Сети передачи данных в асу тп. Краткая характеристика интерфейсов асу тп Человеко машинный интерфейс асу тп лекции

ВВЕДЕНИЕ

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

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

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

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

В настоящее время можно считать доказанным, что главная задача проектирования интерфейса пользователя заключается не в том, чтобы рационально «вписать» человека в контур управления, а в том, чтобы, исходя из задач управления объектом, разработать систему взаимодействия двух равноправных партнеров (человек-оператор и аппаратно-программный комплекс
АСУ), рационально управляющих объектом управления.
ПРЕДМЕТНАЯ ОБЛАСТЬ

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

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

Интерфейс взаимодействия человека с техническими средствами АСУ может быть структурно изображен (см. на рис.1.). Он состоит из АПК и протоколов взаимодействия. Аппаратно-программный комплекс обеспечивает выполнение функций:

1. преобразование данных, циркулирующих в АПК АСУ, в информационные модели, отображаемые на мониторах (СОИ - средства отображения информации);

2. регенерация информационных моделей (ИМ);

3. обеспечение диалогового взаимодействия человека с ТС АСУ;

4. преобразование воздействий, поступающих от ЧО (человека-оператора), в данные, используемые системой управления;

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

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

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

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

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

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

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

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

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

Рис. 1. Информационно-логическая схема интерфейса взаимодействия.

ИНФОРМАЦИОННАЯ МОДЕЛЬ: ВХОДНАЯ И ВЫХОДНАЯ ИНФОРМАЦИЯ

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

D ^ {Dn} , где Rj - множество элементов информационной модели j-й группы, n=1,...N; k=1,...K.

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

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

6. Статическая информация - относительно стабильная по содержанию информация, используемая в качестве фона. Например, координатная сетка, план, изображение местности и т.д.

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

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

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

Принцип минимального рабочего усилия, имеющий два аспекта:

8. минимизация затрат ресурсов со стороны разработчика ПО, что достигается путем создания определенной методики и технологии создания, свойственной обычным производственным процессам;

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

Задача максимального взаимопонимания. Т.е. ЧО не должен заниматься, например, поиском информации, или выдаваемая на экран информация не должна требовать перекодировки или дополнительной интерпретации пользователем.

Пользователь должен запоминать как можно меньшее количество информации, так как это снижает свойство ЧО принимать оперативные решения.

Принцип максимальной концентрации поьзователя на решаемой задачи и локализация сообщений об ошибках.
ЧТО ПОНИМАТЬ ПОД ИНТЕРФЕЙСОМ

Пользовательский интерфейс - это значит общение между человеком и компьютером. Общий Пользовательский Доступ - это правила, которые объясняют диалог в терминах общих элементов, таких как правила представления информации на экране, и правила интерактивной технологии такие, как правила реагирования человека-оператора на то, что представлено на экране. В данном курсовом проекте мы рассмотрим стандарт ОПД фирмы IBM разработанный совместно с компанией MICROSOFT для класса машин «РС-АТ».

КОМПОНЕНТЫ ИНТЕРФЕЙСА

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

1. Способ общения машины с человеком-оператором.

2. Способ общения человека-оператора с машиной.

3. Способ пользовательского представления интерфейса.

МАШИНА К ПОЛЬЗОВАТЕЛЮ

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

ПОЛЬЗОВАТЕЛЬ К МАШИНЕ

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

КАК ПОЛЬЗОВАТЕЛЬ ДУМАЕТ

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

СОГЛАСОВАННЫЙ ИНТЕРФЕЙС

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

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

СОГЛАСОВАННОСТЬ - ТРИ РАЗМЕРНОСТИ:

Говорить что интерфейс согласован - это все равно что говорить, что что-то есть больше чего-то. Мы вынуждены спросить: "Больше чем что?". Когда мы говорим, что интерфейс согласован, мы вынуждены спросить: "Согласован с чем?". Необходимо упомянуть некоторую размерность.

Интерфейс может быть согласован с тремя широкими категориями или размерностями: физической, синтаксической и семантической.

4. Физическая согласованность относится к аппаратному обеспечению: схемы клавиатуры, расположения клавиш, использованию мыши. Например, будет иметь место физическая согласованность для клавиши F3, если она всегда находиться в одном и том же месте независимо от использования системы. Аналогично, будет физически согласованным выбор кнопки на мышке, если она всегда будет располагаться под указательным пальцем.

5. Синтаксическая согласованность относится к последовательности и порядку появления элементов на экране (язык представлений) и последовательности запросов действий требований (язык действий).

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

6. Семантическая согласованность относится к значению элементов, которые составляют интерфейс. Например, что означает "Выход"? Где пользователи делают "Выход" и что затем происходит?

МЕЖСИСТЕМНАЯ СОГЛАСОВАННОСТЬ

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

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

ПРЕИМУЩЕСТВА СОГЛАСОВАННОГО ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

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

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

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

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

ИНТЕРФЕЙСА

MS-Windows предоставляет пользователям оболочку графического интерфейса (GUI), которая обеспечивает стандартную среду пользователя и программиста. (GUI) предлагает более сложное и дружелюбное окружение пользователя, чем командно-управляемый интерфейс DOS. Работа в Windows основана на интуитивно понятных принципах. Вам легко переключиться с задачи на задачу и осуществлять обмен информацией между ними. Однако разработчики приложений традиционно сталкиваются с трудностями программирования, поскольку организация среды Windows является чрезвычайно сложной.

Delphi - язык и среда программирования, относящаяся к классу RAD-
(Rapid Application Development - «Средство быстрой разработки приложений») средств CASE - технологии. Delphi сделала разработку мощных приложений
Windows быстрым процессом, доставляющим вам удовольствие. Приложения
Windows, для создания которых требовалось большое количество человеческих усилий например в С++, теперь могут быть написаны одним человеком, использующим Delphi.

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

Delphi обладает широким набором возможностей, начиная от проектировщика форм и кончая поддержкой всех форматов популярных баз данных. Среда устраняет необходимость программировать такие компоненты
Windows общего назначения, как метки, пиктограммы и даже диалоговые панели.
Работая в Windows , вы неоднократно видели одинаковые «объекты» во многих разнообразных приложениях. Диалоговые панели (например Choose File и Save
File) являются примерами многократно используемых компонентов, встроенных непосредственно в Delphi, который позволяет приспособить эти компоненты к имеющийся задаче, чтобы они работали именно так, как требуется создаваемому приложению. Также здесь имеются предварительно определенные визуальные и невизуальные объекты, включая кнопки, объекты с данными, меню и уже построенные диалоговые панели. С помощью этих объектов можно, например, обеспечить ввод данных просто несколькими нажатиями кнопок мыши, не прибегая к программированию. Это наглядная реализация применений CASE- технологий в современном программировании приложений. Та часть, которая непосредственно связана с программированием интерфейса пользователя системой получила название визуальное программирование

Выгоды от проектирования АРМ в среде Windows с помощью Delphi:

10. Устраняется необходимость в повторном вводе данных;

11. Обеспечивается согласованность проекта и его реализации;

12. Увеличивается производительность разработки и переносимость программ.

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

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

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

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

РАЗРАБОТКА ДИЗАЙНА ПАНЕЛИ

Установим основные термины, относящиеся к разработке панели.

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

9. Информация;

10. Список;

11. Логическое.

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

12. Меню действий и нисходящее меню;

13. Тело панели;

14. Область функциональных клавиш.

Рис. 2. Три панельные области.

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

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

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

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

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

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

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

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

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

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

Область функциональных клавиш располагается в нижней части панели и оператор может выбрать размещение ее в короткой или длинной форме или вообще не размещать. Она содержит список функциональных клавиш. Некоторые панели могут содержать как меню действий, так и заголовок функциональных клавиш. Необходимо обеспечить включение области функциональных клавиш для всех панелей, хотя пользователь может отказаться от их экранирования. См. рис. 3 где представлен общий вид панели пользователя системой.
|Выбор Связи |
|Выбрать один из следующих видов связи: |
|1. Прием почты |
|2. Прием сообщений |
|3. Отправление почты |
|4. Почтовый журнал |
|5. Операции |
|6. Почтовый статус |
|Esc=Отмена |F1=Помощь |F3=Выход |

Рис. 3. Панель с областью функциональных клавиш. Область функциональных клавиш экранирована в короткой форме и содержит выборы Отмена, Помощь и

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

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

ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ: ОБЪЕКТ - ДЕЙСТВИЕ

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

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

РАБОТА ПОЛЬЗОВАТЕЛЯ С ПАНЕЛЬЮ

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

ПРЯМОЕ ВЗАИМОДЕЙСТВИЕ

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

15. Назначение действиям функциональных клавиш.

16. Ускоренный выход из действий высокого уровня.

17. Использование мнемоники и номеров для выбора объектов и действий.

18. Командная область позволяет пользователю войти в приложение и системные команды.

19. Применение мышки ускоряет выбор действий.

ПОСТРОЕНИЕ ДИАЛОГА

Диалог - это последовательность запросов между пользователем и компьютером: запрос пользователя, ответ и запрос компьютера, окончательное действие компьютера.

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

Итак, диалог состоит из двух частей:

Каждому шагу диалога сопутствует решение сохранять или не сохранять новую информацию.

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

22. Вперед на один шаг (действие входа);

23. Назад на один шаг (действие отмены);

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

25. Покинуть приложение (режим выхода из приложения).

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

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

Рис. 4. Диалоговые действия.

УДЕРЖАНИЕ И СОХРАНЕНИЕ ИНФОРМАЦИИ

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

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

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

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

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

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

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

ТРИ ТИПА ОКОН

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

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

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

Устройства Ввода: клавиатура, мышка и другие

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

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

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

Поддержка Клавиатуры

Примем за стандарт де-факто Общий Пользовательский Доступ, разработанный с учетом одного типа клавиатуры, а именно, расширенной клавиатуры фирмы IBM.

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

Правила назначения клавиш:

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

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

27. Если приложение будет переведено на другие языки, не следует назначать сочетаниям алфавитно-цифровых клавиш с Alt. Однако, если это возможно, пользователи могут назначать этим клавишам различные функции.

28. Для изменения исходного значения клавиш используйте их в сочетании с клавишами Alt, Ctrl и Shift. Клавиши Alt, Ctrl и Shift самостоятельно не используются.

29. Не следует переназначать или дублировать назначение клавиш.

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

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

32. Если пользователи нажимают неназначенную на уровне текущей панели клавишу, то никакого эффекта не должно быть, если не указано что-либо иное.
ЗАКЛЮЧЕНИЕ

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

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

Говоря о проблемах взаимодействия человека с ТС АСУ и практической реализации интерфейса взаимодействия, нельзя опустить такой важный вопрос, как унификация и стандартизация. Использование типовых решений, модульного принципа проектирования систем отображения и обработки информации приобретает всё более широкие масштабы, что, впрочем, вполне естественно.

Особый упор при внедрении данных задач следует конечно придавать современным CASE-средствам разработки прграмм, так как они наиболее оптимально позволяют проектировать решения в основе которых лежат, в первую очередь, требования к согласованному пользовательскому интерфейсу, каковым и является интерфейс Windows. Никакие продукты других фирм, доступные сегодня, не обеспечивают одновременную простоту использования, производительность и гибкость в такой степени, как Delphi. Этот язык заполнил брешь между языками 3-го и 4-го поколений, соединив их сильные стороны и создав мощную и производительную среду разработки.

ЛИТЕРАТУРА

Организация взаимодействия человека с техническими средствами АСУ, том 4:
«Отображение информации», редакция В.Н.Четверикова, Москва, «Высшая Школа»
1993.
Организация взаимодействия человека с техническими средствами АСУ, том 7:
«Системное проектирование взаимодействия человека с техническими средствами», редакция В.Н.Четверикова, Москва, «Высшая Школа» 1993.
«Кибернетические диалоговые системы», И.П.Кузнецов.
«Рекоммендации по общепользовательскому интерфейсу», Microsoft, редакция
1995г.
Джон Матчо, Дэвид Р.Фолкнер. «Delphi» - пер. с англ. - М.:Бином, 1995г.

ВВЕДЕНИЕ 2

ПРЕДМЕТНАЯ ОБЛАСТЬ 3

ИНФОРМАЦИОННАЯ МОДЕЛЬ: ВХОДНАЯ И ВЫХОДНАЯ ИНФОРМАЦИЯ 6

ФУНКЦИОНАЛЬНЫЕ ЗАДАЧИ, КОТОРЫЕ РЕШАЕТ DELPHI ПРИ КОНСТРУИРОВАНИИ ИНТЕРФЕЙСА
7

ЧТО ПОНИМАТЬ ПОД ИНТЕРФЕЙСОМ 8

КОМПОНЕНТЫ ИНТЕРФЕЙСА 8

МАШИНА К ПОЛЬЗОВАТЕЛЮ 8

ПОЛЬЗОВАТЕЛЬ К МАШИНЕ 8

КАК ПОЛЬЗОВАТЕЛЬ ДУМАЕТ 8
СОГЛАСОВАННЫЙ ИНТЕРФЕЙС 9

СОГЛАСОВАННОСТЬ - ТРИ РАЗМЕРНОСТИ: 9

МЕЖСИСТЕМНАЯ СОГЛАСОВАННОСТЬ 10

ПРЕИМУЩЕСТВА СОГЛАСОВАННОГО ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ 10

ПРОГРАММНО-ТЕХНИЧЕСКИЕ СРЕДСТВА: РЕАЛИЗАЦИЯ И СОЗДАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО
ИНТЕРФЕЙСА 11

РАЗРАБОТКА ДИЗАЙНА ПАНЕЛИ 13
ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ: ОБЪЕКТ - ДЕЙСТВИЕ 16

РАБОТА ПОЛЬЗОВАТЕЛЯ С ПАНЕЛЬЮ 16

ПРЯМОЕ ВЗАИМОДЕЙСТВИЕ 16

ПОСТРОЕНИЕ ДИАЛОГА 16
УДЕРЖАНИЕ И СОХРАНЕНИЕ ИНФОРМАЦИИ 19
ОКНА 19

ТРИ ТИПА ОКОН 20
УСТРОЙСТВА ВВОДА: КЛАВИАТУРА, МЫШКА И ДРУГИЕ 20

ПОДДЕРЖКА КЛАВИАТУРЫ 21

Скачать документ

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

ИНТЕРФЕЙС
ДЛЯ АВТОМАТИЗИРОВАННЫХ
СИСТЕМ УПРАВЛЕНИЯ
РАССРЕДОТОЧЕННЫМИ ОБЪЕКТАМИ

ОБЩИЕ ТРЕБОВАНИЯ

К.И. Диденко, канд. техн. наук; Ю.В. Розен; К.Г. Карнаух; М.Д. Гафанович, канд. техн. наук; К.М. Усенко; Ж.А. Гусева; Л.С. Ланина; С.Н. Кийко

ВНЕСЕН Министерством приборостроения, средств автоматизации и систем управления

Член Коллегии Н.И. Гореликов

УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 30 марта 1984 г. № 1145

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

до 01.01.90

Несоблюдение стандарта преследуется по закону

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

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

1. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

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

сопряжение с оперативно-технологическим персоналом;

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

2. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ

2.1. Интерфейс реализует бит-последовательный синхронный способ передачи цифровых сигналов данных по двухпроводному магистральному каналу.

2.2. Суммарное затухание сигнала между выходом передающей и входом принимающей станции должно быть не более 24 дБ, при этом затухание, вносимое линией связи (магистральным каналом и отводами), должно быть не более 18 дБ, вносимое каждым устройством связи с линией, - не более 0,1 дБ.

Примечание. При использовании кабеля типа РК-75-4-12 максимальная длина линии связи (включая длину отводов) - 3 км.

(Новая редакция, Изм. № 1).

2.5. Для представления сигналов должна применяться двухфазовая модуляция с фазоразностным кодированием.

2.6. Для кодовой защиты передаваемых сообщений должен применяться циклический код с производящим полиномом X 16 + X 12 + X 5 + 1.

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

2.8. Передача сообщений между локальными подсистемами должна осуществляться посредством ограниченного набора функциональных байтов, последовательность которых устанавливается форматом сообщения. Интерфейс устанавливает два типа форматов сообщений (черт. 1).

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

Формат 2 включает переменную по длине информационную часть, предназначенную для передачи данных.

Формат 2 в зависимости от скорости передачи (низкоскоростной или высокоскоростной диапазон) должен иметь вид 2.1 или 2.2 соответственно.

Типы форматов сообщений

Формат 1

2.9. Форматы сообщений должны включать следующие функциональные байты:

синхронизирующий СН;

адрес вызываемой локальной подсистемы АВ;

код выполняемой функции КФ;

собственный адрес локальной подсистемы АС;

число байтов данных в информационной части ДС, ДС1 или ДС2;

информационные байты ДН1 - ДНп;

байты контрольных кодов КБ1 и КБ2.

2.8, 2.9.

2.9.1. Синхронизирующий байт СН служит для обозначения начала и конца сообщения. Синхронизирующему байту присвоен код?111111?.

2.9.2. Байт адреса подсистемы АВ определяет локальную подсистему, которой направляется сообщение.

2.9.3. Байт выполняемой функции КФ определяет операцию, которая выполняется в данном цикле связи. Назначение разрядов внутри байта КФ приведено на черт. 2.

Структура байта КФ

2.9.4. Коды КФ и соответствующие им выполняемые операции указаны в таблице.

Обозначение байта	Код функции	Выполняемая операция
Обозначение байта		Выполняемая операция
		Групповая передача (с общей адресацией)


		Запись-чтение
		Централизованный опрос контроллеров
		Передача управления магистральным каналом
		Возврат управления магистральным каналом. Сообщение с общим адресом не принято
		Возврат управления магистральным каналом. Сообщение с общим адресом принято
		Децентрализованный опрос контроллеров. Отсутствие запроса на захват канала. Сообщение с общим адресом не принято

		Запрос на захват магистрального канала. Сообщение с общим адресом не принято
		Запрос на захват магистрального канала. Сообщение с общим адресом принято
		Передача маркера




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

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

Разряд 1 принимает единичное значение при занятости подсистемы (например формирование буфера данных).

Разряд 2 принимает единичное значение в том случае, если в данном цикле передается сообщение формата 2.

Разряд 3 принимает единичное значение в повторно посылаемом сообщении одной и той же локальной подсистеме в случае обнаружения ошибки или отсутствия ответа.

(Измененная редакция, Изм. № 1).

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

2.9.6. Байт ДС определяет длину информационной части в формате 2.1, при этом величина двоичного кода байта ДС определяет количество байтов ДН. Исключение составляет код????????, который обозначает, что передается 256 информационных байтов.

Байты ДС1, ДС2 определяют длину информационной части в формате 2.2.

(Измененная редакция, Изм. № 1).

2.9.7. Байты данных ДН представляют информационную часть сообщения формата 2. Кодирование данных должно устанавливаться нормирующими документами на сопрягаемые локальные подсистемы.

2.9.8. Контрольные байты КБ1, КБ2 образуют контрольную часть и используются для определения достоверности передаваемых сообщений.

3. СТРУКТУРА ИНТЕРФЕЙСА

3.1. Интерфейс обеспечивает возможность построения рассредоточенных систем с магистральной структурой связи (черт. 3).

Структура соединения локальных подсистем

Л C 1 - ЛCn - локальные подсистемы; МК - магистральный канал; PC - резистор согласующий

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

3.3. Для сопряжения локальных подсистем с магистральным каналом в их составе должны быть предусмотрены контроллеры связи. Контроллеры связи должны осуществлять:

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

добавление и выделение знаков синхронизации;

распознавание и прием сообщений, адресованных данной локальной подсистеме;

формирование и сравнение контрольных кодов для определения достоверности принимаемых сообщений.

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

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

4. ФУНКЦИИ ИНТЕРФЕЙСА

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

пассивный прием;

прием и ответ;

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

запрос захвата магистрального канала;

централизованное управление магистральным каналом.

(Измененная редакция, Изм. № 1).

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

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

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

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

управляемая подсистема;

управляющая подсистема;

инициативная управляющая подсистема;

ведущая подсистема.

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

4.4.2. Управляемая подсистема осуществляет прием адресованных ей сообщений и формирует ответное сообщение в соответствии с принятым кодом функции.

4.4.3. Управляющая подсистема должна обладать способностью:

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

формировать и передавать сообщения по магистральному каналу;

принимать и анализировать ответные сообщения;

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

(Измененная редакция, Изм. № 1).

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

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

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

центральное управление всеми локальными подсистемами;

контроль работы активной управляющей локальной подсистемы;

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

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

(Измененная редакция, Изм. № 1).

5. ПОРЯДОК ОБМЕНА СООБЩЕНИЯМИ

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

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

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

5.1.3. Все байты, за исключением контрольных КБ1 и КБ2, передаются в магистральный канал, начиная с младшего разряда.

Байты КБ1, КБ2 передаются со старшего разряда.

5.1.4. Для исключения из передаваемого в магистральный канал сообщения последовательности битов, совпадающих с кодом байта СН, каждое сообщение должно быть преобразовано таким образом, что после 5 следующих друг за другом символов «1» должен включаться один дополнительный символ «0». Принимающий подсистемой этот символ должен соответственно исключаться из сообщения.

5.1.5. После передачи сообщения, включая оконечный байт СН, передающая подсистема должна передать еще не менее 2 байтов СН для завершения операций приема, после чего цикл передачи заканчивается.

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

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

5.2, 5.2.1. (Новая редакция, Изм. № 1).

5.2.2. При передаче управления магистральным каналом ведущая подсистема назначает активную управляющую подсистему для выполнения процесса передачи сообщений. Для этого ведущая подсистема должна направить выбранной управляющей подсистеме сообщение формата 1 с кодом функции КФ6.

5.2.3. Управляющая подсистема после принятия сообщения с кодом функции КФ6 должна стать активной и может выполнить в одном процессе передачи несколько циклов обмена сообщениями. Количество циклов обмена должно контролироваться и ограничиваться ведущей подсистемой.

5.2.4. После выполнения передачи управления магистральным каналом ведущая подсистема должна активизировать в себе функцию пассивного приема и включить контрольный отсчет времени. Если в течение установленного времени (время ожидания ответа не должно быть более 1 мс) назначенная активной подсистема не начинает передачу сообщений по магистральному каналу, ведущая подсистема повторно направляет управляющей подсистеме сообщение формата 1 с кодом функции КФ6 и признаком повторной передачи.

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

5.2.6. По окончании процесса передачи активная управляющая подсистема должна выполнить функцию возврата управления магистральным каналом. Для этого она должна направить ведущей подсистеме сообщение с кодом функции КФ7 или КФ8.

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

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

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

5.2.10. После завершения процесса передачи активная управляющая подсистема должна передать управление магистральным каналом следующей управляющей подсистеме с адресом АВ = АЦ + 1, для чего она должна выдать маркер, активизировать в себе функцию пассивного приема и включить контрольный отсчет времени.

В качестве маркера используется сообщение формата 1 (черт. 1) с кодом функции КФ13 и адресом АВ.

Если в течение установленного времени получившая маркер подсистема не начинает процесс передачи, передававшая его подсистема должна предпринять попытку передать маркер подсистемам с последующими адресами АВ = АС + 2, АВ = АС + 3 и т.д. до тех пор, пока маркер не будет принят. Адрес подсистемы, принявшей маркер, должен запоминаться данной подсистемой как последующий до проведения повторного начального захвата.

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

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

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

5.2.7 - 5.2.13. (Введены дополнительно, Изм. № 1).

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

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

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

5.3, 5.3.1, 5.3.2. (Новая редакция, Изм. № 1).

5.3.3. При централизованном опросе ведущая подсистема должна последовательно опросить все подключенные к магистральному каналу инициативные управляющие подсистемы. Ведущая подсистема должна направить каждой инициативной управляющей подсистеме сообщение формата 1 с кодом функции КФ5.

Инициативная управляющая подсистема должна направить ведущей подсистеме ответное сообщение с одним из кодов функции КФ21 - КФ24 в зависимости от своего внутреннего состояния. Последовательность операций в процедуре централизованного опроса приведена на черт. 4.

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

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

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

Процесс централизованного опроса подсистемы

Процесс децентрализованного опроса подсистемы

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

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

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

групповой записи;

записи-чтения.

5.4.1. Групповая запись должна выполняться ведущей подсистемой. При выполнении групповой записи ведущая подсистема выдает в магистральный канал сообщение формата 2, в котором в качестве адреса АВ записан код 11111111 (255) и код функции КФ1.

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

5.4.3. Подтверждение приема группового сообщения осуществляется в процессе централизованного или децентрализованного опроса, а также при возврате управления магистральным каналом, для чего в коды функций КФ7, КФ8, КФ9 - КФ12 и КФ21 - КФ24 включен бит соответствующего состояния.

5.4.4. В процессе записи ведущая подсистема или активная управляющая подсистема посылает в магистральный канал сообщение формата 2 с кодом функции КФ2, предназначенное для приема конкретной управляемой подсистемой, адрес которой указан в байте АВ. После выдачи сообщения активная управляющая подсистема включает контрольный отсчет времени и ждет ответное сообщение.

5.4.5. Адресованная подсистема опознает свой адрес и принимает посылаемое ей сообщение. В том случае, если сообщение принято без ошибки, принимающая подсистема должна выдать в магистральный канал ответ в виде сообщения формата 1 с кодом функции КФ18.

5.4.6. В случае, если в принятом сообщении обнаружена ошибка, принимающая подсистема не должна выдавать ответ.

5.4.7. Активная управляющая подсистема при отсутствии ответа в течение интервала контрольного времени должна повторно выполнить передачу того же сообщения.

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

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

(Новая редакция, Изм. № 1).

5.4.10. Процесс чтения должен начинаться посылкой активной управляющей подсистемой сообщения формата 1 с кодом функции КФ3.

5.4.11. Подсистема, которой адресовано это сообщение, в случае исправного его приема, должна выдать ответное сообщение формата 2 с кодом функции КФ19.

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

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

5.4.14. Для считывания подготовленных данных активная управляющая подсистема должна вновь обратиться к управляемой подсистеме с сообщением формата 1 с кодом функции КФ3. Если данные к этому времени подготовлены, то управляемая подсистема должна выдать ответное сообщение формата 2 с кодом функции КФ19.

Признак занятости подсистемы должен сниматься только после передачи ответного сообщения формата 2.

5.4.15. Если ответное сообщение принято активной управляющей подсистемой без ошибки, то процесс чтения на этом завершается.

5.4.16. При обнаружении ошибки или отсутствии ответа активная управляющая подсистема повторяет обращение, а затем предпринимает меры, аналогичные приведенным в пп. 5.4.7, 5.4.8.

5.4.17. Запись-чтение представляет собой совмещение процессов по пп. 5.4.4 - 5.4.15.

5.4.18. Активная управляющая подсистема посылает в магистральный канал сообщение формата 2 с кодом функции КФ4.

5.4.19. Адресованная подсистема должна принять направленное ей сообщение и сформировать ответное.

5.4.20. Ответное сообщение в данном процессе должно быть представлено форматом 2 (содержать считываемые данные) и иметь код функции КФ20.

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

6. ФИЗИЧЕСКАЯ РЕАЛИЗАЦИЯ

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

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

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

6.4. Для линий связи магистрального канала должен применяться коаксиальный кабель с волновым сопротивлением 75 Ом.

6.5. Коаксиальный кабель должен быть нагружен на обоих концах согласующими резисторами сопротивлением (75 ± 3,75) Ом. Мощность согласующих резисторов должна быть не менее 0,25 Вт.

Согласующие резисторы должны подключаться к концам линий связи при помощи ВЧ-соединителей.

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

6.6. Затухание по линии связи магистрального канала должно быть не более 18 дБ для скорости 500 кбит/с.

6.7. Суммарное затухание, вносимое каждым ответвлением от линии связи магистрального канала, не должно превышать 0,1 дБ, включая затухание, определяемое качеством точки стыковки, затухание на ответвлении и затухание, зависящее от входных-выходных параметров схем согласования.

6.8. Ответвления от линии связи магистрального канала должны выполняться коаксиальным кабелем с волновым сопротивлением 75 Ом. Длина каждого ответвления - не более 3 м. Суммарная длина всех ответвлений входит в суммарную длину магистрального канала. Подключение к линии связи должно осуществляться при помощи ВЧ-соединителей. Отключение любой из подсистем не должно приводить к разрыву линии связи.

6.9. Контроллеры связи должны содержать приемо-передающие усилители, обеспечивающие:

чувствительность по приему, не хуже......................................................... 240 мВ

уровень выходного сигнала.......................................................................... от 4 до 5 В

выходное сопротивление.............................................................................. (37,50 ± 1,88) Ом

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

символу «0» соответствует противоположная фаза относительно предыдущего символа,

Программное обеспечение АСУ МС представляет собой клиент-серверное решение, построенное на платформе MS SQL Server версий 2005 и выше и обеспечивающее разделение прав доступа к данным метрологической службы предприятий. Предусмотрены версии комплекса АСУ МС как для работы с единой, так и с распределенной базой данных (объем базы данных - до 150 000 СИ). Функциональность АСУ МС обеспечивает учет, планирование, контроль выполнения обслуживания, анализ состояния приборного парка. Специальная задача «Приемка-Выдача СИ» для поверочной лаборатории позволяет минимизировать трудозатраты на ввод данных и оформление документов по результатам обслуживания. Права пользователя для работы в различных разделах данных настраиваются администратором АСУ МС в зависимости от специфики организации метрологической службы.

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

Электронный паспорт СИ помимо основной учетной информации и регламентов обслуживания, содержит:

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

Администратор АСУ МС определяет учетную политику и настраивает образ паспорта, скрывая ненужные поля и вкладки.

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

Отчеты в АСУ МС формируются с использованием генератора FastReport; настраиваются набор и ширина столбцов, шрифт, цвет и т. д.; отчеты сохраняются в форматах rtf, xls, html. Библиотека отчетов, входящая в комплект поставки АСУ МС, может быть дополнена по запросам пользователей.

Delphi создает приложения Windows

Delphi - язык и среда программирования, относящаяся к классу RAD- (Rapid Application Development «Средство быстрой разработки приложений») средств CASE - технологии. Delphi сделала разработку мощных приложений Windows быстрым процессом, доставляющим вам удовольствие. Приложения Windows, для создания которых требовалось большое количество человеческих усилий например в С++, теперь могут быть написаны одним человеком, использующим Delphi.

Delphi обладает широким набором возможностей, начиная от проектировщика форм и кончая поддержкой всех форматов популярных баз данных. Среда устраняет необходимость программировать такие компоненты Windows общего назначения, как метки, пиктограммы и даже диалоговые панели. Работая в, вы неоднократно видели одинаковые «объекты» во многих разнообразных приложениях. Диалоговые панели (например Choose File и Save File) являются примерами многократно используемых компонентов, встроенных непосредственно в Delphi, который позволяет приспособить эти компоненты к имеющийся задаче, чтобы они работали именно так, как требуется создаваемому приложению. Также здесь имеются предварительно определенные визуальные и невизуальные объекты, включая кнопки, объекты с данными, меню и уже построенные диалоговые панели. С помощью этих объектов можно, например, обеспечить ввод данных просто несколькими нажатиями кнопок мыши, не прибегая к программированию. Это наглядная реализация применений CASE-технологий в современном программировании приложений. Та часть, которая непосредственно связана с программированием интерфейса пользователя системой получила название визуальное программирование

Выгоды от проектирования АРМ в среде Windows с помощью Delphi:

Устраняется необходимость в повторном вводе данных;

Обеспечивается согласованность проекта и его реализации;

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

Интерфейс пользователя системой

ВВЕДЕНИЕ

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

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

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

ПРЕДМЕТНАЯ ОБЛАСТЬ

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

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

преобразование данных, циркулирующих в АПК АСУ, в информационные модели, отображаемые на мониторах (СОИ - средства отображения информации);

регенерация информационных моделей (ИМ);

обеспечение диалогового взаимодействия человека с ТС АСУ;

преобразование воздействий, поступающих от ЧО (человека-оператора), в данные, используемые системой управления;

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

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

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

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

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

Поддержка сервисных функций, обеспечение дружественного интерфейса пользователя . 2.4. Решение по функциональному разбиению... среды разработки Inprise Delphi Client/Server Suite v. 4. 3.4.1. Входная и выходная информация Отличительными признаками данной АС ...

Разработка автоматизированной системы заполнения первичной документации предприятия

Дипломная работа >> Информатика

Системе. Автоматизированная система (АС ) – это человеко... различных действиях пользователя . Выбор среды разработки данной... Начиная с пятой версии в среде Delphi доступны и другие технологии, ... : Дружественный пользовательский интерфейс – необходимо организовать...

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

Курсовая работа >> Коммуникации и связь

Систем управления предприятиями (АСУ ). АСУ включают несколько автоматизированных... метки, кнопки, которые поддерживают интерфейс пользователя с базой данных. Обеспечивает... изображений. Локальная версия среды разработки – Delphi Desktop Edition, предназначен...

Разработка информационной системы (2)

Реферат >> Информатика

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

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

Сети передачи данных, используемые в АСУ ТП, можно условно разделить на два класса:

Полевые шины (Field Buses);

Сети верхнего уровня (операторского уровня, Terminal Buses).

1. Полевые шины

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

Как уже было отмечено, существует множество стандартов полевых шин, наиболее распространенными из которых являются:

Profibus DP;
Profibus PA;
Foundation Fieldbus;
Modbus RTU;
HART;
DeviceNet.

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

1. Детерминированность. Под этим подразумевается, что передача сообщения из одного узла сети в другой занимает строго фиксированный отрезок времени. Офисные сети, построенные по технологии Ethernet, - это отличный пример недетерминированной сети. Сам алгоритм доступа к разделяемой среде по методу CSMA/CD не определяет время, за которое кадр из одного узла сети будет передан другому, и, строго говоря, нет никаких гарантий, что кадр вообще дойдет до адресата. Для промышленных сетей это недопустимо. Время передачи сообщения должно быть ограничено и в общем случае, с учетом количества узлов, скорости передачи данных и длины сообщений, может быть заранее рассчитано.

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

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

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

По виду физической среды передачи данных полевые шины делятся на два типа:

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

Примером модуля, обеспечивающего подключение контроллера Simatic S7-300 к сети Profibus DP c оптоволоконным кабелем, является коммуникационный процессор CP 342-5 FO. Для подключения S7-300 к сети Profibus DP c медным кабелем можно использовать модуль CP 342-5.

2. Сети верхнего уровня

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

Какие сети используются на верхнем уровне АСУ ТП? В отличие от стандартов полевых шин, здесь особого разнообразия нет. Фактически, большинство сетей верхнего уровня, применяемых в современных АСУ ТП, базируется на стандарте Ethernet (IEEE 802.3) или на его более быстрых вариантах Fast Ethernet и Gigabit Ethernet. При этом, как правило, используется коммуникационный протокол TCP/IP. В этом плане сети операторского уровня очень похожи на обычные ЛВС, применяемые в офисных приложениях. Широкое промышленное применение сетей Ethernet обусловлено следующими очевидными моментами:

1) Промышленные сети верхнего уровня объединяют множество операторских станций и серверов, которые в большинстве случаев представляют собой персональные компьютеры. Стандарт Ethernet отлично подходит для организации подобных ЛВС; для этого необходимо снабдить каждый компьютер лишь сетевым адаптером (NIC, network interface card). Многие современные контроллеры имеют коммуникационные модули для подключения к сетям Ethernet (например, коммуникационный процессор CP 343-1 позволяет подключить S7-300 к сети Industrial Ethernet).

2) На рынке существует большой выбор недорого коммуникационного оборудования для сетей Ethernet, в том числе специально адаптированного для промышленного применения.

3) Сети Ethernet обладают большой скоростью передачи данных. Например, стандарт Gigabit Ethernet позволяет передавать данные со скоростью до 1 Gb в секунду при использовании витой пары категории 5. Как будет понятно дальше, большая пропускная способность сети становится чрезвычайно важным моментом для промышленных приложений.

4) Использование на верхнем уровне АСУ ТП сети Ethernet обеспечивает возможность простой состыковки сети АСУ ТП с локальной сетью завода (или предприятия). Как правило, существующая ЛВС завода базируется на стандарте Ethernet. Использование единого сетевого стандарта позволяет упростить интеграцию АСУ ТП в общую сеть предприятия.

Однако у промышленных сетей верхнего уровня АСУ ТП есть своя специфика, обусловленная условиями промышленного применения. Типичными требованиями, предъявляемыми к таким сетям, являются:

1. Большая пропускная способность и скорость передачи данных. Объем трафика напрямую зависит от многих факторов: количества архивируемых и визуализируемых технологических параметров, количества серверов и операторских станций, используемых прикладных приложений и т.д. В отличие от полевых сетей жесткого требования детерминированности здесь нет: строго говоря, неважно, сколько времени займет передача сообщения от одного узла к другому - 100 мс или 700 мс (естественно, это не важно, пока находится в разумных пределах). Главное, чтобы сеть в целом могла справляться с общим объемом трафика за определенное время. Наиболее интенсивный трафик идет по участкам сети, соединяющим серверы и операторские станции (клиенты). Это связано с тем, что на операторской станции технологическая информация обновляется в среднем раз в секунду, причем передаваемых технологических параметров может быть несколько тысяч. Но и тут нет жестких временных ограничений: оператор не заметит, если информация будет обновляться, скажем, каждые полторы секунды вместо положенной одной. В то же время, если контроллер (с циклом сканирования в 100 мс) столкнется с 500-милисекундной задержкой поступления новых данных от датчика, это может привести к некорректной отработке алгоритмов управления.

2. Отказоустойчивость. Достигается, как правило, путем резервирования коммуникационного оборудования и линий связи по схеме 2*N так, что в случае выхода из строя коммутатора или обрыва канала, система управления способна в кратчайшие сроки (не более 1-3 с) локализовать место отказа, выполнить автоматическую перестройку топологии и перенаправить трафик на резервные маршруты.

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

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

Рис.1 Промышленные коммутаторы SCALANCE X200 производства Siemens (слева) и LM8TX от Phoenix Contact (справа): монтаж на DIN-рейку

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

Есть и другая точка зрения на то, что такое Industrial Ethernet. Дело в том, что в последнее время разработано множество коммуникационных протоколов, базирующихся на стандарте Ethernet и оптимизированных для передачи критичных ко времени данных. Такие протоколы условно называют протоколами реального времени, имея в виду, что с их помощью можно организовать обмен данными между распределенными приложениями, которые критичны ко времени выполнения и требуют четкой временной синхронизации. Конечная цель – добиться относительной детерминированности при передаче данных. В качестве примера Industrial Ethernet можно привести:

Profinet;
EtherCAT;
Ethernet Powerlink;
Ether/IP.

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