Глава 11. Человеко-машинищ-,

у. Заключеиие

том - станция, на которой исполняется прикладная задача. В системе X W клиент генерирует инструкции по выводу изображений, а Х-сервер управ миналом, рисуя графические объекты и текст как реакцию на сообщения Х та. Сервер также передает действия пользователя - нажатия на клавиши ния мыши - любому Х-клиенту, т. е. прикладным программам, соответ " управляя ими. ственно

Каждая станция имеет менеджера окон - специального Х-клиента, который тролирует вид всех графических объектов на экране. Менеджер окон устанавл стиль окна, т. е. внешний вид и поведение (look and feel) оконной системы и следовГ тельно, управляет наложением окон, изменением размеров, масштабированием и знционнрованием в соответствии с командами пользователя.

Работа системы X Window не привязана к какому-либо определенному сетевому протоколу, но до сих пор она в основном использовалась с операционной системой UNIX, т. е. с протоколом TCP/IP, поэтому эти продукты часто ассоциируются один с другим, однако это разные решения для разных, хотя и связанных, задач.

11.7. Заключение

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

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

Как много систем - так много и пользователей. Типичного пользователя не существует. Часть людей хорошо знают ВТ, позитивно настроены и всегда хотят узнать больше. Другие боятся компьютеров или просто не имеют стимулов и ничем не интересуются. Очень часто, особенно когда система управления строится вокруг существующего технического процесса, пользователи - это хорошо подготовленные прикладные специалисты. Нередко они не доверяют программистам, которые не вникают в детали процесса, и по любому поводу отпускают замечания о том, "как все хорошо было раньше".

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

vinpOMHCc между предположением, что пользователи ничего не знают и ничего не ""остоянии выучить, и требованием, чтобы пользователи все-таки изучили кое-чтп

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

рекомендации по дальнейшему чтению

Некоторые базовые знания по психологии могут оказаться полезными для понимания основных идей по разработке дружественных пользовате.яю программных продуктов. Введение в психологию, с солидным разделом, посвященным восприятию, обучению и теории двухуровневой памяти, содержится в [Atkinson et ai., 1990]. Книга рекомендуется тем, кто заинтересован более подробно заниматься этими проблемами. Теория двухуровневой памяти описана также в [Atkinson/Shiffrin, 1971]. Еще более глубокие изыскания, касающиеся проблемы распознавания в психологии, приведены в [Solso, 1993].

[Sanders/McCormick, 1993] является содержательным справочником по различным сторонам практической эргономики; она может быть рекомендована читателям, заинтересованным в расширении кругозора. Сборник [Salvendy, 1987] содержит материалы различных авторов и посвящен г.давным образом рассмотрению психологических и познавательных проблем при работе со сложными системами.

Прекрасная книга, позволяющая взглянуть на вещи с точки зрения пользователя, - это [Когшап, 1988]. Она содержит несколько примеров того, как не нужно проектировать устройства и инструменты, - это захватывающая лекция о здравом смысле в технике. Книга уделяет особое внимание принципам проектирования (простота, наглядность и последовательность), на нескольких примерах демонстрируя хорошо или плохо выполненные разработки. Парадоксы в обращении пользователей с ЭВМ описаны в [Bainbridge, 1983].

Вопросы эргономики программного обеспечения рассмотрены в [Shneider-иап, 1998], особенно в части, касающейся организации объектов на экране и интерактивных командных языков для поиска информации в базах данных. Общим введением в проблемы интерфейса пользователя являются [Norman/Draper, 1986] и [Preece/Keller, 1990]. Модели человеческих действий на уровне навыков, правил и знаний впервые описаны в [Rasmussen, 1983]. Ошибки и их последствия в сложных (истемахрассмотрены в [Rasmussen/Duncan/Leplat, 1987].

руководства и стандарты для интерфейсов пользователя

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

ANSI/IEEE 845-1988, "Guide to Evaluation of Man-Machine Performance in Nuclee Power Generating Stations, Control Rooms and Other Peripheries"

ANSI/IEEE 1023-1988, "Guide for the Application of Human Factors Engineering t -ystems. Equipment and Facilities of Nuclear Power Generating Stations"

Глава 11. Человеко-машинннй

Sun Microsystems Inc., "OPEN LOOK Graphical User Interface- t Specifications" и "OPEN LOOK Graphical User Interface: Application Style Gu"h t"* Addison-Wesley, Reading, MA, December 1989. Wehnes",

Open Software Foundation, "OSF/Motif Style Guide" и "OSF/Motif User Prentice Hall, Englewood Cliffs, NJ, 1990.

Существуют и несколько руководств по наиболее распространенным ин л, сам пользователя в среде Windows и UNIX. Рфеи-

Системная интеграция

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

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

История развития систем управления рассматривается в разделе 12.1. В разде-.1612.2 обсуждается системная интеграция. Надежность системы играет основополагающую роль. Ее можно описать & помощью специально разработанных математических методов, которые, однако, годятся только для конкретных ситуаций; эти «етоды рассмотрены в разделе 12,3.

Функции системы управления процессом - это тема раздела 12.4. В этом разделе совместно рассмотрен материал главы 7 (комбинационное и последовательностное .Правление) и главы 10 (программирование в реальном времени) и дополнительно

Нуждается программирование для баз данных реального времени и интеграция программного обеспечения. Хотя описание ориентировано на большие промышлен-

ксистемы, многие идеи можно использовать в менее масштабных проектах, «он "" приложениях имеют значение не только технические решения - Мы

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

if J2 2° Управления процессами. Эти факторы коротко рассматриваются в разде-"Дени °У моменту у читателя должно возникнуть глубокое н реалистичное итате; возможностей применения автоматизации. Авторы надеются, что

*ели °"Р"бт эту главу как очередной шаг на пути к новым знаниям и опыту, как просто заключительную часть книги.

"" Роце десятилетия короткой истории развития автоматизированного управле-

рование систем управления процессами

Ущ позволили извлечь некоторые важные уроки. Ясно, что две главные

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

про-про-

а соответствующие рещения не были адекватно структурированы с точки зрения граммного и аппаратного обеспечения. Примером может служить разработка граммного обеспечения космической программы "Apollo". Небольшой объем памяти бортового компьютера (64 Кбайт) пришлось использовать до последнего бита, и в ре зультате задача профаммирования потребовала колоссальных усилий - в конечном счете это вылилось почти в 1000 человеко-лет работы. Сегодня даже самые дешевые ЭВМ имеют в сотни раз больший объем памяти, которая быстро "пожирается" громоздкими офисными или игровыми программами.

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

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

Структурирование является самым важным этапом в управлении процессом. Оно влияет как на конфигурацию аппаратных средств, так и на модульную структуру программного обеспечения. В химической и энергетической промышленности стандарты установлены уже давно. Потребности операторов были достаточно очевидны с самого начала - переместить интерфейс управления с панелей и стоек на экраны терминалов. Они хотели видеть ту же самую информацию, что и на старых ПИД-регуляторах, те же самые кривые, которые чертились на старых графопостроителях, и те же схемы процессов, которые у них уже были в диспетчерских. Это привело к развитию языков программирования типа "fill-in-the-blank" ("заполни готовый бланк"), в которых регуляторы описывались в параметрической форме.

Для логических цепей и последовательностных сетей решение было очевидно -заменить старые реле цифровыми технологиями (глава 7). Старые принципиальные схемы можно было вывести на экран на основе тех же самых обозначений, с той лишь разницей, что логические операции выполняются программным обеспечением. 1 Р вые ПЛК действительно являлись лишь заменой релейной технологии. Рост потре ности в структурировании привел сегодня к постоянному обновлению функцио нальной части ПЛК, а также к созданию коммуникационных интерфейсов Для включения их в более крупные сети управления. Эта же потребность в структуриро вании привела к развитию языков для управления последовательностью.

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

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

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

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

12.2. Интеграция автоматизированных систем управления 12.2.1. Уровни интеграции

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

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

Интегральные и гибридные микросхемы содержат логику обработки данных, позволяющую реализовать сложные алгоритмы на основе либо комбинационного управления, либо программного микрокода (firmware), "зашитого" в микросхему. Микропроцессоры общего назначения также базируются на простых, программно Управляемых логических схемах. Кроме серийно выпускаемых, возможно применение специальных заказных микросхем для конкретных приложений, однако из-за fibicoKHX издержек на проектирование и запуск в производство это становится эконо-«ически эффективным, если объем выпуска превышает несколько тысяч штук. Типичная область применения интегральных микросхем - продукция массового спроса, которая не нуждается в замене программного обеспечения в течение всего срока службы, а управляющее устройств должно занимать очень мало места, например