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

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

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

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

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

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

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

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

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

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

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

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

Он состоит из АПК и протоколов взаимодействия. Аппаратно-программный комплекс обеспечивает выполнение функций:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принцип учета профессиональных навыков человека-оператора. Это значит, что при разработке системы на основе некоторых задаваемых в техническом задании исходных данных о возможном контингенте кандидатов проектируется «человеческий компонент» с учетом требований и особенностей всей системы и её подсистем. Формирование же концептуальной модели взаимодействия человека и технических средств АСУ означает осознание и овладение алгоритмами функционирования подсистемы «человек - техническое средство» и овладение профессиональными навыками взаимодействия с ЭВМ.

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

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

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

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

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

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

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

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

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

не используют в названиях разделов фраз (желательно не больше 2 слов);

названия разделов начинают с заглавной буквы;

названия разделов меню, связанных с вызовом диалоговых окон заканчивают многоточием;

названия разделов меню, к которым относятся каскадные меню, заканчивают стрелкой;

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

допускают использовать «горячие клавиши», соответствующие комбинации клавиш отображают в заголовках разделов меню;

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

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

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

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

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

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

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

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

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

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

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

УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 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» соответствует противоположная фаза относительно предыдущего символа,

Обмен информацией между устройствами, входящими в состав автоматизированной системы (компьютерами, контроллерами, датчиками, исполнительными устройствами), происходит в общем случае через промышленную сеть (Fieldbus , "полевую шину") [Cucej ].

• LAN (Local Area Network) - сети, расположенные на ограниченной территории (в цехе, офисе, в пределах завода);
• MAN (Metropolitan Area Networks) - сети городов;
• WAN (Wide Area Network) - глобальная сеть, охватывающая несколько городов или континентов. Обычно для этого используют Internet -технологию.

В настоящее время насчитывается более 50 типов промышленных сетей (Modbus, Profibus, DeviceNet, CANopen , LonWorks , ControlNet , SDS , Seriplex , ArcNet , BACnet , FDDI , FIP , FF , ASI , Ethernet , WorldFIP , Foundation Fieldbus , Interbus , BitBus и др.). Однако широко распространенными является только часть из них. В России подавляющее большинство АСУ ТП используют сети Modbus и Profibus . В последние годы возрос интерес к сетям на основе CANopen и DeviceNet. Распространенность в России той или иной промышленной сети связана, в первую очередь, с предпочтениями и активностью Российских фирм, продающих импортное оборудование.

2.1. Общие сведения о промышленных сетях

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

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

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

Наиболее важными параметрами интерфейса являются пропускная способность и максимальная длина подключаемого кабеля. Промышленные интерфейсы обычно обеспечивают гальваническую развязку между соединяемыми устройствами. Наиболее распространены в промышленной автоматизации последовательные интерфейсы RS-485, RS-232, RS-422, Ethernet, CAN, HART, AS-интерфейс.

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

Обычно сеть использует несколько протоколов, образующих стек протоколов - набор связанных коммуникационных протоколов, которые функционируют совместно и используют некоторые или все семь уровней модели OSI [Руководство ]. Для большинства сетей стек протоколов реализован с помощью специализированных сетевых микросхем или встроен в универсальный микропроцессор.

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