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





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

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

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

[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


Самая читаемая статья: Кадровая политика:
Синдром эмоционального выгорания

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


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

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

опции

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

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

Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Смысл статьи - при создании сложной системы надо сперва все продумать, создать некую виртуальную модель, а только потом делать в металле. Практика показывает, что так можно проектировать бесконечно долго, но в металле или в бетоне ничего не создашь. Нужны живые незабюрократизированные системы, которые развиваются и меняются в процессе их создания. При стороительстве нового блока АЭС на станции раньше сидела группа из АЭП человек 150-200 и постоянно вносила изменения в проект. И это правильно. Кончно, для менджеров это, как кость в горле, так как эти ребята из АЭП должны иметь соответствующие полномочия. Но по другому ничего не создашь.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Автор - чудак на букву.... Открыл бля америку. Здесь есть понятия :опыт и кругозор!Они и дают системность разработке. А по его алгоритму зашибётесь систему создавать.Ведь ваша цель - оптимизмция.  А по подходу автора для неё не хватит ни финансов ,ни людей ,ни вычислительных мощностей. А,главное, времени. Канешна,если спецов держать не за творцов,а за живых роботов,то тоже херня получится!Это пример с парогенератором. Есть конструктор,который блоху сделал,и левша,который её подковал! А опыт только с работой приходит. Этому хер научишь! Весёлый Боцман


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
"Этому хер научишь! Весёлый Боцман"

Тебя, боцман, точно, ничему не научишь. Ты и так все знаешь, и, как Николай Васильевич Гоголь, сидишь на сосне и всех на буй посылаешь. Присмотревшись к твоим комментариям я понял, что ты больной на голову (явно выраженная мания величия и раздвоение личности) и тебе нечего делать.

Сходил бы к психиатру


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Ты бля советчик! А сколько у тебя законченных разработок? А сколько внедрённых проектов. Таких, чтобы и сегодня работали с пользой7 Я уже 30 лет применяю системное проектирование. У меня 4 внедрённых проекта в АСУТП, и один в АРМ. Так что иди в отсос к своему психиатору. Лапоть! 


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Задолбавший всех Боцман! Человек о твоем психическом здоровье заботится, хочет, чтобы ты создал шестую разработку, а твоя реакция только подтверждает его правоту. Был здоровым - внедрял разработки, а сейчас - продуктивная симптоматика.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Системная инженерия позволяет избавиться от все умеющих боцманов в сторну нормальной командной работы единомышленников, при этом постараться ничего не забыть. Поэтому у буржуев в среднем получается достаточно хорошо. Ну а гениев у нас, конечно, больше... 


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Нормальная командная работа раньше всегда была. Это сейчас её меньше стало.Появились САПРы и АРМы. во тут кое-кто себя бля гением и возомнил. Но опыта нет, и мастырят мастырки. Тем более в атомной энергетике,где база знаний не полна и методы решений не совершенны. Боцманами у этих команд были люди,которые за деревьями лес видели.и всей команде на этот лес глаза открывали. А у буржуев обычно один широко глядит- он главный,а остальные,как кроты,только свою хатку видят. 


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Хорошая статья! "В соответствии опять с разделительной ведомостью в границы главного конструктора включен первый контур с пассивными системами безопасности и не включены активные системы безопасности...". Скажу больше, даже часть напорных трубопроводов активных систем от первого контура до первого запорного органа, включая сварной шов с первым контуром, не включены в границы главного конструктора РУ. Вот, рвется этот трубопровод по сварному шву с ГЦК - это уже не РУ. Такая же ситуация, даже более анекдотичная, со вторым контуром - ПГ и СПОТ - это границы главного конструктора, а соединяющий их паропровод - нет.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 08/07/2011
Забавно и симптоматично, эта статья показывает поверхностное мышление некоторых системных инженеров, а именно то, что по сути в этой статье надергали картинок от разработчика Dassault и даже не подумали указать это в литературе в конце статьи... Решения о Dassault нашли апробацию в основном в гражданской авиации и автомобильной промышленности в части проектирование кузовов автомобилей. Именно такие самолётики показаны на картинках. Для атомной энергетики акценты к ядру геометрического моделирования находятся в иной сфере . Нет необходимости в проектировании поверхностей класса А (как автомобилестроении, в кузовах), а нужен софт, легко манипулирующий масивами пазов, отверстий, трубными массивами, легко создающий и оптимизирующий массивы конструктивных элементов трубных решеток. Тот, кто непосредственно работает в разных CAD'ах, знает, что в таких задачах система CATIA не оптимальна.  Необходимо, чтобы загрузка аппаратной платформы при проектировании таких типовых элементов атомной энергетики была не высока. И тут CAD-система CATIA не представляет оптимальный выбор. Лучше бы авторы описали, как проектируют французы АЭС, используют ли они софт от Dassaut свои новые блоки АЭС, а конкретно блок Олкилуото и французский блок на 1600 МВт э. Почему в Олкилуото расползаются и сроки и цены... Как там с распиаренной с растопыренными пальцами "технологией 6D"? Такие пиар-названия технологий кроме как в Росатоме не используются ни у каких поставщиков CAD-систем. Просто разговор ведут об интеграции систем PLM и ERP, без всяких 6D-пузырей.
Возвращаясь к CAD'у. Тот же функционал CAD-системы для конструкторов объектов атомной энергетики у других поставщиков (не от Dassault) обойдётся заметно ниже. Нужно расссматривать соотношение цена/функционал каждого технологического модуля. Но об этом молчок... Такая же ситуация в части рекомендаций от "системных инженеров" складывается при установке так называемых требований по закупке аппаратных платформ. Приходится ухохатываться, читая рекомендации типовых платформ персональных компьютеров, где обязывают покупать только от фирмы HP. Всем конкретным СПЕЦАМ давно известно, что за эти две буквы приходится чисто конкретно доплачивать. За те же деньги можно купить аппаратную платформу с бОльшей производительностью и с бОльшей длительностью гарантии. Забавно читать такие рекомендации от Росатома, где указаны "типовые рекомендации", где для руководства организаций предписаны компы с бОльшей производительностью, чем для конкретных инженеров и конструкторов. Наверно такие "рекомендаторы"исходят из окладов персонала. Хотя всем известно, что начальству кроме типового софта типа Микрософт Офиса и электронной почты ничего не нужно. А конкретные конструктора и расчетчики должны иметь компы с бОльшей производительностью: больше оперативная память, более производительности процессоров, видеокарт и т.д. Такие "рекомендаторы", вероятно, пришли из банковских и коммерческих структур, а не от инженерно-конструкторских предприятий.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 10/07/2011
Видимо, Вы уже овладели кузовными 3Д моделями, но далее не ходили. А чтобы не путать ИТ-систему с 6Д, посмотрите хотя бы сайт НИАЭП- лидера сегодняшнего дня в инфомоделировании АЭС. Кстати, первый международный стандарт BIM по мультиД для зданий принят всего в 2007 г. Вот чтобы навести порядок в подходах и мозгах, системная инженерия весьма удобна, хотя, как каждое лекарство не всесильна.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 10/07/2011
Далее ходили. И все эти D, начиная с 4-го по 6-ой включительно находятся в функционале ERP-систем. И не надо ничего придумывать, ничего из пальца высасывать.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 10/07/2011
Вы лучше не посылайте в Нижегородский АЭП, а покажите в каких ТЕНДЕРАХ в России, а лучше в Росатоме решения от Dassault выиграли у других поставщиков. Особенно в машиностроительном секторе. НИАЭП только летом прошлого года стал осваивать. Каким плачевным должно быть либо состояния с IT-технологиями в Росатоме либо Ваше их познание, что посылаете знакомиться в фирму, которая лишь год осваивает продукты...


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
Забавно, что пример с DS вызвал такую бурную реакцию. Это только пример, иллюстрирующий подход системной инженерии, встроенной в пакет. Можно было бы привести пример с другим поставщиком, только пока системная инженерия не внедрена у других поставщиков. Статья о системной инженерии, а не о CAD системе, о подходе сначала разработать требования, провести функциональный анализ, провести логическое проектирование и лишь затем начинать чертить в CAD системе, при этом включить параллельное расчетное обоснование, а оно у каждого проекта свое.  Жаль, но каждый раз все скатывается к спору, какой поставщик софта лучше. Не найдете такого. Каждый в чем-то опережает другого, а в среднем все на одном уровне, только используется этот потенциал от силы на 30-40%. А. Просвирнов 


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
"Это только пример, иллюстрирующий подход системной инженерии, встроенной в пакет. Можно было бы привести пример с другим поставщиком, только пока системная инженерия не внедрена у других поставщиков." Вы берёте на себя ответственность отвечать "за всю Одессу"? Именно поэтому, что вы ТАК пишите и понятно, почему как вы сами пишите: "пример с DS вызвал такую бурную реакцию". Вы сами себя разоблачаете. Далее. "Статья о системной инженерии, а не о CAD системе," Если вы не знаете и, главное — не демонстрируете на конкретных примерах отраслевых задач, как реализуются требования, "встроенные в пакет" — что за этим стоит в процессе реализации этих требований, какие, в свою очередь, требования к конструкторам и аппаратному обеспечению выдвигаются пр этом в CAD системе, то не стоит бежать впереди паровоза, пускать пиаровские пузыри и пачкать бумагу, выкладывая картинки с самолётами от Dassault, и не упоминая этого в списке литературы...


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 17/07/2011
Кстати, вот появились свежие откровения от фирмы Dassault тут: http://isicad.ru/ru/press_releases.php?press_num=14520
"Что такое Стабильное развитие инноваций? Это совсем несложно: 3D + 3P (Planet, People, Profit)."
Ну и что? Теперь прогрессивно мыслящие системные инженеры от Росатома и от ВНИИАЭС, в частности, сами не работающие в софте, будут менять концепцию 6D на 3D+3P? :-) Это касается также и проектировщиков из НиАЭПа.
Будут типа "Бежать задрав штаны за комсомолом?" :-)Я это к тому, что от функционала (от печки) плясать надо, а не от рекламных-слоганов — пиар-служб того или иного поставщика.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 09/07/2011
Применительно  к 111 стыку ПГВ=1000М системный подход не работает, как трещал этот стык так и трещит уже много лет...

Ядерщик


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
Автор статьи  http://www.proatom.ru/modules.php?name=News&file=article&sid=2004 высказал гипотезу, что одной из причин отказа 111 шва может быть многоцикловая усталость от повышенной вибрации паропроводов. ГК от этого отмахивается. Но метод системной инженерии - рассматривать все идеи, даже абсурдные на первый взгляд. Сначала собираются все гипотезы, ранжируются по важности и последовательно в соответствии с рангом рассматриваются. Но все рано или поздно. А. Просвирнов 


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


деньги-вот в чем вопрос (Всего: 0)
от Гость на 11/07/2011
Не заморачивайтесь Вы ребята-все крайне просто.Нижегородский АЭП сожрал за годы правления Кириенко кучу денег- настает момент истины-куда же деньги делись? Вот и пытается закупать дорогие системы, напускает мути, хотя у него ...пустота...Эта система может работать только при наличии профессионалов высокого класса, которые рубят фишку по всем системам, чего в АЭПе не было и нет.Вы хоть один комплект чертежей выдайде до начала работы, чтобы было что оптимизировать....У Вас же по 3 и 4 Ростовы фактически до сих пор ничего нет...


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
То, что нынче громко именуюется системным инженером, раньше было "хозяином проекта". Поначалу в атомной отрасли "хозяевами" были научные руководители, которые брали на себя ответственность за полноту незнания.

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

Не правда ли - хороший бизнес был у советских АЭПов?

***

Теперь о том, что же он предлагает. А ничего!

Что PLM, что 6D - это всего-лишь инструмент. Работающий по принципу "машина дура" (trash in - trash out). И прежде чем городить всякие 666D на уровень хозяина проекта, нужно избавить всю цепочку низовых исполнителей от источников "мусора". Процесс - занявший в той же автомобильной отрасли одно конструкторско-технологическо-производственное поколение (типовой срок конвейерной "жизни" автомобильной "платформы" - 10-15 лет).

В этом отношении "революция сверху" от первых лиц Росатома под лозунгом "внедрим 6D и будем в шоколаде" заведомо обречена - если микроскопом и забивают гвозди, то очень не долго. "Авгиевы конюшни" нужно расчищать, а не спорить о стилистике греческих мраморных колонн.

Никакое системное проектирование, никакое 6D "не встанет" там, где "режимщики" не могут обеспечить простых исполнителей не то что "персональным" закрытым каналом для обмена коммерчески-значимой информацией с контрагентом, но и банальном Касперским.

Какое 6D? В половине институтов Росатома до сих пор "каменный век" и нелицензионное ПО?

***

И на последок: тырить чужие слайды - не хорошо.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
тырить чужие слайды - не хорошо ---------------------- Обвинение надо доказывать фактами


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


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


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
К сожалению, происходит путаница со  стадиями жизненного цикла. Технология 6D предназначена только для стадии рабочего проектирования, весь разговор в статье идет о стадии концептуального, может быть частично технического проектирования. Согласен, системная инженерия - это только инструмент, помогающий проектировать сложные объекты. Главным остается "его величество специалист", в голове которого зреют идеи, а системная инженерия только помогает упорядочить хаос идей в стройную картину проекта. 
Глубокое заблуждение, что установка лицензионного ПО исправит ситуацию. Только внедрение новой более продуктивной технологии на базе стандартов, а ПО должно служить только вспомогательным средством. Сейчас весь упор на ПО, и все пытаются подстроить новое ПО под старые технологии, при этом производительность может даже упасть (требуется время на освоение), а затраты возрасти  (стоимость лицензий, консультации и т.д.) А. Просвирнов 


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 12/07/2011
Да при чём тут ПО? А нас "технологии" отношений до сих пор архаичны ("ты начальник - я дурак, ..."). При этом интенсивность труда конкретных исполнителей (да, таки ПО) решательно возросла, а интенсивность труда управляющих цепочек столь же решительно затормозилась.

Поэтому "начальственные" решения по ведомостям разделения, по спецификациям и пр. берутся "из предыдущего проекта", т.к. начальство всё больше увязает в переписке с начальством же.

При этом чисто сервисные подразделения (от режимщиков до бухгалтерии) тоже стали причислять к начальству.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 12/07/2011
"К сожалению, происходит путаница со  стадиями жизненного цикла." И кто эту путаницу организует? Вы, господин Просвирнов, наверняка распутаете эту путаницу! :-) Далее. "Технология 6D предназначена только для стадии рабочего проектирования, весь разговор в статье идет о стадии концептуального, может быть частично технического проектирования." Божественное открытие! Расскажите это поставщикам PLM-систем и технологий! Для начала объясните: в чём отличие технологий PLM-решений от той же Dassault, SIEMENS, PTC и технологий 6D. Значит, говорите, что на одна ТЕХНОЛОГИЯ предназначена для стадии концептуального проектирования, а другая — которая 6D — предназначена уже для рабочего проектирования? :-) Вы, господин Просвирнов, слышали такой тезис — СКВОЗНОЕ ПРОЕКТИРОВАНИЕ? Как Вы собираетесь проектируемый объект из одной ТЕХНОЛОГИИ переносить в другую? У меня создаётся стойкое ощущение, что чем дольше Вам задавать вопросы и Вам отвечать, то Вы быстрее запутаетесь в собственных штанах... :-)
Как говорят в таких случаях в американских детективах: "У Вас есть право не отвечать на вопросы, есть право не свидетельствовать против себя, право на адвоката..."  :-) Причина такого запутывания в собственных штанах проста — ВНИИАЭС серьёзным проектированием не занимался. Работайте над анализом эксплуатации! ВНИИАЭС это не конструкторская и не проектная организация. Но, видно, что побалагурить, почудить на этой почве там хотят. :-) Особенно, если на это перевести денежные потоки... Господин Просвирнов, мало читать стандарты системной инженерии. Крайне важен фактор личной работы в тех продуктах, в тех системах, которые Вы упоминаете в Вашей статье. И важен также личный опыт работы в различных системах! Чтобы не быть филиалом пиар службы одной фирмы. Зацикленность на установившуюся по той или иной причине... связь с одним поставщиком делает мировоззрение уязвимым. Тогда и вилять не придётся в ответах.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 13/07/2011
Опять путаница у Вас в понятиях. PLM-решение реализовано и в продуктах DS (это Enovia MatrixOne), и в SIEMENS PLM Software (это Teamcentre), и в PTC (это  CREO, ранее Windchill), и наверняка  вами любимом Intergraph (это SmartPlant Foundation). Кстати у Intergrapha есть специализированный пакет для концептуального проектирования SmartPlant Layout и это совершенно не мешает осуществлять "сквозное проектирование". В статье четко указано, что это только пример, иллюстрирующий подходы системной инженерии. Размер статьи не позволяет привести примеры всех поставщиков, но мне почему-то думается, что приведи я пример со SmartPlant Layout, с Вашей стороны не было бы таких острых выпадов.Прочитайте более внимательно статью, там ясно написано, что результат стадии создания системной архитектуры является базой для разработки следующих стадий (см. Рис. 4). Вся суть в базе знаний, которая обогащается от стадии к стадии. Ничего не выбрасывается. Упор в статье сделан на то, что эта стадия у нас не выполняется и судя по Вашим репликам Вы тоже резко против выделения стадии создания системной архитектуры. 
Впечатляет Ваш упрощенный подход к миру, в котором Вы всех разделяете на 2 лагеря: имеющих право проектировать и не имеющих это право. Но позвольте, мы и не замахиваемся на Ваше "святое" рабочее проектирование. Отказывать же эксплуатирующей организации на стадии создания системной архитектуры учесть многолетний опыт эксплуатации крайне неразумно с Вашей стороны. А читать стандарты надо, хоть Вам этого и не хочется, в них весь накопленный положительный опыт. С  уважением, А. Просвирнов (извините, не знаю Вашего имени и отчества)


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 13/07/2011
Господин Просвирнов, меня уже не удивляет то, что Вы не отвечаете на прямые поставленные ранее Вам вопросы. К примеру, на этот: " в чём отличие технологий PLM-решений от той же Dassault, SIEMENS, PTC и технологий 6D?" Далее. "PLM-решение реализовано и в продуктах DS (это Enovia MatrixOne), и в SIEMENS PLM Software (это Teamcentre), и в PTC (это  CREO, ранее Windchill)". Во первых, CREO это ранее Pro/ENGINEER. Так что — садитесь — два! Изучайте матчасть! Во-вторых, повторяю: Вы заметили, что Вы так и не ответили: в чём отличие PLM-технологий и технологий 6D! Сообщите общественности однозначно: в каких продуктах , в каких модулях близкой Вам фирмы Dassault реализовано это 6D. Кстати, мы все будем очень Вам любезны, если Вы продемонстрируете как в рекламных буклетах от самой Dassault (!) ясно и чётко объяснены эти 6D-технологии. Ждёмс! Далее. "и наверняка  вами любимом Intergraph (это SmartPlant Foundation)". Вы не угадали. лично мне не нравятся продукты от Intergraph. Но тут не обо мне дело, а о Вас, разместившем статью, а по сути — плавающем в теме... "но мне почему-то думается, что приведи я пример со SmartPlant Layout, с Вашей стороны не было бы таких острых выпадов." Ещё раз расстрою Вас: я не сторонник слепого копирования везде не проверенных на конкретных отраслевых задачах и не оцененных по критерию функционал/стоимость продуктов той или иной (любой!) фирмы...
"Вся суть в базе знаний, которая обогащается от стадии к стадии. Ничего не выбрасывается. Упор в статье сделан на то, что эта стадия у нас не выполняется и судя по Вашим репликам Вы тоже резко против выделения стадии создания системной архитектуры. " Ещё раз не угадали. Я за "мир во всём мире" и, разумеется, за так называемые базы знаний. Но я в отличии от Вас постарался то или иное ЗНАНИЕ реализовать в той или иной системе и немного подумать и СРАВНИТЬ как это делается в РАЗЛИЧНЫХ системах, что за этим стоит и сколько это стоит... Чтобы это не было банальным накопление версий файлов  различных стадий разработки того или иного оборудования.
"Впечатляет Ваш упрощенный подход к миру, в котором Вы всех разделяете на 2 лагеря: имеющих право проектировать и не имеющих это право." Судя по Вашим плавающим ответам, незнанию продуктов, я лично не доверил бы Вам проектировать даже собственную дачу, баню и т.д. "Но позвольте, мы и не замахиваемся на Ваше "святое" рабочее проектирование." Вы заметили, что Вы так и не ответили на вопрос, как будете передавать объекты из концептуального проектирования, реализованного на одной технологии в рабочее проектирование, реализованное на другом? Не кажется Вам такое лоскутным принципом?
"Отказывать же эксплуатирующей организации на стадии создания системной архитектуры учесть многолетний опыт эксплуатации крайне неразумно с Вашей стороны."
Отказывают Вам на основе того, что Вы не демонстрируете чёткого понимания сути вопросов по понятной причине — отсутствия собственной работы в конкретных продуктах при реализации конкретных задач Росатома — показываете самолёты... Да и путаетесь в названиях мировых поставщиков.
"А читать стандарты надо, хоть Вам этого и не хочется, в них весь накопленный положительный опыт." Никто не против стандартов. Только я Вам замечу, что начитанный специалист по стандартам, к примеру, нормоконтролёр, автоматически не становится знающим и талантливым конструктором.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 13/07/2011
Извиняюсь что встреваю в дискуссию. Просто интересно узнать что проектирует оппонент г-на Просвирнова? Судя по комментариям, он спроектировал чтото очень серьезное. Может быть даже атомную станцию. Без ошибок, в срок, дешево, без наоушений и т.д.. Ну просто очень интересно ))) 


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


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


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 13/07/2011
Начну с того, то общее у нас.
1. Я согласен, что надо накапливать знания.
2. Я согласен, что нужны какие-то стандарты системной инженерии и нужно следовать им.
3. Я согласен, что нужно использовать соответствующее матобеспечение.
Можно ещё добавить, что "чтобы хорошо жить надо хорошо работать." Это все согласия в банальных вопросах. На этом можно и остановиться.
А вот в частностях, которые я задал Вам, господин Просвирнов, в конкретных вопросах, наверняка есть отличия. Но Вы на них не ответили. А в некоторых моментах просто плавали. Раз Вы не знаете конкурентов тех решений, которые сами предлагаете (конкурентов Dassault), значит Вы не готовы к серьёзным предметным обсуждениям. Вы не знаете рынка! Но статью, тем не менее, пишите... Вы не демонстрируете решения типичных задач для проектирования оборудования энергетического машиностроения. Вы не знаете конкретики продуктов. Вам, похоже, достаточно, что Вам принесла что-то тем или иным способом подвернувшаяся Вам фирма.
Вы в одном из сообщений вначале пишите: "Можно было бы привести пример с другим поставщиком, только пока системная инженерия не внедрена у других поставщиков" И чуть далее в этом же сообщение — реверанс: "Жаль, но каждый раз все скатывается к спору, какой поставщик софта лучше. Не найдете такого. Каждый в чем-то опережает другого, а в среднем все на одном уровне, только используется этот потенциал от силы на 30-40%." Кого Вы оценивали, когда писали "а в среднем все на одном уровне"? Вы изучили всех? Или писали, стоя перед зеркалом? :-) Спотыкаетесь даже на названиях продуктов...


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 14/07/2011
Пушкин тоже Байрону подражал...
Правда, господин хороший, надо конструктивно дискутировать, а то создается впечатление, что в вас клокочет наболевшая невысказанная зависть.

Дурак Дураковский


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 14/07/2011
Были заданы КОНКРЕТНЫЕ вопросы. Но вместо ответов получены рассуждения, в которых начало фразы противоречило её же окончанию.
Зависть к некомпетентности и неосведомлённости? Это что-то новое. Наверно это из жизни дураков... :-)


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 14/07/2011
Ждем от Вас статью, в которой должны быть освещены следующие вопросы и проблемы:1. Анализ рынка и конкурентов DS в особенности. Ваши предпочтения. 2.Описание Вашего подхода и его отличительных особенностей от предложенного подхода.3. Какими методами и  каким ПО Вы управляете требованиями?4. Как проводите функциональный анализ и логическое проектирование, как устанавливаете связи между этими объектами?5. По какому принципу строите Plant Breakdown Structure?6. Продемонстрируйте решения типичных задач для проектирования оборудования энергетического машиностроения.Думаю достаточно на первый раз. План Вашей статьи готов. Вам осталось только его наполнить текстом, а редакция Проатома никому не отказывает в публикации. Ждем...С уважением, А. Просвирнов


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 14/07/2011
Ума не приложу, почему именно Вы, господин Просвирнов, не начали именно с этих вопросов. Или это уже где-то Вами выполнено? Или выполнено, но не Вами? Тогда ссылочку можно? Сам писать не буду, дел много. Такая статья требует серьезных вложений труда. Бесплатной быть она не может. Если она объективна и равноудалена от конкурирующих поставщиков, то будет стоить много, будет весьма полезной для потребителей. Развернутую информацию — конкретную от поставщиков будет трудно вытащить (особенно из Dassault), чтобы четко обрисовать функционал каждого необходимого (обоснованно необходимого) модуля для тех или иных задач. Но, полагаю, раз ВНИИАЭС пытается перетащить на себя денежные потоки в части проекта так называемой по виртуальной АЭС, то её системные инженеры просто обязаны это сделать... Хотя наиболее глубоко эти анализы и результаты конкретных работ в обоснованно типовых задачах для энергомашиностроения могут сделать только конструктора, реально работающие с программными продуктами и освоившие их глубоко, а также постоянно мониторящие мировые тренды в этой сфере. Ну а системным инженерам приходится только шелестеть исошными стандартами и нанизывать подвернувшиеся рекламные буклеты той или иной фирмы... :-)


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 09/08/2011
Уважаемый комментатор ("Ума не приложу...." - другого НИКа нет), предлагаю вам связаться со мной по тел. 8-921-9589004. Есть деловое предложение по статье. Олег Двойников Гл. ред.


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 11/07/2011
Статья перекликается со статьей Е.Г. Гашо "Общие принципы управления техногенными рисками в энергосистемах".

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

Когда будет понятно, каким образом может выживать и развиваться энергосистема страны, тогда появятся требования к АЭС и другим ЭС и станет понятно: что и где мы должны или не должны создавать. А сейчас проектировать то, что заранее никому не нужно - это разбазаривание ресурсов и не более того.

С автором согласен в том, что нужна новая культура в процессе проектирования. Но где ее взять? Она от сырости не появится...

С уважением...


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


Re: Системная инженерия – миф или ключ к эффективности (Всего: 0)
от Гость на 07/09/2017
Системная инженерия [systems-analysis.ru] —междисциплинарный подход и средства для обеспечения реализации успешных систем (International Council on Systems Engineering, INCOSE).
Системная инженерия [systems-analysis.ru]—междисциплинарный подход, определяющий полный набор технических и управленческих усилий, необходимых для преобразования совокупности потребностей и ожиданий клиента и имеющихся ограничений в решение и для поддержки этого решения на протяжении его жизни (ISO/IEC/IEEE 24765:2010).
Назначение системной инженерии заключается в руководстве разработкой сложных, комплексных систем. Система определяется как совокупность взаимосвязанных компонентов, которые работают совместно для достижения общей цели. Комплексная инженерно-насыщенная система состоит из нескольких разнородных, разнотипных элементов, которые связаны между собой сложным образом и требует применения системной инженерии для руководства разработкой.



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






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