WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 | 5 |   ...   | 10 |
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования СЕВЕРО-ЗАПАДНЫЙ ГОСУДАРСТВЕННЫЙ ЗАОЧНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ О.В. АФАНАСЬЕВА Е.С. ГОЛИК Д.А. ПЕРВУХИН ТЕОРИЯ И ПРАКТИКА МОДЕЛИРОВАНИЯ СЛОЖНЫХ СИСТЕМ УЧЕБНОЕ ПОСОБИЕ САНКТ-ПЕТЕРБУРГ 2005 2 Утверждено редакционно-издательским советом университета.

УДК 681.518:629 Афанасьева О.В., Голик Е.С., Первухин Д.А. Теория и практика моделирования сложных систем: Учеб. пособие. – СПб: СЗТУ, 2005. – 131--- с.

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

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

Учебное пособие соответствует требованиям Государственного образовательного стандарта высшего профессионального образования по направлению подготовки магистра 553000 – «Системный анализ и управление».

Рецензенты: В.Е. Марлей, док. техн. наук, проф., зам. директора СПИРАН; А.А. Кондратьев, док. техн. наук, проф., директор института экономики и управления транспортными системами АГА.

© Северо-Западный государственный заочный технический университет, 2005 © Афанасьева О.В., Голик Е.С., Первухин Д.А., 2005 3 Предисловие Дисциплина «Теория и практика моделирования сложных систем» является основой для ряда дисциплин: «Теория и методы учета неопределенности функционирования сложных систем», «Методы научных исследований технических и социально-экономических систем».

Указанную дисциплину изучают на первом курсе подготовки магистра по направлению 553000 – «Системный анализ и управление». Теоретической базой для освоения являются материалы дисциплин «Системное моделирование», «Математические методы системного анализа и теории принятия решений».

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

Учебное пособие предназначено для студентов первого курса подготовки магистра 553000 – «Системный анализ и управление», а также для выполнения магистерских диссертаций.

Введение Известно, что сложные системы как класс могут быть разбиты на следующие типы [12]: технические; экономические; биокибернетические;

социальные.

Для системных исследований состояния всех вышеперечисленных типов систем существует теория управления сложными информационными системами, основоположником которой является д-р тех. наук, проф.

Мартыщенко Л.А. [11,12].

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

В главе 1 настоящего пособия дается общая характеристика проектирования сложных систем.

В главе 2 рассматриваются основные методы математического моделирования сложных технических объектов, представимых в виде многомассовых систем.

В главе 3 приводятся методы статистического моделирования.

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

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

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

1. ОСНОВЫ ПРОЕКТИРОВАНИЯ ТЕХНИЧЕСКИХ СИСТЕМ 1.1. Этапы жизненного цикла технических систем и их содержание Отрезок времени от появления общественной потребности и зарождения идеи создания технической системы до ее отмирания (забывания системы) называют жизненным циклом (ЖЦ). Жизненный цикл любого технического объекта, например подвижных объектов, состоит из четырех основных стадий (рис.1.1) [11,16]: концептуальное проектирование, техническое проектирование, производство и эксплуатация.

Каждая из этих стадий, в свою очередь, состоит из отдельных этапов.

Этапы технического проектирования и содержание выполняемых на них работ строго определены ГОСТом, чего нельзя сказать про другие стадии.

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

На стадии концептуального проектирования определяется необходимость и принципиальная возможность (осуществимость) создания конкретной системы; вырабатываются цели и критерии ее применения и проектирования;

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



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

Xl(,rl ) Анализ проблемы Формирование внешнего Концептуальное облика проектирование Обоснование ТТХ Разработка ТЗ Техническое предложение Аванпроект Техническое Эскизный проект проектирование Технический проект Рабочий проект Технологическая подготовка производства Изготовление Производство Комплексирование Упаковка, складирование Внедрение в эксплуатацию Целевое применение Время Модернизация Снятие с эксплуатации Эксплуатация Утилизация Забывание системы Рис. 1.1. Жизненный цикл технического объекта На стадии производства производится технологическая подготовка производства, изготовление, сборка, настройка, заводские испытания и складирование.

На стадии эксплуатации производится доставка системы, ввод ее в эксплуатацию, эксплуатация, модернизация (с последующей эксплуатацией) и, наконец, снятие с эксплуатации.

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

Изложенные выше общие соображения относительно жизненного цикла относятся к любым системам.

1.2. Процесс проектирования систем В общих чертах процесс проектирования систем имеет две ветви (рис.1.3).

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

Проблема Готовая система Анализ проблемы Порождение, оценка и Система выбор Настройка и математических варианта испытания моделей Разработка Комплексирова техн. задания ние Проектирование, приобретение, ТЗ на компоненты изготовление и настройка Компоненты Нижележащий уровень проектирования Рис. 1.3. Процесс проектирования систем Процесс технического проектирования отличается от концептуального проектирования тем, что начинается с анализа ТЗ на данную систему, а заканчивается разработкой частных ТЗ на подсистемы (п/c). Следовательно, при техническом проектировании имеют дело сразу с тремя уровнями иерархии системы: надсистемой, системой и подсистемой.

Эта схема отражает принцип проектирования «сверху-вниз», когда более крупная система (задача) разбивается на ряд более мелких, объем которых может охватить один человек. Таким образом, процесс проектирования разбивается на уровни, соответствующие уровням иерархии системы, и называется блочно-иерархическим. Этот процесс является итеративным, причем циклы существуют как внутри каждого уровня, так и между ними [13,14,15].

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

Однако удачной альтернативы блочно-иерархическому подходу нет.

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

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





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

Т Без ЭВМ Время полезной Время жизни проектирования ЭВМ САПР t Древние Прошлый Современность Ближайшее века век будущее Рис. 1.4. Зависимость времени полезной жизни времени и проектирования при создании новых современных вычислительных технических систем (СВТС) Все вышеизложенное в полной мере относится и к комплексам управления ПО, проектирование которых дополнительно характеризуется неповторимостью и уникальностью, так как создание каждого нового КУ (а фактически, нового поколения подвижных объектов) осуществляется на базе новых идей, подходов и технических средств.

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

Увеличение общего времени проектирования связано с ростом сложности систем. Если для ПО второго поколения оно составляло 4…5 лет, то для третьего поколения – 7…8 лет, а для четвертого – уже более 10 лет. Это ведет к тому, что к моменту ввода системы в эксплуатацию она оказывается морально устаревшей.

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

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

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

Классическая теория управления, базирующаяся на дифференциальном исчислении, имеет дело с относительно простыми и устойчивыми структурами при вполне определенных внешних условиях. Ее методы оказываются непригодными при разработке средств управления ПО потому, что на начальной стадии проектирования разработчик оперирует с весьма общими понятиями в терминах предметной области. Для этого нужны новые, более выразительные языковые средства. Невыразительность и трудность одновременного описания структуры системы и логико-динамических процессов ее функционирования ограничивают применение теории множеств и методов математического программирования [14]. Языки ситуационного управления [13] хорошо отражают семантику предметной области и логику функционирования ПО, но мало пригодны для вычислительных задач. Таким образом, для описания ПО и процесса проектирования их КУ требуется разработка новых языковых средств, сочетающих достоинства разных методов.

Одним из первых примеров таких средств является объектно-признаковый язык.

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

Это не гарантирует высокого качества проектов и требует разработки эффективных человеко-машинных проектных процедур.

1.3. Обобщенная схема проектирования Известно, что процесс концептуального проектирования любого объекта заключается в решении ряда проектных задач, каждая из которых состоит в последовательном выполнении нескольких проектных процедур и операций [14]. К числу проектных задач можно отнести синтез структуры системы, выбор ее алгоритма управления, обоснование тактико-технических данных, формирование технического задания и др. Проектная процедура – это совокупность действий, оканчивающихся проектным решением (ее не нужно путать с вычислительной процедурой). Проектная операция – это формализованная совокупность действий, составляющих часть проектной процедуры, алгоритмы, выполнения которых остаются неизменными для ряда проектных процедур. Проектные решения оформляются в виде проектного документа или в виде проекта, представляющего собой совокупность проектных документов.

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 10 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.