Моделеориентированная системная инженерия реферат

Обновлено: 30.06.2024

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

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

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

При этом, надо отметить, что хотя визуализация моделей и является важным аспектом, ее проблемы более-менее разрешены и в рамках обычной инженерии - существует куча всяких САПРов и CADов. Поэтому для системной инженерии, ключевым вопросом являются формальные модели, с целью исполнения их на компьютере.

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

Связь с онтологиями

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

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

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

Онтологические языки

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

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

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

Первопорядковые логики

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

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

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

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

Особенности логического моделирования

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

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

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

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

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

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

Однако, при массовом использовании моделей (как раз вероятный сценарий моделеориентированной системной инженерии) вероятность появления таких несовместимостей при комбинировании моделей растет с большой скоростью. Что уже представляет собой серьезный риск.

Конструктивные логики

Один из способов решения этой проблемы - использования конструктивных логик. Часто проблемы неконсистентности вызваны использованием классической аксиомы исключения третьего A \/ ~A совместно с какой-то другой аксиомой. Использование этой аксиомы позволяет доказывать строго больше утверждений, чем при ее отсутствии. Однако, по доказательствам, возможным без участия этой аксиомы, можно построить алгоритм реализующий данную модель - так называемые конструктивные доказательства. Интуитивно, можно получить неконструктивное доказательство благодаря тому, что какое-то утверждение неверно (приводит к противоречию). Тогда, согласно закону отрицания третьего, можно вывести что верно обратное утверждение.

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

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

Современное употребление слова "модель" по смыслу размыто не меньше, чем его обобщение -- "описание". Когда мы пишем "моделе-ориентированная системная инженерия" (model-based systems engineering, MBSE, http://www.incose.org/newsevents/news/details.aspx?id=151), то можно прочесть и как "описание-ориентированная системная инженерия". Но ведь любая инженерия описание-ориентирована, так как в самой ее основе лежат описания: тексты, чертежи, диаграммы, графики, формулы и т.д.. Зачем вводить новый термин для привычной практики, и подчеркивать, что это будущее системной инженерии?

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

Ключевая характеристика моделе-ориентированной системной инженерии -- это поддержка одновременного использования множества методов описания (viewpoints), т.е. одновременного применения множества методов моделирования для получения множества групп описаний (views), которые адресуют различные интересы соответствующих заинтересованных лиц.

Главное достоинство MDA -- это множество уровней абстракции (иерархия уровней метамоделирования) и множество обеспечиваемых метамоделями методов описания с прописанными правилами соответствия методов описаний (viewpoint correspondence rules). Главный недостаток MDA -- это ограниченность этой архитектуры языком UML. Почему UML является недостатком? Потому что в междисциплинарном проекте мы не можем ожидать, что все специалисты-пользователи говорят на UML или SysML, даже если мы расширим эти языки специфичными для предметных областей стереотипами.

В то же время в программной инженерии образовалась и быстро растет другая ветвь модельного движения, которая связана с понятием предметно-специфичного языка (DSL, domain-specific language), обеспечивающего применяемый экспертами метод описания для получения предметно-специфичной группы описаний. DSL объединяет (концептуальную) метамодель и (графическую и/или текстовую) нотацию. Это отличается от MDA, в которой предписываются нотации и метамодели, основанные только на MOF/UML. Тем самым программисты должны обеспечивать отдельную интерактивную среду разработки (IDE, interactive development environment) для каждого DSL, а затем эксперты-непрограммисты будут использовать эти предметно-специфичные IDE для моделирования их систем.

Все САПР могут быть рассмотрены как наборы таких IDE для инженерных предметно-специфичных языков (например, диаграмм P&ID для моделирования гидравлических систем). Если мы хотим создать модель завода непрерывного цикла (например, нефтеперерабатывающего завода), то предстоит трудный выбор между моделированием гидравлических систем в MDA/SysML и традиционным P&ID-моделированием. Предметно-специфические языки современных САПР легко выигрывают. Но потом мы все равно должны объединить все эти несовместимые между собой модели на разных DSL в одну связанную модель завода.

У нас есть две возможности предоставить такую связанность для зоопарка различных DSL: 1. Онтологическое совмещение (mapping) метамоделей различных DSL, и тем самым совмещение моделей в датацентрическом репозитории моделей. 2. Использование языковых рабочих мест (language workbenches).

Языковые рабочие места -- это новые IDE, специально посвященные созданию связанных наборов DSL (http://martinfowler.com/articles/languageWorkbench.html). Эту парадигму для разработки программных средств пробуют сейчас не слишком много разработчиков (http://martinfowler.com/bliki/IntentionalSoftware.html). Разработка "языконезависимого интерпретатора/компилятора" и "языконезависимого (в т.ч. графического) редактора" является очень сложной задачей. Зато перспективы очень заманчивы: каждый эксперт-непрограммист может получить собственный кастомизированный (инженерный, финансовый, управленческий и т.д.) DSL, и все эти DSL, адресующие множество различных интересов заинтересованных сторон, будут работать совместно. Более того, эти отдельные обеспечивающие разделение интересов (separation of concerns) описания далее могут обрабатываться различными способами и для различных нужд: проверяться на непротиворечивость, транслироваться на выходные языки, используемые затем заводскими обрабатывающими инструментальными центрами, транслироваться в исполняемые имитационные модели и т.д.. Благодаря свободе выбора языков, это может быть лучше, чем MDA/UML (или MDA/SysML), и так же предотвращать потерю связности общей модели. Сейчас это движение исключительно программистов, системные инженеры не знают об этом DSL-тренде в целом и тренде разработки языковых рабочих мест в частности.

Системная инженерия может, как обычно, ждать 10 лет до заимствования из программной инженерии этих новых подходов к моделированию, или начинать экспериментировать с новыми технологиями немедленно. Моделеориентированная системная инженерия не должна быть синонимом SysML-ориентированной системной инженерии. SysML -- это только отправной пункт для моделеориентированной системной инженерии, а не пункт назначения.

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

Со времен внедрения цифрового макета процесс проектирования не менялся, а только выверялись и улучшались рабочие процессы. Даже использование идеальных процессов в САПР давало минимальный прирост функциональности и эффективности. Оказалось, что выпустить изделие более высокого класса с использованием традиционного подхода становится довольно сложной задачей. Теперь от производителей требуется учитывать пожелания каждого клиента, сохраняя при этом минимальную стоимость изготовления. Компании перестали укладываться в сроки и бюджеты, а также не всегда могут достичь заложенных в технических заданиях характеристик. И производители осознали, что необходим качественный скачок на более высокий уровень проектирования. Изменение подхода позволит им гарантировать получение того результата, который они задумали.

Модельно-ориентированная системная инженерия

Серьезное развитие программного обеспечения для управления жизненным циклом изделия Product Lifecycle Management (PLM) позволило компании Dassault Systèmes создать новый подход к проектированию, который называется модельно-ориентированная системная инженерия — Model-Based Systems Engineering или сокращено MBSE. MBSE — это принципиальное изменение подхода к разработке изделия с этапа создания моделей и до проектирования. И эти модели непосредственно влияют на полученный результат.

Подход к проектированию MBSE опирается на процессы управления жизненным циклом изделия — (Product Lifecycle Management (PLM), а не заменяет их. MBSE — это скачкообразный рост в процессном подходе проектирования, который не обновлялся в течении последних нескольких десятилетий.

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

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

При модельно-ориентированном подходе генеральный конструктор оформляет свои идеи в моделях, и передает их в конструкторский отдел

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

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

Преимущества MBSE-подхода

Цифровые двойники

MBSE-подход позволяет перенести процесс выявления недостатков и несоответствий на более ранние этапы проектирования

\u042d\u043a\u043e\u043d\u043e\u043c\u0438\u044f \u0432\u0440\u0435\u043c\u0435\u043d\u0438: \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u0435 \u0441\u0440\u043e\u043a\u043e\u0432 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438\u0437\u0434\u0435\u043b\u0438\u044f, \u0441\u043e\u043a\u0440\u0430\u0449\u0435\u043d\u0438\u0435 \u0441\u0440\u043e\u043a\u043e\u0432 \u0432\u044b\u0432\u043e\u0434\u0430, \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0435 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u043c\u0435\u043d\u044f\u044e\u0449\u0438\u043c\u0438\u0441\u044f \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u043c\u0438 \u0438 \u043f\u0440\u043e\u0441\u043b\u0435\u0436\u0438\u0432\u0430\u0435\u043c\u043e\u0441\u0442\u044c \u0432\u0437\u0430\u0438\u043c\u043e\u0441\u0432\u044f\u0437\u0435\u0439 \u043e\u0442 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u0434\u043e \u0442\u0440\u0435\u0445\u043c\u0435\u0440\u043d\u043e\u0439 \u0433\u0435\u043e\u043c\u0435\u0442\u0440\u0438\u0438, \u043c\u0438\u043d\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u043f\u0435\u0440\u0435\u0434\u0435\u043b\u043e\u043a \u0437\u0430 \u0441\u0447\u0435\u0442 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u044f \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u043d\u0430 \u043f\u0440\u043e\u0442\u044f\u0436\u0435\u043d\u0438\u0438 \u0432\u0441\u0435\u0433\u043e \u0446\u0438\u043a\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438.

\u041f\u043e\u0432\u044b\u0448\u0435\u043d\u0438\u0435 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0430: \u0431\u043e\u043b\u0435\u0435 \u0442\u0435\u0441\u043d\u043e\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u0435 \u0441 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430\u043c\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0435 \u0438\u0437\u0434\u0435\u043b\u0438\u0435 \u0441 \u0437\u0430\u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0438\u0441\u0442\u0438\u043a\u0430\u043c\u0438 \u0438 \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u043d\u0435\u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0439 \u0437\u0430 \u0441\u0447\u0435\u0442 \u0438\u0441\u043f\u044b\u0442\u0430\u043d\u0438\u0439 \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0440\u0435\u0434\u0435.

\u0414\u043e\u0441\u0442\u0438\u0436\u0435\u043d\u0438\u0435 \u0422\u0422\u0425: \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u044f \u0422\u0422\u0425 \u0437\u0430 \u0441\u0447\u0435\u0442 \u0440\u0430\u043d\u043d\u0435\u0433\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043e\u0442\u043a\u043b\u043e\u043d\u0435\u043d\u0438\u0439 \u043e\u0442 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043c\u0435\u0436\u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u0430\u0440\u043d\u043e\u0433\u043e \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f\u043c\u0438 \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u044f\u043c\u0438 \u043d\u0430 \u0432\u0441\u0435\u043c \u0436\u0438\u0437\u043d\u0435\u043d\u043d\u043e\u043c \u0446\u0438\u043a\u043b\u0435 \u043f\u0440\u043e\u0434\u0443\u043a\u0446\u0438\u0438.

\u041d\u0430\u043a\u043e\u043f\u043b\u0435\u043d\u0438\u0435 \u0437\u043d\u0430\u043d\u0438\u0439: \u043c\u0435\u0442\u043e\u0434\u044b \u0438 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0430, \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0438\u0441\u0442\u0438\u043a \u0438 \u0441\u0442\u043e\u0438\u043c\u043e\u0441\u0442\u0438 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438, \u043d\u0430\u0440\u0430\u0449\u0438\u0432\u0430\u043d\u0438\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438\u043d\u0442\u0435\u0433\u0440\u0430\u0446\u0438\u0438 \u0441\u0438\u0441\u0442\u0435\u043c \u0432 \u0435\u0434\u0438\u043d\u043e\u0439 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 \u0436\u0438\u0437\u043d\u0435\u043d\u043d\u043e\u0433\u043e \u0446\u0438\u043a\u043b\u0430 \u043f\u0440\u043e\u0434\u0443\u043a\u0446\u0438\u0438, \u043f\u043e\u0432\u0442\u043e\u0440\u043d\u043e\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0437\u043d\u0430\u043d\u0438\u0439 \u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043d\u0430 \u0435\u0434\u0438\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0435. ","append":"">">

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

Повышение качества: более тесное взаимодействие с заказчиками, а также возможность разрабатывать надежное изделие с заданными характеристиками и обнаружение несоответствий за счет испытаний в виртуальной среде.

Достижение ТТХ: обеспечение соответствия ТТХ за счет раннего определения отклонений от требований, а также междисциплинарного управления изменениями и конфигурациями на всем жизненном цикле продукции.

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

Преимущества MBSE-решений

Управление требованиями

В платформе 3DEXPERIENCE при использовании MBSE-подхода к проектированию основное внимание уделяется как раз выявлению и управлению требованиями. Одно из недавних исследований показало, что причина провала в разработке продуктов в 62,5% случаев была связана недостатками в этой сфере. Иными словами, лица, принимающее конструкторские и технологические решения, не обладает полной информацией. Вторая по значимости проблема заключалась в представлении требований. Хранение на разных носителях, например, на бумаге, в файлах формата Word или Excel и т. д., а также представление в виде текста, таблиц, графиков приводит к тому, что затрудняет поиск и анализ взаимосвязей между требованиями и другими моделями.

Западные гиганты уже оценили MBSE

Хорошим примером внедрения MBSE-подхода для проектирования считается разработка дальнемагистрального самолета A350 XWB, реализованная Airbus. Это самолет был создан с учетом потребностей авиакомпаний и пассажиров, начиная с показателей топливной эффективности, эргономики салона и заканчивая системой развлечений на борту.

Для этого Airbus внедрил решения Dassault Systèmes для совместной работы по всей цепочке создания самолета — от проектирования до производства.

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

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

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

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

Такие взаимоотношения между компонентами системы означают, что система представляет собой больше, чем простая сумма ее частей — она имеет свойства, принадлежащие только системе в целом. Такие свойства называют производными или возникающими.
Примеры производных свойств:
надежность системы (зависит от надежности компонент системы и связей между компонентами),
удобство использования системы (помимо ПО и аппаратуры, зависит также от операторов системы и от окружения).

Вложенные файлы: 1 файл

21.docx

Системная инженерия (systems engineering) — это процесс определения, проектирования, реализации, тестирования, внедрения и поддержания систем в целом. Системным инженерам по долгу службы приходится сталкиваться с ПО, аппаратурой и взаимодействием системы с пользователями и собственным окружением.

Система — это продуманный набор связанных компонент, работающих вместе для достижения некоторой цели.

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

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

Примеры производных свойств:

надежность системы (зависит от надежности компонент системы и связей между компонентами),
удобство использования системы (помимо ПО и аппаратуры, зависит также от операторов системы и от окружения).

Для системных программистов необходимо какое-то знание вопросов CBSE, так как ПО приобретает все большее и большее значение в реальных системах. Например, в американском проекте Apollo 1969 года потребовалось всего 10 мегабайт кода для того, чтобы поддержать аппаратуру при полете на Луну. Сегодня же программное обеспечение американского орбитального комплекса составляет 100 мегабайт. Поэтому системное программирование становится критичным для успеха всей системы.

Что дает системная инженерия

8% затрат на внедрение сиcтемной инженерии дают выигрыш в 20% стоимости проектов, и на 50% увеличивают вероятность окончания проекта в срок.

Это достигается через

А) введение общего языка, описывающего проект

Б) сознательный сдвиг усилий на ранние стадии проекта, где цена ошибки экспоненциально меньше

Стадия обнаружения ошибки

Коэффициент стоимости ошибки

x1 (единица отсчета)

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

Фокусируется (при постоянном внимании к охвату проблемы во всей полноте):

- на определении нужд пользователей и требуемой функциональности на ранних стадиях цикла разработки,

- на документирования требований,

- на синтезе дизайна системы,

- на подтверждении соблюдения пользовательских требований

Описывает процесс разработки систем и как бизнес-процесс, и как технический процесс

Охватывает стадии жизни систем от появления замысла до вывода из эксплуатации

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

Внедряет в практику организации ряд ключевых идей системной инженерии:

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

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

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

Охватывает полный цикл жизни (например: замысел, разработка, производство, использование, поддержка и вывод из эксплуатации).

Учитывает необходимость контрактации (приобретения и поставки продуктов и услуг).

Включает в процессы людей, оборудование, компьютеры, софт (ссылается на связанный стандарт ISO 12207 – жизненный цикл софта).

Применяется параллельно, итеративно и рекурсивно для различных частей системы.

Учитывает особенности композиции любых систем – встроенных, автономных, интегрированных и любых других, сложных и простых.

Жизненный цикл информационной системы — период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации.

Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Полный жизненный цикл информационной системы включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае жизненный цикл можно в свою очередь разбить на ряд стадий. В принципе, это деление на стадии достаточно произвольно. Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational Software – одной из ведущих фирм на рынке программного обеспечения средств разработки информационных систем (среди которых большой популярностью заслуженно пользуется универсальное CASE-средство Rational Rose).

Стадии жизненного цикла:

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

На стадии уточнения проводится анализ прикладной области, разрабатывается архитектурная основа информационной системы.

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

В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных факторов риска в проекте.

3) Стадия конструирования

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

4) Стадия передачи в эксплуатацию

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

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

Стандарты жизненного цикла :

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

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission )1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Читайте также: