Системная инженерия – миф или ключ к эффективности
Дата: 08/07/2011
Тема: Кадровая политика


Александр Просвирнов, ОАО «ВНИИАЭС»

С приходом новой команды в отрасль системная инженерия была объявлена неким знаменем развития отрасли. Срочно были изданы два приказа по внедрению, прошли учебные лекции, конференции, выездные учебы, сформировалось межотраслевое сообщество системных инженеров в формате российского отделения INCOSE (Международной ассоциации системных инженеров). И все бы хорошо, но в неформальных беседах с коллегами автор часто слышал мнения, что все это «муть и не имеет к делу никакого отношения».


Может быть лекции по системной инженерии были заумными, может быть не было наглядных примеров положительного опыта ее применения в России, но в основной массе инженеров в отрасли отношение к системной инженерии крайне настороженное.

Никто, конечно, не отрицает полезность системного подхода, однако каждый понимает его по-своему. История развития системной инженерии насчитывает уже более полувека. В советское время готовили даже специалистов по этой теме под названием «системотехник», однако на сегодняшний день специалистов в данной области только собираются готовить в МИФИ и МИСИС. Хотелось бы кратко остановиться только на некоторых аспектах системной инженерии, так как знания о ней необъятны.

Основное понятие, вводимое стандартом по системной инженерии ISO 15288 [1] – это система. Системой может быть услуга или продукт, который вы проектируете или производите, или часть продукта. Вложенность систем не ограничена, но на каждом уровне вы можете применять одинаковый правила. Прежде всего вы должны определить границы системы. Важно ли это? Архиважно! От правильного определения границ зависит конечный результат системного подхода. Если вы сузили границы системы, то ваш взгляд на систему сузился до размеров форточки, и вы уже не сможете смотреть на мир с эффективностью целого окна. Примером может служить парогенератор (ПГ) ВВЭР-1000. В соответствии с разделительной ведомостью главный конструктор проводит границы по патрубкам, а значит, он не рассматривает целиком систему «паропроводы-ПГ-питательные трубопроводы-узел питания и регулирования уровня», которая как раз и определяет основные характеристики ПГ (надежность, устойчивость, поведение и т.д.). В результате имеются проблемы с ресурсом парогенератора, которые могут быть вызваны, например, влиянием повышенной вибрации паропроводов (подобная проблема была освещена в статье на Proatom.ru: http://www.proatom.ru/modules.php?name=News&file=article&sid=2004).

Вторая проблема – это количество шлама, ежегодно выгружаемого из ПГ при отмывках, которое на порядок превышает показатель на наших же ПГ, но установленных за рубежом. Достигается это на зарубежных АЭС специальными мерами в конденсатно-питательном тракте второго контура, однако при рассмотрении системы ПГ только в границах патрубков до учета процессов второго контура руки уже не доходят. В то же время в американских требованиях к ПГ [2] читаем, что в границы системы ПГ входит сам ПГ, паропроводы до заделки в контайнмент, питательные трубопроводы с узлом регулирования уровня в ПГ, системы продувки. Конечно, проблем с ПГ и в PWR хватает, но думается их было бы гораздо больше, если бы они сузили границы системы до «бочки с патрубками». Следующим примером может быть определение границ реакторной установки. В соответствии опять с той же разделительной ведомостью в границы главного конструктора включен первый контур с пассивными системами безопасности и не включены активные системы безопасности и такой важный барьер безопасности, как контайнмент. В результате получается нарушение в системном подходе, когда за общее системное решение производства пара с обеспечением безопасности и глубоко эшелонированной защиты отвечают две организации. Для реактора PWR утвердилось четкое понятие «ядерный остров», как система, которая объединяет весь функционал производства пара на турбину с обеспечением безопасности.

Второй важный аспект – это обеспечивающие системы и системы в операционном окружении. Вы должны описать все интерфейсы системы со всем ее окружением и выделить наиболее значимые из них. Например, при строительстве АЭС Олкилуото-3 в Финляндии AREVA столкнулась с проблемой взаимодействия с местными надзорными органами, что привело к задержке сроков строительства АЭС. Не был учтен и менталитет строителей, основную массу которых составили поляки. В то же время, в соответствии со стандартами системной инженерии вы должны рассмотреть систему не в отдельности, а в совокупности с ее операционным окружением и поддерживающими или обеспечивающими системами.

Следующий аспект - жизненный цикл системы, который вы должны определить и все стадии, через которые она должна пройти в процессе жизненного цикла. Набор стадий, предлагаемый стандартом – это замысел, концептуальный или эскизный проект, технический проект, рабочий проект, изготовление и строительство, пуск и наладка, эксплуатация, модернизация и продление, вывод из эксплуатации. Стадии могут перекрываться, но в каждой стадии должна быть точка решения: продолжать ли стадию, переходить на следующую или прекратить проект. На каждой стадии стандарт [1] рекомендует организовать 25 процессов или практик объединенных в 4 группы: организационные, проектные, технические и закупок-поставок. Для технических специалистов интересными являются технические практики (см. рис. 1) и проектные практики (см. рис. 2), которыми мы и ограничимся в дальнейшем. 




Рис. 1 Технические процессы или практики ISO 15288

В соответствии со стандартом на любом проекте должен быть организован минимум действий: формирование команды, разработка документации по управлению проектом (планы, графики и т.п.), разработка методологии разработки проекта (процедуры, стандарты, регламенты) и действия в рамках разработанных процедур. Как минимум 7 процессов должны быть при этом организованы (см. рис. 2). Кроме планов должны быть обязательно разработаны критерии оценки проекта (система измерения) и на базе их должны проводиться оценка и контроль проекта. Для инвестора очень интересен процесс анализа риска, на базе которого организуется процесс принятия решений. Два процесса, такие как управление информацией и конфигурацией, имеют особое значение для таких сложных объектов, как АЭС. Для тендеров в Финляндии, например, одним из основных требований была поставка так называемых Information Management System (IMS) информационных систем, автоматизирующих процесс управления информацией об АЭС. Процессу или практике управления конфигурацией посвящены 3 документа МАГАТЭ [4],[5],[6] и разработанный в EPRI для новых АЭС в США [7].

 

Рис. 2 Проектные процессы или практики ISO 15288

По определению МАГАТЭ [4] «управление конфигурацией  (УК) (Configuration Management-CM) – это дисциплина управления, определяющая технические и административные направления разработки, производства и поддержки жизненного цикла элементов АЭС. Применяется для технических средств, ПО, материалов, сервисов и технической документации.»

Основная задача системы управления конфигурацией - постоянно контролировать соответствие между требованиями, физической конфигурацией АЭС и документацией (См. рис. 3).



Рис. 3 Структура системы управления конфигурацией АЭС

МАГАТЭ рекомендует включать 6 элементов в систему управления конфигурацией  (УК) на АЭС:

•        Управление программой внедрения УК на АЭС;

•        Проектные требования, которые нужно выявить, документировать, поддерживать в актуальном состоянии, связать со структурой данных проекта (структура, система, компонент-SSC);

•        управление информацией (бумажной и электронной) о физической конфигурации и  проектных требованиях;

•        управление изменениями - соответствие физической конфигурации и информации о конфигурации АЭС проектным требованиям. Люди, вносящие изменения в проект АЭС или ее конфигурацию должны быть квалифицированными и иметь соответствующий опыт, строго следовать утвержденным процедурам.

•        Анализ – как эффективно установить и поддерживать связи между проектными требованиями, физической конфигурацией и информацией о конфигурации АЭС;

•        Обучение и тренинг – персонал, осуществляющий процесс управления конфигурацией, должен быть обучен, пройти тренинг по работе с информационной системой и на тренажере.

Считается, что управление конфигурацией– это интегральная часть управления жизненным циклом (УЖЦ) АЭС и можно сказать, что тот, кто управляет конфигурацией АЭС–управляет ее жизненным циклом.

Базовой практикой технических процессов является управление требованиями. Этот процесс как бы игнорировался ранее, так как сводился к разработке технического задания, после чего его забывали. На самом деле это живой процесс, который должен проходить через все стадии жизненного цикла продукта (например, АЭС) и быть основным инструментом анализа качества и совершенствования. Все требования должны быть проанализированы. При анализе функциональных требований на первый план выходит функциональный анализ, как еще и инструмент оценки стоимости будущей АЭС [3]. Основная цель функционального анализа – выявить альтернативные средства достижения желаемой эффективности, выявить области, в которых имеется возможность для оптимизации стоимости, выделить альтернативные цепочки конструкторских и проектных решений. Наиболее часто используемым инструментом является «закон Парето», согласно которому только примерно 20% элементов влияют на конечный результат, а остальные играют второстепенную роль. В результате анализа должны быть структурированы функции и системы на «единичные жизненно важные» и «второстепенные». Это необходимо для концентрации ресурсов на те области, которые дают максимальный эффект на конечный результат. Точно по такому же принципу из всего набора требований выделяются системные требования, по принципу максимального влияния на конечный результат.

Выделение системных требований и анализ их полноты позволяют приступить к основному магическому действию системной инженерии – к разработке архитектуры разрабатываемой системы (не путать с архитектурой зданий). К сожалению, эта область деятельности отсутствует в наших процессных стандартах. Обычно ее подменяют готовым решением из «запасников», в результате чего старое решение закрепляется на десятки лет. Архитектура системы закрепляет набор системных требований в виде некоего общего недетализированного технического решения. Может оказаться, что одной и той же архитектуре может соответствовать несколько концептпроектов, и выбор конкретного детализированного решения может лежать в плоскости оценки рисков, экономической целесообразности, синергии концептпроектов и т.д.

По определению [8] «системная архитектура – это организация системы, включающая основные компоненты, связи между ними, как они взаимодействуют для удовлетворения системных требований, и принципы их проектирования и развития».
Системная архитектура включает в себя все наиболее важные пропитывающие весь проект стратегические проектные и реализационные решения, изобретения, инженерные компромиссы, допущения и их соответствующие логические обоснования того, как система будет удовлетворять системным требованиям, все основные логические, физические, статические и динамические структуры, альтернативные архитектурные решения, изобретения, компромиссы, допущения и обоснования. Как соотносятся системная архитектура и проектные работы? В таблице 1 перечислены основные отличительные свойства.

Таблица 1 Отличия системной архитектуры от проекта

Системная архитектура
Проект
Стратегический подход, пропитывающий весь проект (Группа компонентов)
Локальный подход (простые компоненты)
Стратегические решения и изобретения
Тактические решения и изобретения
Высоко-уровневые решения для системы
Низко-уровневые решения для системы
Громадное влияние на качество, стоимость и график работ
Слабое влияние на качество, стоимость и график работ
Движущая сила для проекта и интегрального тестирования
Движущая сила для реализации и тестирования на уровне компонентов
Управляется требованиями и высоко-уровневой архитектурой
Управляется требованиями, системной архитектурой и проектом более высокого уровня
Зеркало организации высокого уровня команды разработчиков (Закон Конвея)
Нет влияния на организацию высокого уровня команды разработчиков

Проект разрабатывается уже на базе созданной системной архитектуры, когда рассмотрены альтернативные варианты и выбрана базовая архитектура. На рис. 4 представлена примерная схема проектирования системной архитектуры и перехода к этапу технического и рабочего проектирования: создание P&ID диаграмм, 3-D документов, электрических и КИПиА диаграмм, спецификаций. Рабочая документация разрабатывается в тесной связи с архитектурным проектированием, используя наработанный базис архитектурных решений.




Рис. 4 Схема создания базового проекта «сверху-вниз»

Некоторые системы автоматизированного проектирования (САПР) имеют встроенные функции системной инженерии. К таким пакетам можно отнести RFLP пакет от фирмы DASSAULT SYSTEMES, который отвечает за создание системной архитектуры (структуры), например, будущей АЭС. RFLP расшифровывается как 4 процесса: управление требованиями, функциональный анализ, логическое проектирование и 3-D дизайн.

На рис. 5 представлен поэтапный процесс проектирования системной архитектуры. На первом этапе проводятся сбор, анализ и разработка требований, выделение системных требований. С самого начала сбора требований проводится функциональный анализ, в процессе которого выделяются все функции системы в виде древовидной структуры и результат документируется в виде функциональных диаграмм, для чего требуется редактор функциональных диаграмм, имеющий связь с деревом требований. По сути, функциональный анализ должен ответить на вопрос: «Какими блоками функций будет выполнен весь комплекс собранных требований к продукту (энергоблоку и АЭС)?»

Для выполнения проектирования логической архитектуры требуетсяспециализированный редактор. На этапе логической архитектуры мы должны ответить на вопрос; «Какими системами и подсистемами будут выполнены все определенные в функциональном анализе функции продукта?»

Физическая архитектура документируется в форме 3-D моделей, PFD (P&ID) диаграмм, при этом осуществляется связь всех созданных электронных документов между собой. Вся документация должна храниться в хранилище (базе данных). Сам процесс разработки системной архитектуры также должен моделироваться с обеспечением ресурсами и связью со структурой проекта (см. рис. 5).


Рис. 5 Процесс проектирования системной архитектуры

Как видно из рис. 5, каждый вид деятельности имеет соответствующую документацию с древовидной системой структуризации, перевязанных перекрестными связями и ссылками.

Кроме этого, на этапе системного проектирования необходимо расчетное обоснование системных решений. Это подразумевает подключение расчетных комплексов по автоматике, электрике, теплогидравлике, надежности, безопасности и прочности с автоматическим импортом проектных данных из БД проекта (см. рис. 6). Так называемый V-процесс (см. рис. 6) организуется в постоянной итерации: изменил – проверил (протестировал) - интегрировал компоненты - снова протестировал и т.д.


Рис. 6 V-диаграмма процессов разработки системной архитектуры с встроенным расчетным обоснованием

Результатом работы в пакете должен быть упрощенный (на уровне системной архитектуры) «виртуальный» прототип будущей системы (электронный макет), который может продемонстрировать на моделях выполнение системных требований.

В составе исполняемых архитектурных представлений по сути должны быть виртуальные или реальные архитектурные прототипы, архитектурные симуляторы и исполняемые архитектуры (динамические симуляторы, например, «Виртуальная АЭС» [15],[16]). Сегодня уже практически не используют реальные макеты, на смену им пришли математические модели, компьютерные программы, системы трехмерной визуализации, позволяющие создавать виртуальный прототип разрабатываемой системы.

Системной архитектурой должна заниматься команда опытных инженеров во главе с главным системным архитектором проекта (ГАПом, не путать с архитектором, проектирующим здания). Разделение функций с главным инженером проекта (ГИПом) необходимо, так как совершенно различны задачи (см. таблицу 1). Основная задача ГАП – обеспечить удовлетворение требований заинтересованных сторон, в то время как основная задача ГИП – обеспечить техническую реализуемость проектных решений. Так как часто эти задачи противоречивы, то в споре и рождается истина. Также нужен и ГУП (главный управляющий проекта) – его задача обеспечить организацию процесса проектирования (ресурсы, графики, отчеты и т.д.), так как не рационально загружать этими задачами ГИПа.
 
Практика показала, что недостаточно купить коробочки с программным обеспечением, и, оставив старые процессы проектирования, заявить, что системная инженерия внедрена. Необходимо внедрить современные процессы, которые поддерживаются определенными программными продуктами и международными стандартами, и знание современных технологий и стандартов ценится гораздо выше, чем умение нажимать на нужные кнопочки в компьютерной САПР.

Важно также организовать обмен данными между различными системами. Сегодня уже нет ни одного проекта, который бы делался на одной системе. Многообразие их таково, что международное сообщество пришло к выводу о необходимости разработки стандартов обмена данными. Солидные компании, разработчики крупных систем в нефтяной отрасли, объединились в организацию FIATECH по разработке стандарта обмена данными ISO 15926. Принцип его в следующем. Чтобы не писать множества интерфейсов между всеми системами достаточно создать некий нейтральный формат, через который и будут обмениваться все системы. В этом случае достаточно только одного интерфейса для каждой системы к нейтральному формату.

Заключение

На взгляд автора для внедрения системного подхода в отрасли при создании новых проектов АЭС требуется пересмотр разделительной ведомости. Границы систем, их интерфейсы, системы в операционном окружении и обеспечивающие системы должны быть определены в первую очередь, а значит должны быть определены более четко с позиции системного подхода зоны ответственности всех заинтересованных сторон.

Любой новый проект АЭС, должен начинаться с создания набора требований, выделения системных требований и разработки на их базе системной архитектуры АЭС, как базового элемента будущего технического и рабочего проекта. Выбор в качестве базового проекта любого «реализованного» ранее может утопить в «болоте» второстепенных систем большинство новых идей и проектно-конструкторских решений, а устаревшие проектно-конструкторские решения будут висеть тяжелыми гирями, не давая прохода новым идеям. 

Литература

1.     ИСО/МЭК 15288: 2005 (2008)            Процессы жизненного цикла систем. Системная инженерия. Информационная технология.
2.     ADVANCED LIGHT WATER REACTOR UTILITY REQUIREMENTS DOCUMENT, URD, Prepared For Electric Power Research Institute Palo Alto, California
3.      «УПРАВЛЕНИЕ СТОИМОСТЬЮ», Министерство энергетики США (DOE). Управление по административным вопросам, бюджету и оценке
4.     IAEA-TECDOC-1335, «Управление конфигурацией на АЭС», Configuration management in nuclear power plants, VIENNA, 2003
5.     IAEA-TECDOC-1651, «Информационные технологии для управления конфигурацией АЭС»,  Information Technology for Nuclear Power Plant Configuration Management, VIENNA, 2010
6.     SAFETY REPORTS SERIES No. 65, «Применение управления конфигурацией на АЭС», Application of Configuration Management in Nuclear Power Plants , IAEA, VIENNA, 2010
7.     «Усовершенствованные ядерные технологии: Рекомендации по передаче информации по новым АЭС», EPRI, Пало-Альто, Калифорния: 2009, 1019221
8.     ISO/IEC 42010:2007 Systems and software engineering -- Recommended practice for architectural description of software-intensive systems («Системная и программная инженерия – Рекомендованная практика архитектурного описания программоемких систем»
9.     Элизабет Халл, Кен Джексон, Джереми Дик, «Разработка и управление требованиями», Практическое руководство пользователя (Второе издание)
10.  Стандарт ISO IEC 29148 «Управление требованиями»
11.  PDTR 24748:2007 Systems and software engineering – Life cycle management – Guide for life cycle management («Системная и программная инженерия. Руководство по управлению жизненным циклом»).
12.  ISO/IEC TR 24774:2007 Software and systems engineering — Life cycle management — Guidelines for process description («Программная и системная инженерия. Управление жизненным циклом. Руководство по описанию практик).
13.  ISO/IEC TR 19760:2003 Systems engineering — A guide for the application of ISO/IEC 15288 (System life cycle processes) («Системная инженерия — Руководство по применению ISO/IEC 15288
14.  The Method Framework for Engineering System Architectures (MFESA). Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213, Donald Firesmith 5 March 2009
15.  В.В.Емельяненко, А.П.Жукавин, В.В.Именин, А.Е.Крошилин, В.Е.Крошилин, А.О.Ковалевич, В.Н.Майданик, А.А.Просвирнов, Е.Ф.Селезнев, Р.Г.Сычев, И.В.Федоров, Р.Л.Фукс, «Опыт создания комплексных математических моделей для анализа нестационарных режимов работы АЭС», ОАО «ВНИИАЭС», УДК 621.039, «Вопросы атомной науки и техники», выпуск 3, 2005г.
16.  А.А.Просвирнов, К.А.Тимофеев, «Система автоматизированного проектирования «Виртуальная АЭС», как подсистема CALS технологии поддержки изделия на протяжении жизненного цикла», г. Санкт-Петербург, Международная студенческая конференция Северное Сияние, февраль 2006






Это статья PRoAtom
http://www.proatom.ru

URL этой статьи:
http://www.proatom.ru/modules.php?name=News&file=article&sid=3130