PBS -углубляясь в дебри системной инженерии
Дата: 10/11/2011
Тема: Атомная наука


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

В предыдущих статьях о системной инженерии [13], [14] основной упор был сделан на стадии создания системной архитектуры (стадии концептуального проектирования), на которой создается базис, своеобразный фундамент будущей информационной модели энергоблока и проекта  в целом. Почему-то считается, что 3-D модель является основной в информационной модели. Действительно, красивая картинка может впечатлить, однако на самом деле самым важным в проекте является оптимальная структура данных проекта, так называемая Plant Breakdown Structure (PBS).


Под этим понятием обычно понимается функциональная и геометрическая структуры (см. рис. 1), однако, вкратце в статье упомянем совокупность пяти структур: структура требований, функциональная структура технологических систем и компонентов, (SSC по терминологии МАГАТЭ), геометрическая структура (в каком здании, этаже, комнате находится оборудование или в какой стойке, в каком ряду, номер места), структура деятельности и работ (Work Breakdown Structure-WBS) и организационная структура задействованных предприятий (структура и связи организаций, структура и связи подразделений).


Рис. 1 Совокупность 5 структур с организацией единого справочника на базе ISO 15926

Образно выражаясь, PBS - это некий скелет, поддерживающий все тело информационной модели. Самое важное, что все пять структур должны быть между собой перевязаны перекрестными ссылками, а некоторые структуры могут быть подобными. Например, считается (закон Конвея), что на стадии создания изделия структура проектирующего коллектива (группы организаций, организации) должна как бы повторять функциональную структуру изделия, что позволяет оптимально организовать процессы проектирования за счет минимизации интерфейсов между участниками проекта. В этом случае и структура деятельности (WBS) на соответствующей стадии может иметь оптимальную структуру. 

Эберхард Речтин (основатель понятия «системное мышление») дает следующее определение системы: «когда целое составляет нечто большее, чем механическая сумма составляющих, т.е. система обладает свойствами, которые отсутствуют у составляющих ее элементов". В составе систем рассматриваются машины, люди, программное обеспечение, интерфейс с окружающей средой. При описании системы именно грамотная расстановка связей между составляющими системы и ее интерфейсами и создает эффект появления «новых» свойств системы, не присущих отдельным ее составляющим.

Рассмотрим каждую из структур в отдельности, а затем рассмотрим возможности их связывания.

Структура требований

Документация с требованиями может занимать очень большие объемы, поэтому ясная, хорошо продуманная структура требований и документов имеет очень большое значение для облегчения управления и реализации всего комплекса требований. Создание хорошей структуры требований может помочь:

•       минимизировать общее количество требований;
•       лучше осмыслить большой объем информации;
•       отыскать наборы требований, относящихся к определенной теме;
•       выявить пробелы и повторения;
•       исключить конфликт (противоречия) между требованиями;
•       управлять этапами реализации требований;
•       отклонить малоинформативные требования;
•       оценить требования (например, с точки зрения стоимости или времени реализации);
•       повторно использовать требования в последующих проектах.

Первичными источниками набора требований могут быть требования заинтересованных сторон (заказчик, АЭС, контролирующие организации, инвесторы, госорганы, проектанты, изготовители, строители, ремонтники, пуско-наладчики и т.д.),  нормативные документы и стандарты (ГОСТ, МЭК, IEEE, ASME и т.д.), а также требования зарубежных организаций, суммирующие опыт проектирования, сооружения и эксплуатации АЭС в странах, развивающих ядерную энергетику:

•       Требования стандартов и руководств безопасности МАГАТЭ.

•       Регулирующие документы NRC, требования к АЭС, разработанные Электроэнергетическим научно-исследовательским институтом  EPRI (URD), вобравшие в себя опыт проектирования, сооружения и эксплуатации АЭС в США.

•       Требования Европейского экономического сообщества (EUR), суммирующие опыт проектирования, сооружения и эксплуатации АЭС в Европе.

•       Требования к будущим АЭС со стороны пользователей развивающихся стран (Ассоциация CUC-Common User Considerations, МАГАТЭ № NP-T-1.17 ).

•       Требования ассоциации  WESTERN NUCLEAR REGULATORS ASSOCIATION (WENRA) .

Важно все эти документы проанализировать, выбрать полезную информацию с формулировкой конкретного требования к энергоблоку в целом или конкретной системе, оборудованию, узлу или характеристикам материалов.

Стандарт ISO 15288 [3] отводит требованиям 2 практики: сбор и анализ требований. Требования от заинтересованных сторон могут поступать хаотично, повторяться, противоречить друг другу и т.п., поэтому необходим анализ для формирования структуры требований. На первом этапе выделяются системные требования, на базе которых формируется системная архитектура (концепт-проект). Далее в процессе проектирования требования декомпозируются, уточняются, убираются противоречия, заносятся в базу данных и привязываются к структуре информационной модели энергоблока. Поэтому в структуре требований каждое единичное требование должно иметь ссылку на элемент структуры энергоблока для создания условий проверки выполнения требований проектными решениями.

На самом верхнем уровне  находятся системные требования. Их отличие от всего набора требований определяется принципом Парето, иными словами их вклад в конечный результат суммарно должен превышать примерно 80%. Они относятся к глобальным требованиям верхнего уровня. В качестве примера можно предложить требования сейсмостойкости, климатического исполнения, специфические требования к материалам, если они могут повлечь массовую замену серийно выпускаемого оборудования, например, требование изготовления оборудования второго контура из стали, стойкой к эрозионно-коррозионному износу (ЭКИ). На сегодняшний день такого требования нет, но переход на 60 летний цикл эксплуатации АЭС с возможностью последующего продления до 80 лет может потребовать использовать только такие стали для оборудования, подверженного ЭКИ.

Стандарт ISO 29148 [1], находящийся в стадии разработки, предлагает следующую структуру (спецификацию) для множества системных требований (требований к системе в целом):

1.     Введение ( Назначение системы, Состав системы, Сокращения и аббревиатуры, Источники, Краткий обзор

2.     Описание системы (Назначение системы, Режимы работы системы, Ключевые возможности, Основные условия, Основные ограничения, Пользовательские характеристики, Предположения и зависимости, Операционные сценарии)

3.     Возможности систем, ограничения и условия

3.1 Физические (конструктивные, прочность, долговечность, адаптируемость, экзогенные условия (относящиеся к окружающей среде)
3.3 Характеристика системы (эффективность, производительность)
3.3 Защищенность и безопасность системы
3.4 Управление информацией
3.5 Системные операции (человеческие факторы, ремонтопригодность, надежность)
3.6 Политика и регулирование
3.7 Жизненный цикл самообеспечения системы

4.     Интерфейсы системы
По типам требований можно выделить 6 групп: функциональные требования, ограничения, требования к качеству (включая требования к безопасности), сценарии использования, бизнес-требования  и требования к процессам жизненного цикла продукта, включающие административно-организационные требования.

В работе [14] предложен пример декомпозиции функциональных требований и ограничений на 6 уровней в соответствии с вложенными функциями:

1.      функциональные требования заказчика и пользователя, а также ограничения, накладываемые системами в операционном окружении и внешними обеспечивающими системами, находящимися вне площадки объекта;

2.      требования и ограничения на потоки веществ, энергии и информации, требования к потокам с надсистемой и окружающей средой;

3.      набор требований, но уже к элементам объекта, структурно входящим в него;

4.      условия и ограничения на выбор материалов, ограничения, вызванные дополнительными воздействиями реализуемых физических эффектов на элементы исследуемого объекта и на окружающую среду, а также ограничения на энергопотребление, информацию и т.д.;

5.      дополнительные требования по массе, габаритам, компоновке и другим параметрам, свойственным используемым агрегатам, способам и средствам связи элементов и т.д. унификации, условиям эксплуатации, транспортирования и хранения, сроку окупаемости;

6.      набор требований по выбору оптимальных параметров исследуемого объекта, запасам прочности, устойчивости, надежности, серийности, используемому технологическому оборудованию, взаимозаменяемости, стандартизации и т.д.

К экономическим или бизнес – требованиям относятся: эксплуатационные издержки, капитальные затраты, стоимость продукции, стоимость топливного цикла, финансовые (инвестиционные) требования и т.д.

Требования к качеству можно декомпозировать на следующие:

·      Требования к безопасности и охране окружающей среды
o       Ядерная и радиационная безопасность
o       Стойкость к внешнему воздействию (внешний пожар, землетрясение, ураган (смерч), наводнение или цунами, извержение вулкана, падение самолета, терроризм, магнитные бури и т.д.)
o       Уязвимость от внутренних факторов (отказ системы по общей причине, отказ элемента или подсистемы, пожар на площадке и в помещениях энергоблока)
o       Уязвимость к человеческому фактору (намеренное воздействие (саботаж, терроризм), ошибка персонала, административная структура управления)

·      Требования к надежности
o       Временные показатели (время восстановления, назначенные ресурс, срок службы и хранения, наработка до отказа, наработка между отказами)
o       Комплексные показатели надежности (коэффициент готовности, коэффициент оперативной готовности, коэффициент технического использования)
o       Показатели безотказности (вероятность безотказной работы, гамма-процентная наработка до отказа, интенсивность отказов, средняя наработка до отказа)
o       Показатели долговечности (средний ресурс, средний срок службы)
o       Показатели ремонтопригодности (вероятность восстановления, интенсивность восстановления, среднее время восстановления, средняя трудоемкость восстановления)

·      Требования к климатическому исполнению

·      Требования к категории качества исполнения

·      Требования к классу безопасности

Примерами требований к сценариям использования (режимам) могут быть требования:

o      к режимам пуска и останова;
o      к режимам аварийного останова;
o      к противоаварийному управлению;
o      к управлению тяжелыми авариями;
o      к регулированию частоты сети;
o      к режимам отпуска тепла;
o      и т.д.

Отдельно надо выделить требования к процессам и административные и организационные требования:

·      Требования к процессам
o      Требования к процессам контроля и управления
o      Требования к процессам наблюдения и мониторинга
o      Требования к процессам сервиса, тестирования, технического обслуживания и управления надежностью
o      Требования к процессам обеспечения качества
o      Требования к процессам вывода из эксплуатации
o      Административные и организационные требования
§       Требования к обеспечивающим системам и системам в операционном окружении
§       Требования к кодам и стандартам по безопасности
§       Требования к интерфейсу с окружающей средой
§       Требования к интерфейсу с внешними системами

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

По способу верификации в информационной модели все требования разделяются на два класса. К первому относятся текстовые требования, которые не содержат численного критерия выполнимости требования, а значит, требуется чисто экспертная (качественная) оценка его выполнимости со стороны эксперта. В случае простого (несоставного) требования его верификация проводится посредством экспертного анализа специалиста. Если же требование более высокой иерархии может быть декомпозировано на несколько более низких по уровню таким образом, чтобы сумма составляющих равнялась исходному, его верификация осуществляется проверкой выполнения всех вложенных требований более низкого уровня. Этот процесс может быть частично автоматизирован, однако экспертный анализ и в этом случае является определяющим.

Ко второму классу относятся параметрические требования, которые содержат численный критерий и  математическое условие (больше, меньше, равно) выполнимости требования, и верификация такого требования возможна через аппарат сравнения численного параметра требования с параметром из базы данных проекта энергоблока, а результат верификации автоматически вносится в БД.

Наиболее известными системами управления требованиями на сегодняшний день являются DOORS фирмы IBM и IRQA фирмы Visure Solution. Основными недостатками этих систем является их оторванность от базы данных проекта и трудности при создании интерфейсов с этими системами для организации автоматизированного процесса верификации и валидации проекта. Поэтому многие фирмы, поставщики CAD, PLM, PDM систем предлагают собственные системы управления требованиями, с меньшим функционалом работы с требованиями, но с встроенной системой верификации и валидации. Примером могут служить Requirements TeamCenter от Siemens PLM Software и Requirements Central от Dassault Systemes.

Жизненный цикл требований идет параллельно жизненному циклу изделия: начинается от замысла и заканчивается выводом из эксплуатации. Ошибочно мнение, что написали и утвердили техническое задание, и на этом работа с требованиями закончена. Каждая стадия проекта формирует свой набор требований: на стадии пуско-наладки уточняются характеристики систем и уточняются требования, стадия эксплуатации, как самая длительная в жизненном цикле, формирует пласт опыта эксплуатации, на базе которого создаются требования к оптимизации эксплуатации, модернизации, требования учета опыта эксплуатации в новых проектах, и так вплоть до завершения стадии вывода из эксплуатации.

Функциональная структура

Функциональная структура должна разрабатываться на базе функционального анализа [14] и логического проектирования [13]. Естественно, что для сохранения структуры требуется кодирование ее элементов. Кодирование на функциональном принципе используется в стандарте KKS и более новой версии стандарта ISO 81346 [8]. Очень удобно использовать функциональную классификацию стандарта для построения функциональной структуры АЭС. На рис. 2 предложен подход подобного построения (функциональный аспект): площадки АЭС, энергоблоки, функциональные блоки (например, оборудование, прикрепленное к цехам на АЭС), функциональные группы систем, технологические (электрические, управляющие) системы, единицы оборудования (агрегаты). Стандарт также дает правила классификации и для геометрической структуры (локальный аспект,  см. рис. 2,3). Для классификации единиц оборудования (агрегатов) можно использовать правила классификации по продуктовому аспекту (см. рис. 3). Так как в проекте может использоваться в разных системах однотипное оборудование, то целесообразно иметь и структуру каталожной информации, чтобы не дублировать информацию в функциональной структуре, а иметь только ссылку на элемент структуры каталога проекта (см. рис. 2). Информация в каталоге проекта должна поступать из отраслевого каталога и периодически актуализироваться.
 


Рис. 2 Функциональная и геометрические структуры, включая структуру номенклатуры оборудования

При проектировании сначала создается виртуальный прообраз единицы оборудования в формате набора физических параметров, так называемые исходные технические требования (ИТТ). Набор параметров ИТТ совпадает с набором параметров в каталоге, поэтому выбор номенклатуры на позицию в проекте может быть автоматизирован даже при использовании конкурсной процедуры закупок. Как только выбор произведен, можно присвоить номенклатурный код позиции проекта, закодированной в KKS или ISO 81346 [11]. После формирования заказа и изготовления на заводе единице оборудования присваивается заводской номер. При поступлении реального оборудования на склад оно кодируется инвентарным кодом и каждой позиции KKS приписывается инвентарный код единицы оборудования. Если KKS и номенклатурный коды не меняются на жизненном цикле АЭС (могут меняться только при модернизации или изменении проекта), то инвентарный код, приписываемый позиции KKS, меняется при замене или перемещении оборудования, и информационная модель должна это учитывать при моделировании жизненного цикла единицы оборудования.

Стандарт ISO 81346 [11], по сути, задает некий шаблон функций и подфункций и соответствующих им систем и подсистем, и вы должны только подставить в шаблон требуемые параметры. Безусловно, в структуре электронных моделей должны быть предусмотрены и ссылки на текстовые документы, эти документы, как впрочем и электронные, удобно кодировать в соответствии со стандартом ISO 61355 [12] (см. рис. 2), который задает структуру документов.



Рис. 3 Структура кодирования (KKS-код, номенклатурный и инвентарный коды)

Структура отдельных элементов АЭС также должна быть описана в информационной модели. В этом случае можно воспользоваться классификаторами, используемыми в машиностроении. Примерами могут быть:
o      Классификатор ЕСКД (ОК 012-93) разработан в качестве информационной части ГОСТ 2.201-80 ЕСКД для обозначения изделий и конструкторских документов машиностроения и приборостроения класса 30 «Сборочные единицы общемашиностроительные».

o      Технологический классификатор (ТКД, OК 021-95) деталей машиностроения и приборостроения при неизменных основных принципах его построения охватывает детали всех отраслей промышленности основного и вспомогательного производств и является логическим продолжением и дополнением классов деталей Классификатора ЕСКД (классы 71, 72, 73, 74, 75, 76).

o      ОК 022-95 - Общероссийский технологический классификатор сборочных единиц машиностроения и приборостроения (ОТКСЕ) входит в состав Единой системы классификации и кодирования технико-экономической и социальной информации (ЕСКК) Российской Федерации.

Детализация структуры должна отталкиваться от технологических потребностей. Если, например, сосуд изготавливается из обечаек, то в структуре обязательно должны присутствовать объекты с соответствующими свойствами, описывающие обечайки, сварные швы, наплавки с набором атрибутов, описывающих свойства этих объектов. Все объекты должны быть классифицированы и закодированы в единой системе уникальным неповторяющимся кодом.

Структура деятельности и работ (WBS)

Структура деятельности и работ может базироваться на 25 практиках (укрупненных процессах), описанных в стандарте ISO 15288 [3]. Так как указанный стандарт не является стандартом прямого действия, требуется дальнейшая детализация процессов до уровня практического использования.

Четыре верхних класса определены в стандарте как:

·       Процессы согласования или контрактные процессы (закупки, поставки)

·       Организационные процессы (управление инфраструктурой, ресурсами, портфелем проектов, качеством, моделью жизненного цикла)

·       Процессы проекта (планирование, оценка и контроль, управление информацией, конфигурацией, риском и решениями)

·       Технические процессы (управление требованиями, системная архитектура, интеграция, включающая изготовление, строительство и монтаж, верификация и валидация, ввод в эксплуатацию или пуско-наладка, эксплуатация, ТОиР, модернизация, вывод из эксплуатации)
МАГАТЭ несколько иначе группирует управление ресурсами, объединяя в этот класс и управление информацией из процессов проекта и управление интеллектуальной собственностью и инфраструктурой. Можно предложить выделить отдельную группу практик (процессов) управления ресурсами, куда включить все перечисленные выше практики: управление инфраструктурой, человеческими ресурсами, управление информацией и управление интеллектуальной собственностью.

Возникают некоторые сложности с некоторыми технологическими процессами, которые могут фигурировать в разных практиках, например, процессы сварки или монтажа применимы и в практике интеграции (строительстве, монтаже), так и при модернизации, ТОиР и выводе из эксплуатации, поэтому в структуру «технические процессы» должен быть добавлен класс «технологические процессы», включающий, например, строительные операции, монтаж, сварка, пайка и т.д. На каждой стадии жизненного цикла энергоблока применим свой специфический набор процессов, однако структура всех процессов может быть единой для всех стадий. В этом случае можно описать в единой структуре все процессы в информационной модели и использовать на всех стадиях, все время добавляя требуемые процессы и корректируя уже описанные. Однако, тема структуры работ необъятна, и в рамках одной статьи все проблемы описать нельзя.

Организационная структура

Организационную структуру предприятия (организации) описывает стандарт ГОСТ Р ИСО 15704-2008 [15],  который  предназначен для определения требований к архитектурам и методологиям предприятия (enterprise-reference architectures and methodologies). Стандарт нацелен на решение задач трех типов: создание предприятия, его реструктуризация и изменение и ориентирован как на людей, так и на технологии. В качестве приложения в стандарт включена обобщенная стандартная архитектура предприятия и методологии GERAM (Generalised Enterprise Reference Architecture and Methodology). Концепции и правила для модели организации описаны в ГОСТ Р ИСО 14258-2008 [16].

Международные стандарты определяют Предприятие как «группу организаций, разделяющих установленные задачи и цели по предложению продукции или услуг, или того и другого [16]».
Архитектура предприятия – «Описание (модель) основного устройства (структуры) и связей частей системы (физического или концептуального объекта или сущности)»[15]. Архитектура предприятия затрагивает управление знаниями и процессы управления информационными технологиями (ИТ) в организации.

Архитектура предприятия может быть представлена матрицей Захмана (см. рис. 4). Каждая ячейка матрицы задает свой тип описания (модели) свойств предприятия. Вся совокупность ячеек разделена на шесть столбцов матрицы — шесть аспектов деятельности предприятия:

1.     «ЧТО делается», или объекты/данные;
2.     «КАК делается», или функции/процессы;
3.     «ГДЕ делается», - размещение или инфраструктура;
4.     «КТО делает» - люди, оргединицы;
5.     «КОГДА делается» - графики событий и работ;
6.      «ЗАЧЕМ делается» - стимулы, мотивы и стратегии деятельности.


Рис. 4 Матрица Захмана
и шесть строк матрицы:
Ряд 1 – Контекст. Внешние требования и движущие факторы (Моделирование бизнес-функций)            представление организации в окружении внешних факторов
Ряд 2 – Модель бизнеса (Модели бизнес-процессов) – представление бизнес-процессов внутри организации
Ряд 3 – Системная модель (Логические модели)
Ряд 4 – Технологическая модель (Физические модели, определение и разработка решения) – инженерное представление
Ряд 5 – Детальное представление - рабочие конфигурации - взгляд тех, кто будет выполнять отдельные работы
Ряд 6 – Работающая организация (Функционирование организации и оценка)

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

Заключение.

«Как вы яхту назовете, так она и поплывет». Хорошо продуманная заранее структура данных будущего проекта даст многократный выигрыш на последующих стадиях, и не стоит экономить ресурсы на создании инфраструктуры данных. Не стоит уповать и на ПО известных поставщиков. Известное имя и бренд не спасут от ошибок, если изначально они были заложены в структуре данных на первых стадиях проекта. В этом случае надо выбирать поставщика ПО с гибкой системой настроек, позволяющей относительно легко создавать с нуля и модифицировать структуру уже в процессе проектирования в соответствии со стандартами, а не пользоваться лишь ограниченным спектром шаблонов, предоставляемых ПО на начальном этапе разработки. К сожалению, даже известные бренды не могут похвастать подобными свойствами и требуют коренной переделки баз данных в случае перенастроек. Опираться нужно только на современные стандарты, признанные международным сообществом, а не отдельным поставщиком ПО, при этом отслеживать последние разработки и принимать участие в разработке новых стандартов под собственные потребности.

Переход на процессы с использованием информационных технологий (ИТ) в организации требует пересмотра архитектуры предприятия и ее согласования с архитектурой ИТ-приложений. Простая закупка ПО с информационными системами приведет только к негативным последствиям. При сохранении старой структуры произойдет отторжение нововведений необученным персоналом. Более того, налаженная годами технология без использования ИТ может дать сбой при насильственном внедрении информационной системы. Но и отдавать на откуп специалисту по ИТ процесс реинжиниринга в организации еще опаснее. Как правило, специалист по ИТ хорошо знает информационную систему одного поставщика и не способен критически подойти к своему выбору и оптимальному построению информационной системы на предприятии. Здесь нужен системный инженер, имеющий знания в области системной инженерии и обладающий базовыми знаниями о возможностях и недостатках ПО различных поставщиков, а не конкретного ПО, и не мотивированный поставщиком ПО. Ну и, конечно, в процесс реинжиниринга должны быть включены не только руководители, но и ключевые работники предприятия, на которых, как правило, и держится весь успех предприятия.

Если вы провели реинжиниринг предприятия, создали информационную модель изделия, освоили практики жизненного цикла и используете их в работе, описали  жизненный цикл изделия (создали модель его жизненного цикла), постоянно осуществляете анализ риска [14], то есть смотрите на два шага вперед, значит вы управляете жизненным циклом изделия, в противном случае, жизненный цикл изделия будет управлять вами, но это уже совсем другая история…

Литература
1.     ISO IEC 29148 «Управление требованиями»
2.     Элизабет Халл, Кен Джексон, Джереми Дик, «Разработка и управление требованиями», Практическое руководство пользователя (Второе издание)
3.     ГОСТ Р ИСО 152888:2005, ISO/IEC 15288:2008 (IEEE Std 15288-2008) Systems and software engineering — System life cycle processes («Системная и программная инженерия. — Практики жизненного цикла системы»).
4.     DOE-STD-1073-2003, Configuration Management, U.S. Department of Energy
5.     Next Generation Nuclear Plant System Requirements Manual, INL/EXT-07-12999, Rev. 3, September 2009
6.     PDTR 24748:2007 Systems and software engineering – Life cycle management – Guide for life cycle management («Системная и программная инженерия. Руководство по управлению жизненным циклом»).
7.     ISO/IEC TR 24774:2007 Software and systems engineering — Life cycle management — Guidelines for process description («Программная и системная инженерия. Управление жизненным циклом. Руководство по описанию практик).
8.     ISO/IEC TR 19760:2003 Systems engineering — A guide for the application of ISO/IEC 15288 (System life cycle processes) («Системная инженерия — Руководство по применению ISO/IEC 15288 (Практики жизненного цикла системы)»).
9.     ISO/IEC 42010:2007 Systems and software engineering -- Recommended practice for architectural description of software-intensive systems («Системная и программная инженерия – Рекомендованная практика архитектурного описания программоемких систем»
10.  The Method Framework for Engineering System Architectures (MFESA). Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213, Donald Firesmith 5 March 2009
11.  Стандарт ГОСТ Р ISO IEC 81346 «ПРОМЫШЛЕННЫЕ СИСТЕМЫ, УСТАНОВКИ И ОБОРУДОВАНИЕ И ПРОМЫШЛЕННЫЕ ПРОДУКТЫ. ПРИНЦИПЫ СТРУКТУРИРОВАНИЯ И УСЛОВНЫЕ ОБОЗНАЧЕНИЯ»
12.  Стандарт ISO 61355 «Классификация и обозначение документов для станций, систем и оборудования. Часть 1: Правила и классификационные таблицы»
13.  А. А. Просвирнов, «Системная инженерия – миф или ключ к эффективности», http://www.proatom.ru/modules.php?name=News&file=article&sid=3130
14.  А.А. Просвирнов, Т.А. Просвирнова, «Системный функциональный анализ как базис концептуального проектирования», http://www.proatom.ru/modules.php?name=News&file=article&sid=3334
15.  ГОСТ Р ИСО 15704-2008, Промышленные автоматизированные системы. ТРЕБОВАНИЯ К СТАНДАРТНЫМ АРХИТЕКТУРАМ И МЕТОДОЛОГИЯМ ПРЕДПРИЯТИЯ. Industrial automation systems. Requirements for enterprise-reference architectures and methodologies
16.  ГОСТ Р ИСО 14258-2008, Промышленные автоматизированные системы, КОНЦЕПЦИИ И ПРАВИЛА ДЛЯ МОДЕЛЕЙ ПРЕДПРИЯТИЯ, Industrial automation systems. Concepts and rules for enterprise models 







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

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