Содержание к диссертации
Введение
Глава 1. Постановка задач и анализ технических требований 10
1.1 Анализ технических требований 11
1.2 Каналообразующая часть шкафа 14
1.3 Состав операционной системы "Linem" 22
1.4 Протоколы сетевого взаимодействия ОС "Linem" 24
1.4.1 FTP (File Transfer Protocol) 26
1.4.2 Telnet 27
1.4.3 SNMP(Simple Network Management Protocol) 28
1.5 Сравнительные характеристики 32-х разрядных систем 32
Глава 2. Разработка методик верификации СПО и ППО 34
2.1 Программные средства испытаний 35
2.2 Порядок проведения испытаний 36
2.3 Методика испытаний общесистемных функций 38
2.4 Запуск и диспетчеризация задач 39
Глава 3. Создание стенда тестирования надежности ПО 40
3.1 Цели проведения испытаний 41
3.2 Состав стенда тестирования надежности 43
Глава 4. Процесс верификации компонент СПО и ППО 45
4.1 Порядок испытаний 45
4.2 Методика испытаний сетевых функций 46
4.3 Контроль работоспособности сетевых приложений 47
4.4 Проверка функции зеркалирования серверов . 48
4.5 Тестирование прием-передачи информации 50
4.6 Тестирование реализации функции файлового сервера 51
4.7 Тестирование работы общесистемных функций 52
4.8 Выводы по результатам тестирования 53
4.9 Детализированное описание порядка проведения испытаний 11110...54
4.10 Аудит исходных текстов СПО «Linem» 56
4.11 Верификация исходных текстов ППО 59
4.12 Тестирование защищенности от несанкционированного доступа...63
Заключение 68
Приложения 69
- Анализ технических требований
- Порядок проведения испытаний
- Цели проведения испытаний
- Проверка функции зеркалирования серверов
Введение к работе
В современных программно-аппаратных комплексах особо важными становятся задачи, связанные с верификацией работы программного обеспечения, то есть с выполнением процесса, позволяющего определить, что разработанное программное средство точно реализует концептуальное описание данной системы.
В соответствии с МЭК 60880 верификацией признается процесс, в котором проверяется правильность интегрирования прошедших верификацию модулей аппаратных средств и программного обеспечения (ПО) в систему, их совместимость и функционирование в виде системы согласно требованиям к интеграции.
При проектировании и запуске в эксплуатацию объектов атомной энергетики возникает необходимость установки отказоустойчивых интегрированных систем мониторинга процессов работы оборудования как на системно-функциональном, так и на программном уровне.
Программно-технический комплекс информационно- диагностической системы (ЛТК ИДС) функционирует в рамках комплекса электрооборудования системы управления и защиты реактора (КЭ СУЗ) и представляет собой сложную электромеханическую систему в составе большого количества функционально связанных шкафов, укомплектованных серверами, сетевыми коммутаторами, мониторами, а также сопутствующим оборудованием. Весь комплекс функционирует как единое целое, выполняя сложные функциональные задачи в области обеспечения управления и защиты атомных реакторов атомной энергетических станций с глубокой диагностической и информационной поддержкой.
Аналогичные вопросы рассматривались в работах различных иностранных и российских ученых (А. Шоу, М. Дансмур, Г. Дейвис, К.Ю.Богачев, Г.Т. Артамонов, Л.Б. Богуславский, М. Уелш).
Работы по созданию подобных операционных систем проводились специалистами Института проблем управления Российской Академии наук (ИЛУ РАН) применительно к системе верхнего блочного уровня атомной электростанции (АЭС), к которой предъявляются иные по сравнению с КЭ СУЗ требования по обеспечению отказоустойчивости, резервирования и восстановления после сбоев и отказов.
В Федеральном государственном унитарном предприятии "Научно-производственном предприятии - всероссийском научно-исследовательском институте электромеханики с заводом им. А.Г. Иосифьяна " (Hi111 ВНИИЭМ) вопросами создания отказоустойчивого программного обеспечения занимались И.А. Десятников, А.К. Савин, Т.Е. Ампилова, И.А.Иванова, М.В. Протопопов и др.
Наиболее подробно вопросы верификации и тестирования программных средств, включая применение и взаимодействие верификации и тестирования в жизненном цикле сложных программных средств рассматриваются в трудах В.В. Липаева.
В рамках данной диссертационной работы учитывается накопленный опыт НПП ВНИИЭМ по проведению процесса верификации и предлагаются новые подходы и методики применительно к процессу оценки программного обеспечения, функционирующего в рамках информационно-диагностических систем комплекса электрооборудования системы управления и защиты атомных электростанций (КЭ СУЗ АЭС).
Верификация программных модулей не является типовой задачей. Решать ее приходится разными способами, в прямой зависимости от содержания как самих программ и типа операционной системы, так и назначения программно-аппаратного комплекса. Различные операционные системы по разному реализуют необходимые функции, в связи с этим крайне важным является производить переосмысление методов и методик верификации при смене типа операционных систем и программ.
Обеспечение требований по отказоустойчивости функционирования программного обеспечения для комплекса электрооборудования системы управления и защиты атомных электростанций (КЭ СУЗ АЭС), содержащего как системные, так и прикладные компоненты, ставит проблему глубокого анализа структуры и логики совместной работы программных и аппаратных составляющих, принципов их совместного взаимодействия.
С самого начала работы над проблемой была поставлена задача по созданию комплекса программ мониторинга и управления, базирующихся на операционной системе с открытыми исходными текстами, так как данная область представляется недостаточно изученной.
Проблема создания и верификации подобной операционной системы и прикладного программного обеспечения высокой доступности является особенно актуальной при разработке информационно-диагностического комплекса электрооборудования систем управления и защиты АЭС (ИДС КЭ СУЗ АЭС).
Целью данной диссертационной работы является разработка методов верификации системного и прикладного программного обеспечения информационно-диагностической системы комплекса электрооборудования системы управления и защиты (КЭ СУЗ) АЭС. Для достижения указанной цели в диссертационной работе ставятся следующие задачи: разработка методик верификации системного и прикладного программного обеспечения с применением автоматических методов, создание стенда тестирования программных составляющих, тестирование программных компонентов на наработку в рамках программы по верификации, разработка программ-зондов, осуществляющих контроль работы всего комплекса программ и частных прикладных программ при подаче на них тестового трафика, эмулирующего нагрузку, проведение анализа результатов тестирования.
В процессе верификации представляется особенно важным использование аналитических и экспериментальных методов оценки результатов с использоаанием специализированных стендов тестирования программного обеспечения, базирующегося на идентичных электрооборудованию информационно-диагностической системы комплекса электрооборудования системы управления и защиты атомных электростанций аппаратных средствах.
Данная область также содержит большое поле для проведения исследований по причине необходимости выполнения следующих задач, непосредственно связанных с вопросами тестирования и верификации программного обеспечения и функций системы: проведение системного анализа задач по верификации программного обеспечения информационно-диагностической системы комплекса электрооборудования и защиты (ИДС КЭ СУЗ) АЭС, разработка основных критериев верификации операционной системы и прикладного программного обеспечения с открытыми исходными текстами, использование новых функций в области подтверждения отказоустойчивости совместной работы оборудования и программного обеспечения, важного для безопасности АЭС, исследование отказоустойчивой работы программных средств ИДС на основе предложенных методик, включающих в себя набор задач по верификации, в том числе с использованием созданного стенда тестирования программного обеспечения, проведение процесса верификации программного обеспечения, выполненного на базе открытых исходных текстов, на основе созданных методик автоматических (с использованием специализированных программных средств) и ручных способов аудита.
Достоверность предложенных методик предлагается подтвердить тестированием системного и прикладного программного обеспечения в (СПО и ППО) форсированном режиме на специализированном стенде НЛП ВНИИЭМ. Задачей стенда тестирования надежности ставится получение необходимого объема статистических данных для анализа.
Большое внимание в исследовании процесса верификации системного и прикладного программного обеспечения (СПО и ППО) информационно-диагностической системы комплекса электрооборудования и защиты (КЭ СУЗ) АЭС необходимо уделить и подходу к реализации самого процесса верификации программ и функций системы. В соответствии с рекомендациями МЭК 60880 и 60880-2, крайне важным для оценки итоговой работы по верификации является следование принципу разделение группы программистов создающих программный код и группы программистов, осуществляющей его верификацию, включая различное административное подчинение, инструкции по работе, программно-аппаратные средства реализации своих функций.
Анализ технических требований
Международными регламентирующими организациями (МАГАТЭ и др.) принято решение о безусловном выполнении требований открытости операционной системы, применяемой для обеспечения функций управления и контроля управления АЭС. В частности такие требования были предъявлены к программному обеспечению комплекса электрооборудования систем управления защиты (ПО КЭ СУЗ). До последнего времени в этих системах использовалась только ОС Windows NT (разработчик - компания Microsoft), однако в связи с вышеуказанными требованиями возникла необходимость ее поэтапной замены на ОС с открытыми исходными текстами. С этой целью была поставлена задача о создании открытой ОС для КЭ СУЗ, внедрение ее в комплекс аппаратуры, выпускаемой ВНИИЭМ по ряду договоров, в том числе ТЯНВАНЬ, БУШЕР и другие, проведения тестирования и верификации, как самой операционной системы, так и ее системного и прикладного ПО. Эта проблема является не только актуальной, но и существенно новой как для ВНИИЭМ, так и для отрасли в целом, поскольку такая задача никогда не выполнялась ранее для оборудования АЭС, к которым предъявляются повышенные требования (в том числе обеспечение отказоустойчивости, резервирования, быстрого восстановления после сбоев и отказов).
Для успешного решения данной проблемы потребовалось решить следующие задачи: - провести анализ дистрибутивов ОС, основанных на принципах открытых исходных текстов с целью исследования возможности адаптировать собственный дистрибутив ОС к задачам возложенным на НДС; - подготовить загрузочную версию ОС и произвести разработку и создание стенда для тестирования ОС и ПО; - проведение непрерывного длительного тестирования ОС и ПО с целью подтверждения требований, предъявляемых ним, а также исследовать возможность решения задач резервного копирования между блоками программного комплекса; исследование возможности обеспечения отказоустойчивого функционирования программ сетевого мониторинга; - провести тестирование и верификацию дистрибутива ОС, в том числе его программных составляющих в соответствии с разработанными методиками. Задачами работы являются: 1. Разработка методик верификации системного и прикладного программного обеспечения с применением автоматических методов. 2. Создание стенда тестирования программных составляющих, тестирование программных компонентов на наработку в рамках программы по верификации. 3. Разработка программ-зондов, осуществляющих контроль работы всего комплекса программ и частных прикладных программ при подаче на них тестового трафика, эмулирующего нагрузку, проведение анализа результатов тестирования. 1.1 Анализ технических требований В связи с необходимостью произведения процесса верификации, крайне важным явился процесс анализа состояния построенного программно-аппаратного комплекса с целью адаптации методик верификации под конкретные задачи, возложенные на систему. Процесс адаптации программного обеспечения (ПО) с самого начала исследований базировался на технических требованиях, разработанных для программно-аппаратного комплекса ИДС, где в частности подчеркивается, что аппаратная конфигурация серверов в составе системы обеспечивает: - организацию двух сегментов сети Ethernet (формат кадров - 802.3) с целью обеспечения резервирования; - двухканальную связь по сети Ethernet с системой СВБУ с целью обеспечения резервирования; - ввод в каждый шкаф серверов дискретных сигналов; - вывод из каждого шкафа серверов дискретных сигналов; - электропитание оборудования шкафа серверов от источника бесперебойного питания, входящего в состав шкафа. Для обеспечения общих требований к программному комплексу в составе ИДС типовая аппаратная конфигурация каждого шкафа с серверами включает: - два сервера (сервер диагностической информации (СДИ) и рабочая станция шлюза (РСШ); - платы дискретного ввода ПДВ; - платы дискретного вывода - релейной коммутации ПРК; - интерфейсы (карт) локальной сети Ethernet 802.3; - каналообразующая часть - коммутаторы локальной сети Ethernet 802.3; -монитор и клавиатуру, подключаемые к любому серверу; - источник бесперебойного питания ИБП. Каждый сервер в типовой конфигурации, на котором функционирует ОС "Linem", устанавливаемый в шкафу, имеет следующие характеристики: - микропроцессор типа (класса) Intel Pentium III (или Celeron) с внутренней тактовой частотой не менее 667 Мгц; - объем оперативной памяти - не менее 128 Mb; - объем накопителя на жестком диске - не менее 8 Gb; - возможность установки до 4-х карт локальной сети Ethernet 8023 на платах 3COM; - контроллер SVGA, обеспечивающий разрешение не менее 1024x768 и количество цветов - 65536. Внешний вид рассматриваемого шкафа серверов программно-аппаратного комплекса ИДС КЭ СУЗ представлен на рисунке №1. Несмотря на то, что верификация программных составляющих производилась с использованием типового набора аппаратных составляющих, результаты данных исследований также справедливы и для другого набора аппаратных компонент, таким образом разработанные методики верификации ПО, могут применяться и при решении других задачи по верификации.
Порядок проведения испытаний
Программные средства обеспечивают корректную установку и работу с ядром и основными компонентами ОС "Linem", в том числе: ядром ОС интерпретатором bash оболочкой Motif IPX коллектором (ipx_utils/mars_nwe) snmp-агентом (snmpd), істр-агентом программой зеркалирования данных (mirror/proftp) программой архивирования данных (tar/gzip) драйверами и программой обработки данных поступающих с плат цифрового ввода-вывода ЦВВ Advantech PLC 733/73. В целях проведения процесса верификации создают специализированные программы-зонды, по одному на одну или несколько функций - запуск и диспетчеризация задач (proc-diag), зеркалирование серверов (mirror-diag), Поддержка протокола ТСРЛР (icmp-diag), при ем-передача информации через контроллеры ввода-вывода дискретных сигналов (pcl_diag), защита от несанкционированного доступа — обеспечение безопасности сети (Secure-diag). Данные программы могут быть воспроизведены как на различных языках программирования (в том числе bash и perl). В соответствии с международными стандартами, регламентирующими разработку и тестирование программного обеспечения для АЭС[16], весь комплекс работ по тестированию ПО информационно-диагностической системы (ИДС) можно разделить на несколько этапов. На первом этапе проводятся автономные испытания отдельных программных модулей программ на стенде оценки надежности ПО. На этом этапе оценка надежности проводится раздельно для сетевых и общесистемных функций системы. Такой подход позволяет оценить как соответствие системы требованиям к потерям и задержкам, возникающим при передаче данных, так и сбоям в системных и прикладных пакетах системы (устойчивость к зависаниям). На втором этапе проводится проверка функционирования всего стенда оценки надежности программного обеспечения. На этом этапе проверяются такие показатели надежности системы как наработка на отказ, восстановление в случае сбоев и др. Поскольку в данном случае испытаниям подвергается интегрированная система, сочетающая в себе аппаратную и программную части, то и показатели надежности системы вычисляются для всей системы в целом, т.е. отказы системы рассматриваются безотносительно аппаратной или программной причины их возникновения. Испытаниям подвергаются как общесистемные, так и сетевые функции программных средств. На рабочих станциях при испытаниях запускаются следующие штатные программы: сервер автозапуска crond; программа зеркалирования Mirror; интерфейсные скрипты тестирования (ICMP-diag, PROC-diag и другие). Проверка надежности работы ПО осуществлялась по нескольким направлениям: контроль функционирования программных средств ИДС; сохранение работоспособности системы при соблюдении условий эксплуатации сервера; проверка работоспособности ПО, в частности (ядра ОС, интерпретатора bash, snmp-агента (snmpd), программы зеркалирования данных (mirror/proftp), істр-агента). Контроль за функционированием программного обеспечения проводился с использованием специальных диагностических средств в следующем порядке: - подготовка серверов к тестированию (установка rpm пакетов: ping, top, и др., установка IP адресов - в сети); - написание тестового ПО для проведения испытаний (script, perl), общесистемных функций серверов, а также тестирования межсетевого взаимодействия (передача потока информации с одновременным учетом качественных параметров по окончанию процесса передачи); - тестовый запуск диагностической программы-зонда; - установка круглосуточного режима работы на стенде оценки надежности при постоянном запуске программы; - по результатам работы и наблюдений, анализа файлов /var/log/messages, /var/log/bootlog, /data/message) производится проведение мониторинга работы тестирующего ПО и серверов в целом, а также произведение соответствующих записей в оперативный журнал. 2.3 Методика испытаний общесистемных функций Контроль общесистемных функций программного обеспечения ИДС сводится к мониторингу запуска и диспетчеризации значительного числа задач. На одном из серверов, работающих под ОС "Linem" осуществлялся запуск диагностических программных средств. При этом обеспечивался как непрерывный режим работы серверов, так и диагностических средств, запущенных на сервере диагностической информации (СДИ). Для мониторинга общесистемных функций ПО устанавливается и запускался зонд proc-diag. Пример проведения процесса верификации с использование программы зонда показан в приложении №7.
Цели проведения испытаний
В состав стенда входили: - материнская плата ROBO-658 (чипсет Intel 810е); - центральный процессор Celeron 766; - оперативная память DIMM 256 Mb Sync 133; - жесткий диск U Series 5 ST340823A Seagate; - видеоадаптер 3D Graphic 4 Mb 1600x1200 256 цветов; - сетевой адаптер ЗС980С-ТХМ; - сетевой адаптер - встроенный контроллер Intel EEPROM; - привод CD-R/RW для архивирования данных; источники бесперебойного питания для обеспечения непрерывности процесса тестирования; - модули цифрового ввода/вывода Advantech PCL 733, К испытаниям прилагалась следующая документация: техническое задание на СПО; техническое задание на стенд оценки надежности ПО; паспорт стенда оценки надежности ПО ПТК ИДС; программа и методика испытаний. Для разработки методик тестирования и верификации системного и прикладного ПО необходимо было необходимо создать стенд тестирования ПО на котором бы существовала возможность производить тестирование ПО под нагрузкой в течение длительного периода времени. Стенд тестирования надежности является важным элементом в проведении процесса верификации (в составе стенда - материнская плата с микросхемным набором, микропроцессором, оперативной памятью, накопителем на жестком магнитном диске, видеоадаптером, сетевыми адаптерами, приводом CD-R/RW).
Сложность используемых в промышленности программно-технических комплексов информационных, диагностических систем постоянно возрастает, что требует непрерывного увеличения затрат как на разработку и изготовление, так и на тестирование и верификацию процессов работы этих комплексов. При этом доля затрат на разработку программного обеспечения непрерывно возрастает. Но в особенности быстро растет доля затрат на верификацию новейших сложных программно-технических комплексов, поскольку именно эффективная верификация обеспечивает быстрый ввод этих комплексов в эксплуатацию.
Основное электротехническое оборудование АЭС модифицируется достаточно медленно и имеет срок службы в несколько десятилетий, на протяжении которого аппаратура, обслуживающая это оборудование программно-технического комплекса сменяется несколько раз. Программное же обеспечение комплекса может модернизироваться регулярно, как наиболее гибкая и легко модифицируемая часть программно-технического комплекса. Поэтому проблема верификации программного обеспечения оборудование ИДС КЭ СУЗ АЭС не является одноразовой, а должна многократно решаться в течение срока жизни основного электротехнического оборудования АЭС и выполняться при каждом существенном изменении аппаратуры или ПО комплекса. Соответственно должен видоизменяться и стенд, на котором выполняется верификация ПО. Стенд верификации ПО программно-технического комплекса должен иметься у каждого энергоблока АЭС и работать на протяжении всего жизненного цикла основного энергооборудования этого энергоблока АЭС, обеспечивая выполнение верификации программного обеспечения при каждой модификации ПО и аппаратуры ПТК ИДС КЭ СУЗ АЭС. При этом стенд должен аппаратно и программно соответствовать состоянию оборудования и ПО верифицируемого программно-технического комплекса ИДС КЭ СУЗ энергоблока.
Проверка функции зеркалирования серверов
В рамках разработанной программы и методики по верификации исходных текстов были проделаны работы по аудиту исходных текстов ППО. По результатам были сделаны соответствующие замечания, в частности подчеркивалось: - требования к программному коду в части содержания заголовка, авторства, номера версии и указанием внесенных изменений выполнены только для ПО «ШЛЮЗ» (GW). В ПО «КДЭ» и «ШЛЮЗ» (gate.c) комментарии в заголовках полностью отсутствовали. В связи с этим группе разработчиков рекомендовалось осуществить дополнение заголовков, а также создание комментариев для каждой вызываемой функции и всех участков кода трудных для понимания. Было обращено внимание на несоответствие комментариев рассматриваемому участку кода (например в модуле GW_Aling.c, функция GW_Align); - в комментариях к исходным текстам использовался как русский, так и английский язык (рекомендовалось сохранение единой схемы комментирования исходного кода (модулей, функций, участков кода, переменных и констант) в частности использование одного языка (русский/английский/трансл ит); - для облегчения понимания кода и сокращения возможного наличия в нем логических ошибок рекомендовалось шире использовать константы препроцессора, развернуто комментировать как отдельные константы, размерности массивов, границы циклов, так и группы констант, имеющих общую смысловую нагрузку; - для облегчения читаемости кода и обеспечения единого стиля программного кода, а также для выполнения требования о построчном объявлении переменных и констант (одна строчка кода- один оператор) была подчеркнута необходимость обратить внимание на использование инструмента indent(lL); - рекомендовалось удаление закомментированных участков исходного кода, используемых лишь на этапе отладки и тестирования; в программных модулях было обнаружено широкое использование глобальных переменных, статических массивов строк/данных и функций работы над ними. В виду особенностей стандартной библиотеки языка С, а именно отсутствия возможности контроля границ массивов, было рекомендовано использование специальной библиотеки Iibsafe(8) для проверки корректной работы таких функций как sprintf[3), strcat(3), strcpy(3) и другие; - была подчеркнута необходимость обратить внимание на повторяющиеся файлы в пакетах ШЛЮЗ и КДЭ (например, файлы с одинаковыми именами bushtypes.h и bushcommon.c - используются в обоих проектах, однако их контрольные суммы различаются, заголовочный файл bushtypes.h включается в оба проекта используя конструкцию #include с угловыми скобками), а также и на повторяющиеся участки кода встречающиеся в нескольких файлах директории GW). Необходимым являлось создание единообразного механизма связи исследуемого и тестирующего программного обеспечения. В первую очередь это касалось способов передачи сообщений об ошибках. ПО должно было адекватно отзываться о текущей ситуации в жестких условиях круглосуточного повторения тестов без доступа оператора нижеперечисленными способами: - произошла неожиданная/нештатная ситуация после которой ПО не может продолжать работу. Единая функция оповещения об ошибке должна указать в каком файле, строке файла, функции она произошла, возможный контекст, текстовое сообщение. Оно будет передано разработчикам ПО. Тестирующее ПО на уровне посимвольного сравнения должно однозначно определить, что программа закончила свое выполнение нештатно, тест завершился неуспешно. Для примера можно указать на реализацию функции assert(3): - произошла штатная ситуация, программа отреагировала адекватно и может продолжить/завершить свою работу. Для тестирующего ПО должно быть ясно, что тест завершился успешно. От единой функции оповещения об ошибках требуется указания причины произошедшей ошибки в формате, используемом для целевого пользователя программного обеспечения; - тестирование ПО неизбежно вызовет ситуации, при которых исследуемое ПО прекращает свою работу без сообщений об ошибках (например, зависание системы вместе с "core dump"); - необходимо предусмотреть способ коммуникации между разработчиками ПО и самим ПО в условиях тестирования (здесь может оказаться недостаточно описание теста при котором произошло событие и приложения обратного стека вызовов, полученного отладчиком gdb(l)). В приложении №2 содержится список пакетов подлежавших верификации с указанием исходного языка программирования на котором создан соответствующий пакет.
