Разработка АСУ с применением системного анализа

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

Эти особенности были осознаны с самого начала разработки АСУ и обусловили необходимость привлечения для их объяснения и обеспечения системных представлений, закономерностей функцио­нирования и развития сложных систем. Понимая неизбежность и необходимость проявления названных особенностей и обусловливающих их закономерностей, которые действуют в системе независимо от того, учитывают или нет, и затрудняют управление разработками автоматизированных информационных систем, некоторые специалисты уже на ранних стадиях их создания предлагали создавать системы проектирования и развития АСУ, разрабатывать единые принципы проектирования и терминологию. Были разработаны типовые положения, типовые структуры, поря­док разработки и другие методические материалы, объединенные затем в единый документ - Общеотраслевые руководящие методи­ческие материалы (ОРММ) [5].

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

Структура функциональной части (ФЧ) определяется на основе анализа целей и функций системы управления, для обеспечения деятельности которой создается АСУ или АИС, и включает подсистемы и задачи, выбранные для автоматизации, т. е. ФЧ определяет как бы цели и основные функции АСУ (АИС).

Структура обеспечивающей части (ОЧ) включает виды обеспечения (собственно инфор­мационное, техническое, программное, лингвистическое, эргономическое и т. п.), необходимые для реализации подсистем и задач ФЧ
АСУ (АИС), т.е. ОЧ представляет собой как бы средства для достижения целей АС.

Соответственно при управлении разработками автоматизированных систем выделяют две основные проблемы:

1. Формирование структуры функциональной части АС и выбор на ее основе первоочередных задач автоматизации (для АС той или иной очереди).

2. Формирование структуры обеспечивающей части АС.

Применение системного анализа при обосновании структуры функциональной части АСУ (АИС). В разрабатываемых методиках обоснования структуры ФЧ АСУ так же, как и при разработке структур целей и функций систем управления, выделялось два основных этапа, которые делились на подэтапы в соответствии с выбранными методиками структуризации целей.

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

Первоначально основной формой представления структуры ФЧ АСУ была древовидная иерархическая структура. АСУ делилась на подсистемы (или комплексы задач, подсистемы - на группы задач, а последние, в свою очередь, - на отдельные задачи.

Подсистемы в первых структурах ФЧ АС, а затем - в типовой структуре ФЧ АС были ориентированы на основные функциональные подразде­ления существовавших систем организационного управления, отку­да и произошел термин "функциональная подсистема".

Число подсистем в АИС первой очереди конкретных предприя­тий было разным, но обычно не превышало числа подсистем типо­вой АСУП, рекомендованной в ОРММ. Число задач по подсистемам колебалось довольно в широких пределах, в зави­симости от принятой детализации задач и конкретных особенностей предприятия.

Однако по мере развития АСУ число подсистем увеличивалось. При возрастании числа подсистем нарушается важное требование к иерархическим структурам - гипотеза Миллера, согласно которой число составляющих одному узлу должно быть 7 ±2.

Трудности управления разработками АС при существенном увеличении числа подсистем, т. е. числа составляющих на верхнем уровне иерархической структуры ФЧ, привели к тому, что на неко­торых предприятиях стали вводить еще один обобщающий уровень. В дальнейшем, по мере развития предприятий и их АСУ, особенно в условиях предоставления большей самостоятельности производствам и цехам и перераспределению управленческих функций между администрацией предприятия и руководителями производств и цехов, также стало более удобным представлять структуру ФЧ АСУ в виде многоуровневой, стратифицированной.

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

С учетом сказанного задачу обоснования структуры ОЧ АСУ можно сформулировать следующим образом [5].

Под структурой ОЧ АСУ будем понимать сеть информационных служб (Главный информационно-вычислительный центр, локаль­ные вычислительные центры производств, цехов и других подразде­лений, автоматизированные рабочие места и другие составляющие ОргО) с размещенными в ней массивами хранения информации, до­кументами (ИО), техническими средствами регистрации, хранения, передачи, обработки, представления информации (ТО), программ­ным обеспечением (ПО), методическим обеспечением (инструкци­ями для пользователей, положениями о подразделениях и т. п.) и другими видами обеспечения.

Под выбором структуры ОЧ - задачу наилучшего размещения всех этих компонентов с учетом единой со­гласованной системы критериев и ограничений, обеспечивающей наиболее эффективную реализацию подсистем и задач, включенный в структуру ФЧ АСУ на соответствующем этапе ее развития (т.е. соответствующей очереди АСУ).

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

Теоретические положения системного анализа определенное время рассматривались только как некая философия инженера и поэтому при решении задач создания искусственных систем иног­да не учитывались. Однако развитие техники привело к тому, что без системного анализа, одним из результатов которого являют­ся концептуальные модели, исследование функционирования си­стем становится невозможным [2].

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

Известно, что для оценки производительности процессора используются два показателя:

1) показатель производительности процессоров на операции с данными целочисленного типа (integer) MIPS (Million Instruction Per Second - миллион машинных команд в секунду), т.е. отношение числа команд в программе к времени ее выпол­нения;

2) показатель производительности процессоров на операци­ях с данными вещественного типа (float point) MFLOPS (милли­он арифметических операций над числами с плавающей точкой в секунду).

Для работы с показателями MIPS и MFLOPS чаще всего ис­пользуются системы тестов Dhrystone, LINPACK и «Ливерморские циклы». Так, например, тестовая смесь Dhrystone состоит из 100 команд: 53 - опера­торы присвоения, 32 - управления и 15 - вызова функций. Резуль­татом работы этого теста является число Dhrystone в секунду. Очевидно, что учет такого числа команд является наглядным примером системного подхода к проведению тестирования.

Ведущие производители компьютерных систем в 1988 г. со­здали некоммерческую корпорацию SPEC (Strandard Performance Evaluation Corporation), призванную дать объективную оценку производительности вычислительных систем. Корпорация SPEC является разработчиком тестов, проводит тестирование и публи­кует результаты в специальном бюллетене «The SPEC Newsletter», который размещается на WWW-сервере www.SPEC.com. Оцен­ки, публикуемые комитетом SPEC, являются официальными, при­знаваемыми всеми разработчиками тестов.

Основным набором в SPEC был тест SPECint89 для оценки процессора на операциях с данными целочисленного типа и SPECfp89 для оценки при работе с данными вещественного типа. Появление в начале 90-х гг. нового поколения RISC-процессо­ров (PowerPC, PA-7200, MIPS, Rxxxx) сделало невозможным ис­пользование этого набора из-за резкого уменьшения времени выполнения и влияния на производительность оптимизирующих компиляторов.

Тестовый набор был преобразован в смеси SPECint92 и SPECfp92, учитывающие эффективность работы с памятью. Про­изводительность тестируемой системы измерялась в условных единицах относительно базовой DEC VAX 11/780.

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

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

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

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

Со временем тест iCOMP был модифицирован и назван iCOMP 2.O. В нем отражены основные тенденции в формирова­нии требований к оценке микропроцессоров: учет современных профилей прикладных программ, определяемых как соотноше­ние времени выполнения регистровых операций ЦПУ, обмена с памятью и ввода-вывода; переход на 32-разрядные операцион­ные системы и прикладные программы, включая Windows 95, NT, OS/2 и UNIX; быстрое увеличение объема мультимедийных, се­тевых средств и средств обработки трехмерной графики.

Сравнение и оценка производительности вычислительных систем применительно к конкретному приложению и планируе­мому использованию проводятся по методикам AIM, разработанным независимой ком­панией AIM Technology, основанной в 1981 году. Предлагаемые AIM Technology методики и тестовые смеси ориентированы на получение интегральных оценок по всем компонентам UNIX-систем в многопользовательском и многозадач­ном режимах.

Интерес представляют и методики оценки скорости обработки транзакций. До недавнего времени все производители рабочих станций и разработчики систем управления базами данных (СУБД) пред­лагали свои собственные способы оценки. В 1988 г. пять ведущих фирм, среди которых были IBM, Control Data и Hewllett-Packard, организовали Совет по проведению оценки скорости выполне­ния транзакций ТРС (Transaction Processing Performance Council), положивший конец «войне транзакций» и установивший единые правила измерения и оформления отчетов по их результатам.

Методики тестирования ТРС основаны на том, что эффективность систем, предназначенных для решения задач оперативной анали­тической обработки данных - OLTP (On-line Transaction Processing), в том числе для работы с базами данных, характери­зуется числом транзакций, выполняемых в единицу времени. Любая компания и фирма может стать членом ТРС, а резуль­таты тестовых испытаний общедоступны на WWW-сервере www.ideas.com.au/bench/spec/spec.htm.

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

Для оценок графических систем в настоящее время доступны несколько тестов, разработанных комитетом Graphics Performance Characterization (GPC), функционирующим под уп­равлением Национальной графической компьютерной ассоциа­ции (NCGA - National Computer Graphics Association), которая, в свою очередь, взаимодействует со SPEC. Комитет GPC предло­жил три системы тестов, на основе которых производится тести­рование графических систем. Первой тестовой системой являет­ся Picture-Level Benchmark (PLB), фактически измеряющая ско­рость визуализации. Результаты тестирования, доступные на сер­вере http://sunsite.unc.edu/gpc/gpc.html или www.ideas.com.au/bench/gpc, приводятся для стандартной (PLBlit) и оптимизированной (PLBopt) конфигурации.

Кроме теста PLB комитет GPC публикует результаты измере­ний по методике Xmark93, используемой для оценки эффектив­ности работы Х-сервера. Следует отметить, что фирмами-разра­ботчиками чаще всего используется тест Xmark93, позволяющий оценивать не только аппаратуру, но и эффективность реализа­ции Х-сервера и степень его оптимизации под конкретное графи­ческое оборудование. Результаты измерений на основе данного теста обычно доступны на WWW-серверах фирм-производителей.

Для оценки быстродействия суперкомпьютеров используются специальные методики. Результаты последних оценок суперкомпьютерных платформ можно найти на WWW-сервере NAS www.nas.nasa.gov/NAS/NPB. Анализ этих данных показывает, что даже самая быстродейству­ющая система VPP500 по соотношению цена/производительность уступает или сравнима с намного более дешевым сервером DEC 8400, суперкомпьютером SGI Power Challenge или RS/6000 SP.

Наконец, тестовая методика оценки конфигураций Web - WebSTONE - представляет собой одно из первых средств оценки эффектив­ности оборудования и программного обеспечения при работе с протоколом HTTP.

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

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

В перспективе возможности WebSTONE будут расширены средствами поддержки proxy-серверов, стоимостными оценками, например затратами на эксплуатацию и модернизацию Web-сер­вера, оценками организации работы с транзакциями, активно использующими двоичные сценарии CG (Common Gate Interface), оценками эффективности построения защиты и производитель­ности работы с распределенными базами данных.