sistemnii_analiz_v_ypravlenii_V (998781), страница 19

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

Текст из файла (страница 19)

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

Вертикальная интеграция заключается в том, что СУ₁ и СУ₂ нижнего уровня устанавливаются модифицированные критерии оптимизации К_М1 (К_Н1) и К_М2 (К_Н2), а также реализуются управления U^opt₁₂ и U^opt₁₁ , такие, что:

U^opt_2i =arg extr K_Мi (K_Нi ); i[1,2];

U_2i

K_Нi [I_2i (U^opt_2i,U^opt_1i)] не хуже K^доп_нi ; i[1,2];

{U^opt₁₁ ,U^opt₁₂} = arg extr K(U^opt₂₁,U^opt₂₂),

{U_11, U₁₂}

где К^доп_Н1 ,К^доп_Н2 – допустимые значения соответственно критериев К_Н1, К_Н2.

Поскольку вопрос существования такого решения очень сложен, могут изыскиваться виды К^Р_М1, К^Р _М2, а также U^Р₂₁ , U^Р₂₂ , U^Р₁₂ и U^Р₁₁ такие, что:

K_Нi [I₂₁ (U^Р_2i, U^Р_1i )] не хуже K^доп_Нi ; i[1,2];

K_В (K_mi ,U^p_ji ); i,j[1,2] не хуже K^доп_В ,

Рис. 1.9. Схема сопряжения подсистем
при вертикальной интеграции (условный пример)

где K^доп_В – допустимые значения критерия K_В.

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

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

Для того чтобы исключить обязательность знания связей I_2i=I_2i(U_2i); i[1,2] для системы верхнего уровня, необходимы встречное генерирование и обмен сведениями об альтернативах управленческих решений между управляющими системами различных уровней.

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

► 2. СИСТЕМНОЕ ТОПОЛОГИРОВАНИЕ
СОФТВЕРНОГО ИНСТРУМЕНТАРИЯ ОБОСНОВАНИЯ
УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ

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

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

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

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

Конечно, такое разграничение в известном смысле условно.

В самом деле:

- во-первых, алгоритмы традиционно являются составной частью моделей;

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

Соответственно после осуществления программирования возникают программные реализации математических моделей и алгоритмов – программные продукты, в сочетании с математическими прототипами образующие специальное софтверное обеспечение. Применительно к современным средам проектирования нередко трудно, а порой и просто невозможно разнести специальное, прикладное креативное и собственно само специальное софтверное обеспечение. Типичные примеры – среда программирования Mathcad™, в которой, в частности, написание интегро-дифференциального уравнения и его разрешение в конечных разностях совмещаются через оператор «разрешить», а также Compaq™ Visual Fortran, имеющая мощные встроенные библиотеки.

2.1. Комплекс требований к софтверному обеспечению
управляющей системы и их декомпозирование

Подойдем к рассмотрению подходов к формированию требований к софтверному обеспечению.

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

Формализующий идентификационный инструментарий обладает рядом свойств, среди которых наиболее важными являются:

- характеристики точности, оцениваемые по выходным переменным (для моделей объекта управления – по показателям состояния);

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

- применяемый тип математических абстракций (например, дифференциальные и интегральные уравнения, функции алгебры логики);

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

- состав входных переменных, который для модели объекта управления соответствует составу управленческих воздействий и внешних по отношению к системе управления воздействий;

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

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

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

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

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

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

- посредством концентрации на одном элементе, когда все элементы, кроме одного, объявляются идеальными (например, абсолютно точными или не требующими затрат времени на функционирование);

- посредством эвристического назначения;

- посредством равноценного, равномерного распределения;

- посредством перенесения по аналогиям, например, исходя из характеристик конкурирующих продуктов – как существующих, так и проектируемых;

- посредством построения модели управленческого процесса и оптимизации структуры и параметров подпроцессоров.

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

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

2.2. Система методов моделирования объектов

Модели описывают объекты.

Характеристики

Список файлов книги