proatom.ru - сайт агентства ПРоАтом
Авторские права
  Агентство  ПРоАтом. 27 лет с атомной отраслью!              
Навигация
· Главная
· Все темы сайта
· Каталог поставщиков
· Контакты
· Наш архив
· Обратная связь
· Опросы
· Поиск по сайту
· Продукты и расценки
· Самое популярное
· Ссылки
· Форум
Журнал
Журнал Атомная стратегия
Подписка на электронную версию
Журнал Атомная стратегия
Атомные Блоги





PRo IT
Подписка
Подписку остановить невозможно! Подробнее...
Задать вопрос
Наши партнеры
PRo-движение
АНОНС

Вышла в свет книга Б.И.Нигматулина и В.А.Пивоварова «Реакторы с тяжелым жидкометаллическим теплоносителем. История трагедии и фарса». Подробнее 
PRo Погоду

Сотрудничество
Редакция приглашает региональных представителей журнала «Атомная стратегия»
и сайта proatom.ru.
E-mail: pr@proatom.ru Савичев Владимир.
Время и Судьбы

[10/11/2011]     PBS -углубляясь в дебри системной инженерии

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

В предыдущих статьях о системной инженерии [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


Самая читаемая статья: Атомная наука:
Интуиция в законе

Рейтинг статьи
Средняя оценка работы автора: 2.2
Ответов: 10


Проголосуйте, пожалуйста, за работу автора:

Отлично
Очень хорошо
Хорошо
Нормально
Плохо

опции

 Напечатать текущую страницу Напечатать текущую страницу

"Авторизация" | Создать Акаунт | 21 Комментарии | Поиск в дискуссии
Спасибо за проявленный интерес

Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 10/11/2011
Вы (ВНИИАЭС) бы лучше привязку времени к событиям в Ростове-2 сделали, чем "филосовствовать". У Вас там время недостоверно уже несколько лет (с моиента пуска). У Вас как-то теория с реальностью не очень дружат.


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 10/11/2011
А ведь действительно. Кому нужна система, да и толку от нее, если события с недостоверным временем ? Можно ли верить
этим параметрам ?


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 10/11/2011
Где эта теория у нас в России уже применена? На какой АЭС? И какие результаты?


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 10/11/2011
Когда вместо красивых фраз и "заумных" речей Вы будете делать то, что сегодня от Вас ждут люди, а не то, что у Вас получается ?  Пора из "дебрей" вернуться к реалиям.


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 11/11/2011
Очень полезная и интересная статья. Хорошо, что во ВНИИАЭС остались еще толковые профи, не все съехали за бугор. А на злопыхателей не обращайте внимание – пакостный и ограниченный народишко.


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 11/11/2011
А В чем польза статьи ??? Поясните. Повторю свой вопрос: "Где именно и на какой АЭС, или другом объекте это применено ?"


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 11/11/2011
Ну польза должна быть в обсуждении проблем системной инженерии, более того применительно к АЭС. Но из статьи видна работа по обработке большого объема информации. Выделенные проблемы весьма банальны и очевидны и без проведения такого анализа. Действительно, реальность сложна и не всегда ее можно однозначно загнать в 'структуру'. Статью бы еще редактировать и редактировать, посмотреть значения терминов и определений, выбрать подходящий, привести его встатье. Убрать противоречия громких фраз по тексту. Привести ее к каму-нибудь единому стилю, да смыслу.


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 11/11/2011
А потом что ?


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 11/11/2011
А потом, решение проблемы. Обычно сначала разрабатывается теория, а потом ищется ей применение. Не все методы и практики системной инженерии применяются на просторах нашей страны. Видно, даже из этой статьи, что проблем и вопросов хватает. 


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 14/11/2011
Для нас (на Волгодонской АЭС Блок 2) сейчас более актуальна проблема метки времени. С момента буска блока уже прошло несколько лет. А проблема привязки метки времени к событиям не решена. Какая польза от такой системы ? Может быть в этой области поискать применение Вашей теории ? Вы то сами как относитесь к этой проблеме ?
Вы бы ее решили, а потом бы искали применение Вашей теории!


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 13/11/2011
Уже после одного этого опуса-откровения от Просвирнова:
"Почему-то считается, что 3-D модель является основной в информационной модели. Действительно, красивая картинка может впечатлить, однако на самом деле самым важным в проекте является оптимальная структура данных проекта, так называемая Plant Breakdown Structure (PBS)."  читать дальше не имеет смысла... Видно, что пишет не практик, и, конечно, не конструктор, который видит и понимает почему работает конструкция, какие в ней температурные поля и напряжения, а методист, читатель ГОСТов. И это всё пишет специалист в энергетике!!! Там, где "железо" подвергается многофакторному воздействию различных полей. Этот горе-инженер, жонглёр стандартов в 3D модели видет только красивую картинку! Может не с теми специалистами в своём ВНИИАЭСе общается? Они только 3D модель как красивую картинку представляют!?


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 13/11/2011
Злой и малосодержательный комментарий. И, чувствуется, комментатор – не системщик. Ограничен железяками и проводами. Не понимает. Жаль человека.


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 14/11/2011
Да! Конечно! Только системщик знает ГОСТы! А давайте пошлём на фиг всех конструкторов, которые понимают как ведёт себя и как чувствует конструкция в железе, в реальных непростых рабочих условиях. Давайте оставим на предприятиях только нормоконтролёров и системщиклов — жонглёров ГОСТов и ИСО-шек.


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 14/11/2011
Призыв статьи к проектантам не рисовать просто 3-Д картинки, как часто сейчас происходит, а именно проектировать в 3-Д с созданием структуры объектов с классификацией и атрибутикой, для автоматизированного  создания спецификации проекта из базы данных и исходных наборов данных  для расчетных кодов по требуемым направлениям (прочность, теплогидравлика, электрика и т.д.) Сейчас все наборы данных расчетных программ создаются вручную расчетчиком, в результате нельзя исключить человеческий фактор ошибки. А. Просвирнов


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 14/11/2011
Ух-ты, Генератор текста уже статьи с картинками выдаёт !


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 18/11/2011
Не плохая обзорная статья! Единственное, что удивляет, так это сослагательное наклонение. Я думал, что ВНИИАЭС как инженер-архитектор эти требования уже реализовывает в ВВЭР-ТОИ, видимо нет, а жаль! А значит опять все пойдет по басне Крылова- Мартышка и очки! Закупят программное обеспечение для 3-D моделирования и будут рисовать картинки, вместо создания модели! Хотя и это движение вперед.

На счет построения WBS у меня и у десятков тысяч специалистов в области управления проектами другое мнение. ИСО 15288 не подходит для создания структуры WBS, потому как описывает процессы жизненного цикла систем. WBS же должна быть ориентирована на результаты, а не на процессы! Это очень важно! Верхний уровень WBS должен быть организован по фазам жизненного цикла проекта. На выходе каждой фазы принимается решение о необходимости продолжения проекта. WBS внутри каждой фазы имеет свою собственную структуру, отличную от другой фазы и очень похожа на структуру получаемого на выходе фазы продукта. Более того, WBS для одной фазы для разных проектов могут отличаться, например от применяемых технологий и методов строительства (монолит- одна структура, легко возводимые конструкции- другая и т.д.)


[ Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 18/11/2011
А разве ВНИИАЭС что-нибудь реальное в состоянии сделать ?
Там только слова, слова, слова,.......


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 20/11/2011
Согласен, впрямую 15288 использовать нельзя. Идея: создать структурированную библиотеку стандартных процессов, из которых набирать требуемые WBS на конкретные работы. К сожалению, мне не знакомо ПО, с помощью которого это можно осуществить, придется создавать. А ИСО 15288 только для структуризации процессов и моделирования жизненного цикла.  А. Просвирнов


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 21/11/2011
"К сожалению, мне не знакомо ПО, с помощью которого это можно осуществить, придется создавать."
Господин Просвирнов, нам — читающим ваши статьи на Proatome, уже давно понятно, что ни системы PLM, ни системы ERP вам не известны.
Хочется верить, что таблица умножения и таблица Менделеева вам известны, иначе у вас впереди — большущая дорога познаний-изучений...
Эх... прощай бюджетные финансы! :-(


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 22/11/2011
Чего это вы так радеете за бюджетные финансы? Неужели не понятно, что они уже давно не ваши. Они уже приватизированы людьми которые уже владеют всей Россией. Посмотрите: Христенко, Голикова, Шойгу, Сердюков, Путин, Медведев,.... Они или их жены миллиардерши, за наш счет. Они бесконтрольны и несменяемы. Смотрите  "Ведомости" за 21 ноября - у них в собственности сотни гектаров земли на каждого, заводы, природные ресурсы. Лужков наворовал и перевел деньги за бугор. И таких сотни. Это и есть Единая Россия. Они нас рассматривают как стадо. А вы: бююджеетные финансы...


[
Ответить на это ]


Re: PBS -углубляясь в дебри системной инженерии (Всего: 0)
от Гость на 22/11/2011
Чтобы провести "реинжиниринг" предприятия, изначально должен быть хороший "инжиниринг" на этом предприятии. А если инжиниринг очень и очень слабый, то как ты его не реинжинируй, хорошего будет мало, вернее, будет только хуже.
Вот попробуйте на основании вашей структуры создать какое-нибудь маленькое, но очень эффективное предприятие или проект или изделие. Докажите, что ваша схема работает, а потом уже говорите как это правильно и эффективно, и предлагайте делать реинжиниринг по работающему примеру.
Очень уж много делается всяких реинжинирингов, реформ, модернизаций и т.д., а результатов, как правило, кроме распила бюджетных средств нет. Хотя, безусловно, описано у вас все правильно и красиво...
 


[ Ответить на это ]






Информационное агентство «ПРоАтом», Санкт-Петербург. Тел.:+7(921)9589004
E-mail: info@proatom.ru, Разрешение на перепечатку.
За содержание публикуемых в журнале информационных и рекламных материалов ответственность несут авторы. Редакция предоставляет возможность высказаться по существу, однако имеет свое представление о проблемах, которое не всегда совпадает с мнением авторов Открытие страницы: 0.11 секунды
Рейтинг@Mail.ru