ГОСТ Р ИСО 15745-3-2010
Группа Т58
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Системы промышленной автоматизации и интеграция
ПРИКЛАДНАЯ ИНТЕГРАЦИОННАЯ СРЕДА ОТКРЫТЫХ СИСТЕМ
Часть 3
Эталонное описание систем управления на основе стандарта МЭК 61158
Industrial automation system and integration. Open systems application integration frameworks. Part 3: Reference description for IEC 61158-based control systems
ОКС 25.040.40
Дата введения 2011-09-01
Предисловие
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"
Сведения о стандарте
1 ПОДГОТОВЛЕН Научно-техническим центром ИНТЕК на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. N 864-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 15745-3:2003* "Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 3. Эталонное описание систем управления на основе стандарта МЭК 61158" (ISO 15745-3:2003 "Industrial automation system and integration - Open systems application integration frameworks - Part 3: Reference description for IEC 61158-based control systems").
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе "Национальные стандарты", а текст изменений и поправок - в ежемесячно издаваемых информационных указателях "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет
Введение
Прикладная интеграционная среда (AIF), описанная в ИСО 15745, определяет элементы и правила, позволяющие облегчить решение следующих вопросов:
- систематическая организация и представление требований прикладной интеграции с помощью моделей интеграции;
- разработка технических условий интерфейса в форме профилей интероперабельности приложений (AIP), позволяющих производить выбор как необходимых ресурсов, так и документации приложений "в заводском исполнении".
Стандарт ИСО 15745-1 определяет общие элементы и правила описания моделей интеграции и AIP с относящимися к ним профилями компонент - профилями процессов, профилями обмена информацией и профилями ресурсов. Контекст ИСО 15745 и структурный обзор составляющих AIP приведен на рисунке 1 в ИСО 15745-1:2003.
Настоящий стандарт расширяет исходную AIF, описанную в ИСО 15745-1, путем определения специфических технологических элементов и правил описания как профилей коммуникационных сетей, так и связанных с коммуникациями аспектов профилей устройств, специфичных для систем управления, основанных на стандарте МЭК 61158 (P-NET, PROFIBUS, WorldFIP, ControlNet и INTERBUS). Эти технологии используют профили, установленные в МЭК 61158, которые описаны в МЭК 61784-1. Профили для систем управления, представленных в ИСО/МЭК 8802-3, не входят в область применения данного стандарта и установлены в ИСО 15745-4.
_______________
P-NET является зарегистрированной торговой маркой Международной организации пользователей P-NET Aps (IPUO). Контроль использования торговой марки передан бесприбыльной организации IPUO. Эта информация предоставлена для удобства пользователей настоящего стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки P-NET. Применение торговой марки P-NET требует разрешения IPUO.
PROFIBUS является торговой маркой PROFIBUS Nutzerorganisation e.V. (PNO). Контроль использования торговой марки передан бесприбыльной организации PNO. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки PROFIBUS. Применение торговой марки PROFIBUS требует разрешения PNO.
WorldFIP является зарегистрированной торговой маркой Ассоциации WorldFIP. Контроль использования торговой марки передан бесприбыльной организации Ассоциация WorldFIP. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки WorldFIP. Применение торговой марки WorldFIP требует разрешения Ассоциации WorldFIP.
ControlNet является торговой маркой ControlNet International, Ltd. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки ControlNet. Применение торговой марки ControlNet требует разрешения ControlNet International, Ltd.
INTERBUS является торговой маркой Phoenix Contact GmbH & Co. KG, контроль использования торговой марки передан бесприбыльной организации INTERBUS Club. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки INTERBUS. Применение торговой марки INTERBUS требует разрешения INTERBUS Club.
В частности, настоящий стандарт описывает специфические технологические шаблоны профилей для профилей устройств или экземпляров профилей коммуникационной сети, являются частью профиля ресурсов, определенного в ИСО 15745-1. Профиль устройства и экземпляры XML-файлов профиля коммуникационной сети включены в экземпляр профиля XML-ресурсов с использованием ProfileHandle_DataType согласно определениям в ИСО 15745-1:2003, 7.2.5.
Установленные AIF, использующие элементы и правила ИСО 15745-1, могут быть легко совместимы с профилями компонент, определенных с использованием элементов и правил, установленных в настоящем стандарте.
Настоящий стандарт был подготовлен техническим комитетом ИСО ТК 184 "Системы промышленной автоматизации и интеграция", подкомитетом ПК 5 "Архитектура, коммуникации и структуры интеграции".
Стандарт ИСО 15745 состоит из следующих частей под общим названием "Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем":
- Часть 1. Общее эталонное описание;
- Часть 2. Эталонное описание систем управления на основе стандарта ИСО 11898;
- Часть 3. Эталонное описание систем управления на основе стандарта МЭК 61158;
- Часть 4. Эталонное описание систем управления на основе стандарта Ethernet.
1 Область применения
Настоящий стандарт распространяется на специфические технологические элементы и правила описания как профилей коммуникационной сети, так и связанных с коммуникациями аспектов профилей устройств, относящихся к системам управления, на основе МЭК 61158. Настоящий стандарт не распространяется на профили систем управления на основе ИСО/МЭК 8802-3.
Примечание - Общие элементы и правила для описания моделей интеграции и профилей интероперабельности приложений совместно с профилями их компонент (профилями процессов, профилями обмена информацией и профилями ресурсов) установлены в стандарте ИСО 15745-1.
При описании среды интеграции приложений настоящий стандарт должен использоваться совместно с ИСО 15745-1.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты*, которые необходимо учитывать при использовании настоящего стандарта. В случае ссылок на документы, в которых указана дата утверждения, необходимо пользоваться только указанной редакцией. В том случае, когда дата утверждения не приведена, следует пользоваться последней редакцией ссылочных документов, включая любые поправки и изменения к ним.
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .
ИСО 639-1:2002 Коды для представления названий языков. Часть 1. Двухбуквенный код (ISO 639-1:2002 Codes for the representation of names of languages - Part 1: Alpha-2 code)
ИСО 639-2:1998 Коды для представления названий языков. Часть 2. Трехбуквенный код (ISO 639-2:1998 Codes for the representation of names of languages - Part 2: Alpha-3 code)
ИСО 3166-1:1997 Коды для представления названий стран и единиц их административно-территориального деления. Часть 1. Коды стран (ISO 3166-1:1997 Codes for the representation of names of countries and their subdivisions - Part 1: Country codes)
ИСО 9506-1:2000 Системы промышленной автоматизации. Спецификация производственных сообщений. Часть 1. Определение услуг (ISO 9506-1:2000 Industrial automation systems - Manufacturing Message Specification - Part 1: Service definition)
ИСО 15745-1:2003 Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 1. Общее эталонное описание (ISO 15745-1:2003 Industrial automation and systems integration - Open systems application integration framework - Part 1: Generic reference description)
ИСО/МЭК 10646-1:2000 Информационные технологии. Универсальный многооктетный набор кодированных знаков (UCS). Часть 1. Архитектура и основная многоязычная матрица (ISO/IEC 10646-1:2000 Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane)
МЭК 61131-3:2003 Контроллеры программируемые. Часть 3. Языки программирования (IEC 61131-3:2003 Programmable controllers - Part 3: Programming languages)
МЭК 61158 (все части) Передача цифровых данных для измерения и управления. Полевая шина для систем автоматического регулирования и управления технологическими процессами (IEC 61158 (all parts) Digital data communications for measurement and control - Fieldbus for use in industrial control systems)
МЭК 61784-1:2003 Цифровые передачи данных для измерения и управления. Часть 1. Профильные наборы для непрерывного и раздельного производства полевых шин для систем автоматического регулирования и управления технологическими процессами (IEC 61784-1:2003 Digital data communications for measurement and control - Part 1: Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems)
МЭК 61804-2 Блоки функциональные (FB) для управления процессом. Часть 2. Спецификация концепции FB и языка описания электронного устройства (EDDL) (IEC 61804-2 Function blocks (FB) for process control - Part 2: Specification of FB concept and electronic device description language (EDDL))
_______________
Готовится к публикации первое издание.
ANSI TIA/EIA-232-F:1997 Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange
ANSI TIA/EIA-485-A:1998 Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems
EN 50170:1996 Volume 3 Part 7-3 General purpose field communication system - WorldFIP - Network Management
IEEE Std 754-1985 (R1990) IEEE Standard for Binary Floating Point Arithmetic
REC-xm1-20001006 Extensible Markup Language (XML) 1.0 Second Edition - W3C Recommendation 6 October 2000
REC-xmlschema-1-20010502 XML Schema Part 1: Structures - W3C Recommendation 02 May 2001
REC-xmlschema-2-20010502 XML Schema Part 2: Datatypes - W3C Recommendation 02 May 2001
RFC 1738:1994 Uniform Resource Locators (URL) - Internet Engineering Task Force (IETF), Request for Comments (RFC)
RFC 1759:1995 Printer MIB - Internet Engineering Task Force (IETF), Request for Comments (RFC)
UML V1.4 OMG - Unified Modeling Language Specification (Version 1.4, September 2001)
3 Термины и определения
В настоящем стандарте используются термины из ИСО 15745-1.
Примечание - Термины UML и обозначения, использованные в настоящем документе, приведены в ИСО 15745-1:2003, Приложение А.
4 Обозначения терминов
AIF - интеграционная среда приложений;
AIP - профиль интероперабельности приложений;
AL - уровень приложения;
ASCII - американский стандартный код для обмена информацией;
ASE - элемент сервиса приложения;
СIР - общий промышленный протокол;
_______________
CIP является торговой маркой ControlNet International, Ltd. и Open DeviceNet Vendor Association, Inc. Эта информация предоставлена для удобства пользователей ISO 15745 и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использование торговой марки CIP. Применение торговой марки CIP требует разрешения ControlNet International, Ltd и Open DeviceNet Vendor Association, Inc.
СР - профиль коммуникации;
CRC - циклический избыточный контроль;
DL - канальный уровень;
DP - сервисы и протокол PROFIBUS;
EDD - описание электронного устройства;
EDDL - язык описания электронного устройства;
EDS - электронный бланк данных;
FDCML - язык разметки конфигурации полевого устройства;
FIP - полевой промышленный протокол;
GSD - общее описание терминала;
HMI - интерфейс "человек - машина";
I/O - ввод/вывод;
IAS - промышленная система автоматизации;
ID - идентификатор;
kbit/s - 1024 бит/с;
LSB - наименьший значащий бит;
MAU - блок передачи данных для подключения к среде;
Mbit/s - 1024x1024 бит/с;
MCS - общие сервисы сообщений;
MMS - спецификации производственных сообщений;
MPS - производственные периодические/апериодические сервисы;
MS1 - мастер класса 1;
MS2 - мастер класса 2;
NC - числовое программное управление;
NM - сетевое управление;
OSI - взаимодействие открытых систем;
PC - персональный компьютер;
PID - пропорционально-интегрально-дифференциальный контроллер;
PLC - программируемый логический контроллер;
RC - управление с помощью робота;
SM_MPS - периодическая спецификация промышленных систем менеджмента;
SMS - спецификация систем менеджмента;
SubMMS - подмножество MMS;
SWNo - номер беспроводной (гибкой) среды передачи данных;
UML - унифицированный язык моделирования;
VMD - виртуально управляемое устройство;
XML - расширяемый язык разметки.
5 Специфические технологические элементы и правила
5.1 Модели интеграции и интерфейсы IAS
Разработчики AIP должны создать модель интеграции, использующую описанные в ИСО 15745-1 правила, а также гарантировать, что основанные на МЭК 61158 профили устройств и коммуникационных сетей (как соответствующие требованиям интерфейса, так и полученные на основе существующих устройств/коммуникационных сетей) включают необходимые интерфейсы IAS. Интерфейсы IAS, включенные в профиль, должны быть указаны в разделе заголовков (см. ИСО 15745-1:2003, 7.2.2).
Примечание - Интерфейсы IAS описаны в ИСО 15745-1:2003, Приложение В.
5.2 Шаблоны профилей
5.2.1 Общие положения
Специфические технологические шаблоны профилей согласно МЭК 61158 разрабатываются исходя из общих шаблонов профилей, установленных в ИСО 15745-1:2003, раздел 7.
5.2.2 Содержание и синтаксис
Стандарт ИСО 15745 устанавливает шаблоны профилей, представляющие собой XML-схемы (REC-xmlschema-1-20010502 и REC-xmlschema-2-20010502) и использующие общие родовые структуры. Профили устройств и коммуникационных сетей, основанные на этих шаблонах, обычно включают следующее:
- информацию, необходимую для идентификации соединяемого устройства;
- описание данных устройства, которые могут быть доступны по сети;
- описание коммуникационных возможностей, поддерживаемых устройством;
- дополнительную информацию, относящуюся к поставщику.
Однако в некоторых технологиях, описанных в стандарте МЭК 61158, используется специальный ранее принятый синтаксис ASCII. В связи с этим для достижения обратной совместимости определения шаблонов в любых технологиях (приложения А-Е) включают все или необходимые подмножества:
- шаблонов профилей коммуникационных сетей и устройств, согласно определениям в ИСО 15745-1;
- шаблона, описанного в ИСО 15745, для инкапсуляции файлов, содержащих ранее принятый синтаксис ASCII ("оболочку");
- ранее принятого синтаксиса ASCII.
5.2.3 Заголовок
Заголовок шаблона профиля, определенный в ИСО 15745-1:2003, 7.2.2, используется для специфических технологических шаблонов профилей, описанных в МЭК 61158. Каждая технология использует одно или несколько имен для идентификации технологии или ее частных компонент (см. таблицу 1). Выбранное имя должно сохраняться в атрибуте ProfileTechnology в заголовке.
Таблица 1 - Имена ProfileTechnology
Имя ProfileTechnology | Технология |
ControlNet | ControlNet |
CIP | ControlNet |
EDS | ControlNet |
GSD | PROFIBUS |
EDDL | PROFIBUS |
P-NET | P-NET |
WorldFIP | WorldFIP |
INTERBUS | INTERBUS |
FDCML | INTERBUS |
5.3 Специфические технологические профили
Структура специфического технологического профиля коммуникационной сети и структура аналогичного профиля связанных с коммуникациями аспектов устройства, основанные на технологиях полевой шины стандарта МЭК 61158, описаны в разделе 6. Рассматриваемые технологии включают:
- ControlNet (см. 6.1);
- PROFIBUS (см. 6.2);
- P-NET (см. 6.3);
- WorldFIP (см. 6.4);
- INTERBUS (см. 6.5).
Соответствующие определения шаблона профиля приведены в приложениях А-Е.
6 Профили устройств и коммуникационных сетей в системах управления, основанные на МЭК 61158
6.1 ControlNet
6.1.1 Профиль устройства
6.1.1.1 Общие положения
На рисунке 1 в виде диаграммы представлена структура классов профиля устройства ControlNet.
Рисунок 1 - Диаграмма классов профиля устройства ControlNet
Имеющиеся форматы профилей устройств ControlNet описаны в А.2.
XML-схема, представляющая шаблон профиля устройства ControlNet, определена в разделе А.2.1.3.3. Имя файла данной схемы должно быть "CIP_Device_Profile.xsd".
Примечание - Диаграмма классов профиля устройства ControlNet, представленная на рисунке 1, определяет только основные классы. Далее эти классы рассматриваются более детально. Подробности приведены в Приложении А.
XML-схема, представляющая инкапсуляцию ранее принятого ControlNet EDS в шаблон профиля устройства, описанного в ИСО 15745, определена в А.2.2.2. Имя файла данной схемы должно быть "EDS_Device_Profile_wrapper.xsd". Синтаксис ASCII прежнего EDS описан в А.4.
6.1.1.2 Device identity
Класс Deviceldentity содержит атрибуты, которые уникальным образом идентифицируют устройство, и поддерживает сервисы, позволяющие извлечь эту информацию из устройства.
Эти атрибуты предоставляют, в частности, следующие данные:
- идентификацию изготовителя (имя и идентификационный код);
- идентификацию устройства (тип устройства, наименование продукта, проверка, серийный номер);
- классификацию устройства;
- место хранения дополнительной информации (например, иконки).
6.1.1.3 Device manager
Класс DeviceManager содержит атрибуты и поддерживает сервисы, используемые для контроля и конфигурирования устройства.
Эти атрибуты предоставляют такие возможности, как:
- проверка объекта идентификации ControlNet;
- наличие информации о структуре устройства (для устройств, интегрированных в модульную систему).
Сервисы позволяют:
- переустановку устройства в начальное состояние;
- извлечение атрибутов DeviceManager.
6.1.1.4 Device function
Класс DeviceFunction содержит атрибуты и поддерживает сервисы, позволяющие управлять функциями устройства (например, его конфигурацией).
Пример - Примерами объектов класса DeviceFunction являются объекты "перегрузка", "состояние наличия", "аналоговый ввод", "дискретный вывод".
Примечание - Класс DeviceFunction не описан в ИСО 15745-3.
6.1.1.5 Application process
На рисунке 2 в виде диаграммы представлена структура класса ApplicationProcess.
Рисунок 2 - Диаграмма класса ApplicationProcess профиля устройства ControlNet
Класс Assembly объединяет несколько объектов данных процесса применения в единый блок в целях оптимизации коммуникаций. Класс Parameter предоставляет стандартный интерфейс для оценки отдельных объектов данных процесса применения. Класс ParameterGroup устанавливает группы связанных параметров для специальных целей (например, конфигурации, мониторинга).
Классы Assembly и Parameter поддерживают атрибуты и сервисы на уровнях класса и экземпляра класса.
Классы Assem, Param и Group определяют индивидуальные экземпляры главных классов.
Примечание - Классы Assembly и Parameter соответствуют объектам Assembly и Parameter ControlNet. Объект Assembly описан в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2).
6.1.2 Профиль коммуникационной сети
6.1.2.1 Общие положения
На рисунке 3 в виде диаграммы представлена структура классов профиля коммуникационной сети ControlNet.
Рисунок 3 - Диаграмма классов профиля коммуникационной сети ControlNet
Существующие форматы профилей коммуникационных сетей ControlNet описаны в А.3.
XML-схема, представляющая шаблон профиля коммуникационной сети ControlNet, определяется в А.3.1.3. Имя файла данной схемы должно быть "CNet_CommNet_Profile.xsd".
XML-схема, представляющая инкапсуляцию ранее принятого ControlNet EDS в шаблон профиля коммуникационной сети, описанного в ИСО 15745, определяется в А.3.2.2. Имя файла данной схемы должно быть "EDS_CommNet_Profile_wrapper.xsd". Ранее принятый синтаксис ASCII EDS описывается в А.4.
6.1.2.2 Application layers
Класс ApplicationLayers представляет комбинированные профили трех верхних уровней OSI - модели интеграции коммуникационной сети ControlNet.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 3:
- ConnectionManager определяет характеристики, связанные с соединениями и управлением соединениями;
- MessageRouter определяет характеристики, связанные с маршрутизацией внутренних сообщений в устройстве.
Примечание - Объекты Connection Manager и Message Router описаны в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2).
6.1.2.3 Transport layers
Класс TransportLayers представляет комбинированные профили для четырех низших уровней OSI - модели интеграции коммуникационной сети ControlNet.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 3:
- CNPhysicalLayer определяет характеристики физического уровня (например, провода, задержки);
- CNLinkLayer и ControlNetObject определяют характеристики, связанные с конфигурацией и мониторингом канала передачи данных;
- Port определяет порты устройства, предназначенные для направления сообщений с одного канала передачи данных на другой.
Примечание - Объект ControlNet описан в МЭК 61158-4:2003 (тип 2).
6.1.2.4 Network management
Класс NetworkManagement представляет конфигурацию сети и возможности регулирования характеристик модели интеграции коммуникационной сети ControlNet.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 3:
- ControlNetScheduling определяет характеристики, связанные с распределением запланированного времени передачи;
- Keeper определяет характеристики, связанные с управлением сетью;
- NM-MessageRouter, NM-ConnectionManager и NM-ControlNetObject определяют характеристики, связанные с управлением классами соответствующих объектов.
Примечание - Соответствующие объекты ControlNetScheduling и Keeper описаны в МЭК 61158-4:2003 (тип 2).
6.2 PROFIBUS
6.2.1 Профиль устройства
На рисунке 4 в виде диаграммы представлена структура классов профиля устройства PROFIBUS.
Рисунок 4 - Диаграмма классов профиля устройства PROFIBUS
Информация для классов Deviceldentity, DeviceManager и ApplicationProcess приведена в ранее принятых форматах EDD и GSD профиля устройства.
Класс DeviceFunction содержит атрибуты и вспомогательные сервисы, которые позволяют выполнять управление функциями устройства (например, производить их конфигурирование).
Пример - Примерами объектов DeviceFunction являются объекты "аналоговый ввод" и "дискретный вывод".
Примечание - Класс DeviceFunction не определен в ИСО 15745-3.
Существующие форматы профилей устройств PROFIBUS описаны в В.2.
XML-схема, представляющая инкапсуляцию ранее принятых форматов EDD и GSD устройства PROFIBUS в шаблон профиля устройства, описанного в ИСО 15745, определена в В.2. Имя файла данной схемы должно быть "GSD_Device_Profile_wrapper.xsd" или "EDD_Device_Profile_wrapper.xsd". Синтаксис ASCII прежнего EDDL описан в МЭК 61804-2, используя профиль PROFIBUS МЭК 61804-2: изд.1, F.2.
Простые устройства, в которых отсутствует необходимость иметь EDD, должны ссылаться на GSD.
Эквивалентность классов Deviceldentity, DeviceManager и ApplicationProcess определена в МЭК 61804-2 или в случае ссылки на GSD - в В.4.
6.2.2 Профиль коммуникационной сети
6.2.2.1 Общие положения
На рисунке 5 в виде диаграммы представлена структура классов профиля коммуникационной сети PROFIBUS.
Рисунок 5 - Диаграмма классов профиля коммуникационной сети PROFIBUS
Существующие форматы профилей коммуникационной сети PROFIBUS описаны в В.3.
Имя файла данной XML-схемы должно быть "GSD_CommNet_Profile.xsd".
XML-схема, представляющая инкапсуляцию ранее принятого GSD устройств в шаблон профиля коммуникационной сети PROFIBUS, описанной в ИСО 15745, определяется в В.3. Имя файла данной схемы должно быть "GSD_CommNet_Profile_wrapper.xsd". Синтаксис ASCII ранее принятого GSD представлен в В.4 и В.5.
6.2.2.2 Application layers
Класс ApplicationLayers коммуникационной сети PROFIBUS представляет комбинированные профили трех верхних уровней OSI - модели интеграции коммуникационной сети PROFIBUS (см. МЭК 61784-1:2003 СР3/1 и СР3/2, особенно подразделы для протокола AL и сервиса AL).
6.2.2.3 Transport layers
Класс TransportLayers коммуникационной сети PROFIBUS представляет комбинированные профили для четырех низших уровней OSI - модели интеграции коммуникационной сети PROFIBUS (см. МЭК 61784-1:2003 СР3/1 и СР3/2, особенно подразделы для протокола DL и сервиса DL).
6.2.2.4 Network management profile
Класс NetworkManagement profile коммуникационной сети PROFIBUS представляет конфигурирование сети и возможность регулировки характеристик модели интеграции коммуникационной сети PROFIBUS.
6.3 P-NET
6.3.1 Профиль устройства
Переменные в устройствах P-NET обычно организованы в каналы (channels). Channel представляет собой совокупность связанных переменных и функций для единичного сигнала процесса. Он может поддерживать до 16 регистров, каждый из которых имеет свой собственный номер SoftWire (SWNo). Содержание каждого регистра может включать любой тип данных, в том числе сложные структуры, например многомерные таблицы и базы данных.
В каждом устройстве P-NET должен быть представлен хотя бы один сервисный канал (serviceChannel). ServiceChannel содержит информацию, используемую для облегчения получения сервиса устройства, например глобальный уникальный идентификатор (GUID), информацию об ошибках и т.д. Все другие каналы, включенные в данное устройство, зависят от типа устройства. Устройство может включать ряд каналов одинакового типа и/или совокупность каналов различного типа.
Пример 1 - Примеры различных стандартных типов каналов включают цифровой ввод, цифровой вывод, аналоговые измерения, пропорционально-интегрально-дифференциальный контроллер (PID) и т.д. Дополнительные типы каналов может определить пользователь.
Профиль устройства P-NET должен описывать все достижимые в сети переменные и каналы в устройстве в объекте ApplicationProcess. Профиль устройства включает также объекты для управления устройством и его идентификации (см. рисунок 6).
Рисунок 6 - Диаграмма классов профиля устройства P-NET
Пример 2 - Примеры Device Function - расходомер, контроллер, аналоговый ввод 4-20 мА, цифровой ввод/вывод.
Примечание - В P-NET не существует специальных сервисов для доступа к характеристикам объектов DeviceFunction, DeviceManager и Deviceldentity. Данные характеристики могут быть отображены в объектах ApplicationProcess и доступны в сети с помощью Application Protocol Data Unit (APDU), установленного в классе P-NET ApplicationLayers (см. 6.3.2.2).
Атрибуты и подклассы классов профиля устройства подробно изложены в С.1, где установлены XML-схемы, требующиеся для профилей устройств. Имя файла данной схемы должно быть "P-NetDeviceProfile.XSD".
6.3.2 Профиль коммуникационной сети
6.3.2.1 Общие положения
На рисунке 7 в виде диаграммы представлена структура классов профиля коммуникационной сети P-NET.
Рисунок 7 - Диаграмма классов профиля коммуникационной сети P-NET
XML-схема, представляющая профиль коммуникационной сети P-Net, определяется в С.2. Имя файла данной схемы должно быть "P-NetCommNetworkProfile.XSD".
6.3.2.2 Application layers
Application layers коммуникационной сети P-NET должен всегда предоставлять сервисы и элементы протокола, необходимые для оценки переменных, определенных в профиле устройства P-NET. Сервисы и элементы протокола представлены в APDU.
6.3.2.3 Transport layers
6.3.2.3.1 Общие положения
Класс TransportLayers представляет комбинированные профили для четырех низших уровней OSI - модели интеграции коммуникационной сети. Объект TransportLayers состоит из одного или нескольких объектов PhysicalLayer (по одному на каждый физический порт) и объекта DataLinkLayer.
6.3.2.3.2 PhysicalLayer
Объект PhysicalLayer должен определять поддерживаемый электрический эталон и скорость двоичной передачи в бодах. Действующие электрические эталоны - RS232 и RS485. Правильные значения скорости двоичной передачи в бодах для RS232 - 1200, 2400, 4800, 9600, 19200 и 38400 бит/с. Для RS485 правильное значение скорости двоичной передачи в бодах только 76800 бит/с.
6.3.2.3.3 DataLinkLayer
Уровень DataLinkLayer коммуникационной сети P-NET должен всегда предоставлять элементы протокола, необходимые, согласно классу устройства, установленному объектом NetworkManagement. Наиболее подходящие классы устройств - Master, Simple node или Slave.
Объект DataLinkLayer должен установить поддерживаемый метод обнаружения ошибок. Наиболее подходящие методы - Normal и Reduced.
6.3.2.4 NetworkManagement
Диаграмма класса NetworkManagement представлена на рисунке 8. Она состоит из нескольких объектов типа Master, Simple Node или Slave для каждой физической точки соединения, определенной в профиле OSI-U.
Рисунок 8 - Диаграмма класса NetworkManagement профиля коммуникационной сети P-NET
6.4 WorldFIP
6.4.1 Профиль устройства
6.4.1.1 Структура главного класса
На рисунке 9 в виде диаграммы представлена структура главного класса профиля устройства WorldFIP.
Рисунок 9 - Диаграмма класса профиля устройства WorldFIP
Требуемый формат профиля устройства WorldFIP описан в D.1. XML-схема, представляющая шаблон профиля устройства WorldFIP, определена в D.1.3. Имя файла данной схемы должно быть "WFIPDEVP.XSD".
Примечание 1 - Для лучшей читаемости диаграмма класса профиля устройства WorldFIP должна быть разделена на четыре диаграммы класса.
Примечание 2 - Эти диаграммы отображены в одной и той же XML-схеме, определенной в D.1.3.
Примечание 3 - Диаграммы класса профиля устройства WorldFIP, показанные на рисунках 9-12, определяют главные классы. Некоторые классы подвергаются дальнейшей декомпозиции с учетом подробностей, определенных в D.1.
6.4.1.2 Device identity
Класс Deviceldentity состоит из дочерних классов, показанных на рисунке 10 и описанных в таблице 2.
Рисунок 10 - Диаграмма класса Deviceldentity
Таблица 2 - Декомпозиция класса Deviceldentity
Класс | Описание | Профиль | Тип | Экземпляр |
DeviceVendor | Имя изготовителя или поставщика устройства | X | X | X |
DeviceProductType | Тип устройства | X | X | X |
DeviceConformityClass | Класс соответствия (см. D.1.2) | X | X | X |
DeviceProductName | Имя, присвоенное продукту поставщиком | X | X | X |
DeviceProductCode | Уникальный идентификатор (ID), обозначающий тип устройства, формат по выбору поставщика | X | X | |
DeviceRevision | Проверка спецификации, которой соответствует данное устройство | X | X | X |
DeviceSerialNumber | Серийный номер экземпляра устройства | X | ||
Примечание - Пометка в колонках "Профиль", "Тип" и "Экземпляр" указывает, что некий дочерний класс подходит или не подходит для использования в профиле устройства, описании типа устройства или описании экземпляра устройства | ||||
6.4.1.3 Device Manager
6.4.1.3.1 Общие положения
На рисунке 11 в виде диаграммы представлен класс DeviceManager профиля WorldFIP.
Рисунок 11 - Диаграмма класса DeviceManager профиля WorldFIP
Любое устройство представлено физическим узлом, относящимся к оборудованию WorldFIP, который принимает участие в прикладных функциях и поддерживает коммуникационные функции.
Примечание - Устройство может включать несколько физических узлов, если оно обладает несколькими точками в одной сети или в различных сетях (например, шлюзы, центральное оборудование и т.д.).
6.4.1.3.2 PhysicalNode
6.4.1.3.2.1 Identifier
Каждый физический узел имеет уникальный идентификатор.
6.4.1.3.2.2 ManagementVariable
Physical node управляются с помощью SM_MPS и используют две или несколько переменных управления, роль и идентификаторы которых зафиксированы на основании значения DeviceConformityClass (см. D.1.2).
6.4.1.3.2.3 LogicalNode
Пользовательское приложение в физическом узле подвергается декомпозиции в одном или нескольких логических узлах в контексте выполняемых операций обработки в физическом узле от имени приложения. Пользовательское приложение описывается одним или несколькими логическими узлами.
Логический узел может быть сформирован из нескольких логических узлов.
Подробные сведения о логических узлах приведены в D.1.2.
6.4.1.3.2.4 FunctionBlock
Прикладные функции логического узла состоят из набора объектов уровня пользователя, представляемых функциональными блоками.
Функциональный блок позволяет производить идентификацию и определение простых или комплексных элементарных операций процесса обработки.
Функциональный блок может состоять из нескольких функциональных блоков.
Подробные сведения о функциональных блоках приведены в D.1.2.
6.4.1.3.2.5 ExchangeBlock
Блоки обмена являются специализированными функциональными блоками. Их роль состоит в моделировании механизмов обмена данными, который необходим между различными удаленными друг от друга сущностями пользователя (например, логическими узлами), расположенными в различных устройствах (например, физических узлах), в целях выполнения при необходимости синхронизации их функций в процессе.
6.4.1.4 Device function
На рисунке 12 в виде диаграммы представлен класс DeviceFunction профиля устройства WorldFIP
Рисунок 12 - Диаграмма класса DeviceFunction профиля устройства WorldFIP
Примечание - Определение объекта DeviceDataSheet, относящегося к классу DeviceFunction, не рассматривается в данном стандарте.
6.4.1.5 Application process
Объект ApplicationProcess состоит из функциональных блоков и дополнительных блоков обмена, представленных в 6.4.1.3.2.4 и 6.4.1.3.2.5.
6.4.2 Профиль коммуникационной сети
6.4.2.1 Структура главного класса
Требуемый формат профиля коммуникационной сети WorldFIP описан в D.2. XML-схема, представляющая шаблон профиля коммуникационной сети WorldFIP, определена в D.2.5. Имя файла данной схемы должно быть "WFIPCOMP.XSD".
Примечание 1 - Для лучшей читаемости диаграмма класса профиля коммуникационной сети WorldFIP должна быть разделена на пять диаграмм класса.
Примечание 2 - Эти диаграммы отображены в одной и той же XML-схеме, определенной в D.2.5.
Примечание 3 - Диаграммы класса профиля коммуникационной сети WorldFIP, показанные на рисунках 13-18, определяют главные классы. Некоторые классы подвергаются дальнейшей декомпозиции с учетом подробностей, описанных в D.2.
На рисунке 13 в виде диаграммы представлена структура главного класса профиля коммуникационной сети WorldFIP.
Рисунок 13 - Диаграмма класса профиля коммуникационной сети WorldFIP
Семантика атрибута CommunicationNetworkConformityClass подробно изложена в D.2.
6.4.2.2 Application layers
6.4.2.2.1 Общие положения
Класс ApplicationLayers представляет комбинированные профили для трех верхних уровней OSI - модели интеграции коммуникационной сети. Он устанавливает поддерживаемые элементы сервиса приложения и ассоциированные с ними сервисы.
ASE (Application Service Elements), определенные для WorldFIP, могут быть установлены следующими объектами профиля:
- MPS (Manufacturing Periodic/aperiodic Services).
MPS представляет собой периодическое/апериодическое обновление распределенной базы данных. Эти сервисы присутствуют во всех профилях коммуникационной сети WorldFIP;
- MCS (Message Common Services).
MCS представляет собой дополнительный уровень интерфейса, поддерживающий сервисы сообщений;
- SubMMS.
SubMMS представляет собой дополнительное подмножество сервисов MMS (Manufacturing Messages Specifications).
6.4.2.2.2 MPS
6.4.2.2.2.1 Общие положения
На рисунке 14 представлен прикладной уровень MPS профиля коммуникационной сети WorldFIP.
Рисунок 14 - Прикладной уровень MPS профиля коммуникационной сети WorldFIP
Семантика атрибута MPSConformityClass подробно изложена в D.2.2.1.2.
6.4.2.2.2.2 IdentifiedVariable
MPS обеспечивает периодический и апериодический обмен переменными между одним производителем и одной или несколькими сущностями приложения. Все общие атрибуты переменных определены в классе IdentifiedVariable. Подробные сведения об идентифицированных переменных приведены в XML-схеме в D.2.5.
6.4.2.2.2.3 ProducedVariable
В пределах распределенного приложения одна уникальная сущность приложения декларируется как производитель значений переменных. Класс ProducedVariable объединяет все атрибуты, относящиеся к переменной внутри уровня приложения производителя. Подробные сведения о произведенных переменных приведены в XML-схеме в D.2.5.
6.4.2.2.2.4 ConsumedVariable
Одна или несколько сущностей приложения декларируются как потребители значений переменных. Класс ConsumedVariable объединяет все атрибуты, относящиеся к переменной внутри уровня приложения потребителя. Подробные сведения о потребленных переменных приведены в XML-схеме в D.2.5.
6.4.2.2.2.5 ThirdPartyVariable
Некоторые сущности приложения, которые не являются ни производителями, ни потребителями значений переменных, могут обладать относящимися к ним знаниями в целях осуществления обновления их значений.
6.4.2.2.2.6 IdentifiedVariableList
Уровень приложения MPS поддерживает определение и обработку списков переменных. Список переменных определен универсально, и переменным присвоены значения на уровне сущности приложения. Список состоит исключительно из потребленных переменных. Подробные сведения о списках переменных приведены в XML-схеме в D.2.5.
6.4.2.2.2.7 TypeConstructor
Тип переменной определяется классом TypeConstructor, на который переменная имеет ссылку. На рисунке 15 показана структура класса объекта TypeConstructor.
Рисунок 15 - Переменная TypeConstructor MPS профиля коммуникационной сети WorldFIP
Подробные сведения о TypeConstructor приведены в D.2.2.1.1.
6.4.2.2.2.8 VariableAccess
VariableAccess относится к переменным и указывает используемый режим доступа. Подробные сведения о доступе к переменным приведены в XML-схеме в D.2.5.
6.4.2.2.3 MCS
На рисунке 16 представлен прикладной уровень MCS профиля коммуникационной сети WorldFIP.
Рисунок 16 - Прикладной уровень MCS профиля коммуникационной сети WorldFIP
Прикладной уровень MCS обеспечивает сервисы по мониторингу ассоциаций приложения и предоставлению возможности передачи блоков данных из прикладного уровня MCS в ассоциированном и неассоциированном режимах.
6.4.2.2.4 SubMMS
На рисунке 17 представлен прикладной уровень SubMMS профиля коммуникационной сети WorldFIP.
Рисунок 17 - Прикладной уровень SubMMS профиля коммуникационной сети WorldFIP
Семантика атрибута MMSConformityClass подробно изложена в D.2.2.3.
6.4.2.3 Transport layers
6.4.2.3.1 Общие положения
Объект TransportLayers представляет комбинированные профили для четырех нижних уровней OSI - модели интеграции коммуникационной сети. Объект TransportLayers должен быть разделен на один или несколько объектов PhysicalLayer и объект DataLinkLayer.
6.4.2.3.2 DataLinkLayer
6.4.2.3.2.1 Общие положения
На рисунке 18 представлен Data Link layer профиля коммуникационной сети WorldFIP.
Рисунок 18 - Data Link layer профиля коммуникационной сети WorldFIP
Семантика атрибута DLConformityClass подробно изложена в D.2.3.
6.4.2.3.2.2 DLVariable
Data Link layer профиля коммуникационной сети WorldFIP поддерживает циклический обмен переменными и запрос об обмене переменными.
Подробные сведения о переменных приведены в XML-схеме в D.2.5.
6.4.2.3.2.3 Message
Data Link layer профиля WorldFIP поддерживает циклическую передачу сообщений и апериодическую передачу сообщений.
Подробные сведения о сообщениях приведены в XML-схеме в D.2.5.
6.4.2.3.3 PhysicalLayer
Объект PhysicalLayer идентифицирует MAUType, тип интерфейса и поддерживаемую скорость двоичной передачи (в бодах) на физическом уровне.
6.4.2.4 NetworkManagement
Класс NetworkManagement должен определять функциональные возможности для определенной конфигурации конкретной сети WorldFIP. Управление сетью в данном случае определяется в EN 50170:1996, том 3, часть 7-3. В зависимости от класса соответствия управления сетью, документально оформленного в атрибуте NMConformityClass, WorldFIP использует SM_MPS и опционально SMS.
Функции управления сетью подразделяются на три категории:
- установка и модификации;
- проверка согласованности конфигурации;
- настройка работы в сети.
Семантика атрибута NMConformityClass подробно изложена в D.2.4.2.
6.5 INTERBUS
6.5.1 Профиль устройства
6.5.1.1 Структура главного класса
На рисунке 19 в виде диаграммы представлена структура главного класса профиля устройства INTERBUS.
Рисунок 19 - Диаграмма класса профиля устройства INTERBUS
Требуемый формат профилей устройства INTERBUS описан в Е.1. XML-схема, представляющая шаблон профиля устройства INTERBUS, определена в Е.1.6.1. Имя файла данной схемы должно быть "FDCML.XSD".
Примечание 1 - Для лучшей читаемости диаграмма класса профиля устройства INTERBUS разделена на шесть диаграмм класса.
Примечание 2 - Эти диаграммы отображены в одной и той же XML-схеме, определенной в Е.1.6.1.
Примечание 3 - Диаграммы класса профиля устройства INTERBUS, показанные на рисунках 19-25, определяют главные классы. Некоторые классы подвергаются дальнейшей декомпозиции с учетом подробностей, определенных в Приложении Е.
6.5.1.2 Device identity
Класс Deviceldentity представлен на рисунке 20.
Рисунок 20 - Диаграмма класса Deviceldentity профиля устройства INTERBUS
Класс Deviceldentity должен состоять из дочерних классов, показанных на рисунке 20 и описанных в таблице 3.
Таблица 3 - Декомпозиция класса Deviceldentity
Класс | Описание | Профиль | Тип | Экземпляр |
vendorName | Имя изготовителя или поставщика устройства | X | X | X |
vendorlD | IEEE OUI (Организация уникальных идентификаторов) (см. [3]) | X | X | |
vendorText | Может быть использован для предоставления дальнейшей информации о поставщике | X | X | X |
deviceFamily | INTERBUS специальный тип устройства (например, ввод/вывод). Список действующих типов устройства (см. таблицу Е.2) | X | X | X |
capabilities | Определение данного класса не дано в ИСО 15745-3 | X | X | |
productFamily | Определенная поставщиком конкретная серия (торговая марка) устройства | X | X | |
productName | Специальное наименование продукта, определенное поставщиком | X | X | X |
productID | Уникальный идентификатор (ID), указывающий тип устройства. Формат выбирается поставщиком | X | X | |
productText | Может быть использован для предоставления дальнейшей информации об устройстве | X | X | X |
orderNumber | Специальный номер заказа продукта для поставщика | X | X | |
version | Специальная версия продукта поставщика, атрибут versionType, позволяющий различать несколько версий (например, аппаратные средства, программно-аппаратные средства) | X | X | |
buildDate | Дата ввода программно-аппаратных средств или программного обеспечения, устанавливающих основные функциональные характеристики устройства | X | X | |
specificationRevision | Проверка спецификации, которой соответствует данное устройство | X | X | X |
instanceName | Имя экземпляра устройства | X | ||
seriaNumber | Серийный номер экземпляра устройства | X | ||
Примечание - Пометка в колонках "Профиль", "Тип" и "Экземпляр" указывает на то, что некоторый дочерний класс подходит или не подходит для использования в профиле устройства, описании типа устройства или описании экземпляра устройства. | ||||
6.5.1.3 Device manager
6.5.1.3.1 Общие положения
На рисунке 21 представлен класс DeviceManager профиля INTERBUS.
Рисунок 21 - Диаграмма класса DeviceManager профиля INTERBUS
6.5.1.3.2 LocalDataDescriptionltemList, localDataltemlocalDataDescription
Объект localDataDescriptionltemList должен представлять собой собрание объектов localDataltemDescription. Объект localDataltemDescription должен описывать объекты данных, используемых только в контексте определенного устройства.
6.5.1.3.3 DeviceStructure
6.5.1.3.3.1 Обзор
Объект deviceStructure должен представлять собой хранилище (контейнер) для всех физических объектов устройства. Такие объекты могут быть каналом, физической или логической точкой ввода/вывода, MAU, слотом для подсоединения дополнительных модулей (в качестве части устройства) или LED (светоизлучающим диодом).
6.5.1.3.3.2 ChannelList
Объект channelList должен представлять собой совокупность объектов типа channel. Объекты данного типа должны описывать физические или логические точки ввода/вывода устройства.
6.5.1.3.3.3 MAUList, MAU
MAUList определяется как собрание объектов MAU. Эти объекты должны описывать точки доступа к сетевым носителям.
6.5.1.3.3.4 SlotList, slot
Объект slotList описывает собрание объектов типа slot. Объект slot должен содержать ссылку на описание средств обмена профиля внешнего устройства INTERBUS.
Примечание - Slots используются для описания модульных устройств или различных комбинаций устройств.
6.5.1.3.3.5 IndicatorList, LEDList, LED
Объект LEDList должен представлять собой собрание объектов LED. Каждый объект LED должен описывать устройства LED.
Примечание - Класс IndicatorList может быть расширен в будущих изданиях данного стандарта.
6.5.1.3.4 CommunicationEntity
6.5.1.3.4.1 Обзор
На рисунке 22 в виде диаграммы представлен класс communicationEntity.
Рисунок 22 - Диаграмма класса communicationEntity профиля INTERBUS
Объект communicationEntity описывает сущность устройства, способного осуществлять коммуникации с другими устройствами, и должен содержать полный набор заранее определенных элементов конфигурации и описаний объектов коммуникаций. В устройстве может быть несколько объектов communicationEntity.
Пример - Примером устройства, включающего два объекта communicationEntity, является системное коммутационное устройство, в котором объединяются профили INTERBUS ведомого и ведущего устройств (см. рисунок 23).
Рисунок 23 - Пример устройства с двумя объектами communicationEntity
6.5.1.3.4.2 AdditionalltemList, additionalltem
Объект additionalltemList представляет собой собрание определенных пользователем объектов additionalltem. Объект additionalltem может быть использован для описания характеристик устройства, отличных от характеристик конфигурации или объектов коммуникации.
Примечание - Определение объекта additionalltemType не входит в область данного стандарта.
Пример - Документация устройства.
6.5.1.3.4.3 ProcessDataDescriptionList, processDataDescription
Объект processDataDescriptionList представляет собой собрание объектов processDataDescription. Эти объекты представляют описания данных процесса. Объект processDataDescription может использоваться объектом channel.
6.5.1.3.4.4 ProcessDataAssemblyList, processDataAssembly
Объект processDataAssemblyList представляет собой собрание объектов processDataAssembly. Объекты processDataAssembly служат описаниями группы объектов processDataDescription. Объект processDataAssembly обеспечивает связи с объектами processDataDescription.
6.5.1.3.4.5 ParameterDecsriptionList, parameterDecscription
Объект parameterDecsriptionList представляет собой собрание объектов parameterDecscription. Объекты parameterDecscription содержат описания переменных и объектов вызова функций.
6.5.1.3.4.6 ParameterAssemblyList, ParameterAssembly
Объект parameterAssemblyList представляет собой собрание объектов parameterAssembly. Объекты parameterAssembly являются описаниями группы объектов parameterDescription. Объект parameterAssembly обеспечивает связи с объектами parameterDescription.
6.5.1.3.4.7 MethodDescriptionList, methodDescription
Объект methodDecsriptionList представляет собой собрание объектов methodDecscription. Объекты methodDecscription представляют собой методы, которые могут быть задействованы удаленной сущностью.
6.5.1.3.4.8 LogicalConnectionPointList, logicalConnectionPoint
Объект logicalConnectionPointList представляет собой собрание объектов logicalConnectionPoint. Объект logicalConnectionPoint описывает конечную точку соединения (возможные атрибуты см. в Е.1.4.6).
Примечание - Используются только соединения между конечными точками соединений одинакового типа.
6.5.1.3.4.9 LogicalConnectionPointAssemblyList, logicalConnectionPointAssembly
Объект logicalConnectionPointAssemblyList представляет собой собрание объектов logicalConnectionPointAssembly. Объект logicalConnectionPointAssembly служит описанием группы объектов logicalConnectionPoint. Объект logicalConnectionPointAssembly обеспечивает связи между объектами logicalConnectionPoint.
6.5.1.3.4.10 MAUUsageList, MAUUsage
Объект MAUUsageList представляет собой собрание объектов MAUUsage. Объекты MAUUsage должны определять, какие объекты MAU используются communicationEntity.
6.5.1.3.4.11 InternalConnectionPointList, internalConnectionPoint
Объект internalConnectionPointList представляет собой собрание объектов internalConnectionPoint, которые определяют внутренние соединения между многими communicationEntity и/или объектами resourceEntity в том же устройстве.
6.5.1.3.4.12 SlotUsageList, slotUsage
Объект slotUsageList представляет собой собрание объектов slotUsage. Объекты slotUsage должны определять, какие слоты ассоциированы с данной communicationEntity.
6.5.1.3.4.13 CfgltemList
Объект cfgltemList может состоять из объектов dedicatedCfgltem и объектов uncomittedCfgltem.
6.5.1.3.4.14 DedicatedCfgltem
Объект dedicatedCfgltem должен представлять собой элемент конфигурации с атрибутом dedicatedCfgltemType согласно определениям в таблице Е.4 и таблице Е.5. Объект dedicatedCfgltem должен использоваться для установления соответствующих характеристик конфигурации.
6.5.1.3.4.15 UncommittedCfgltem
Объект uncommittedCfgltem должен представлять собой элемент конфигурации без атрибута dedicatedCfgltemType. Объект uncommittedCfgltem должен использоваться для установления характеристик конфигурации, которые не могут быть описаны с помощью dedicatedCfgltem.
Примечание - Определение несвязанных элементов конфигурации не входит в область настоящего стандарта.
Пример - Описание DIP-переключателя, который изменяет код идентификации (ID) устройства.
6.5.1.3.5 ProcessingEntity
На рисунке 24 представлен класс processingEntity профиля устройства INTERBUS.
Рисунок 24 - Диаграмма класса processingEntity профиля устройства INTERBUS
ProcessingEntity описывает любую сущность устройства, которая не является communicationEntity.
Примечание - Описание дочерних объектов см. в 6.5.1.3.4.
Пример - Ресурс, обладающий способностью выполнять программы.
6.5.1.4 DeviceFunction
6.5.1.4.1 Обзор
DeviceFunction в виде диаграммы представлен на рисунке 25.
Рисунок 25 - Диаграмма класса DeviceFunction профиля устройства INTERBUS
Для того чтобы создать множественные представления функций устройства, используется дополнительная XML-схема для описания DeviceFunction. Имя файла данной схемы должно быть "FDCMLИCO15745DeviceFunction.XSD". XML-схема DeviceFunction определена в Е.1.6.3.
Примечание - Определение дополнительных XML-схем, описывающих DeviceFunction, не входит в область данного международного стандарта.
6.5.1.4.2 ParameterList, parameter
Объект parameterList представляет собой собрание объектов parameter. Объект parameter описывает параметры устройства с функциональной точки зрения. Этот объект соединяется с объектом коммуникаций в CommunicationEntity.
6.5.1.4.3 FunctionList, function, inputsList, outputsList
Объект functionList представляет собой собрание объектов function. Данный объект function должен состоять из inputsList и outputsList. Эти списки должны содержать перечень ссылок на объекты parameter.
6.5.1.5 Application process
Объект applicationProcess может быть представлен одной или несколькими подходящими XML-схемами.
Примечание - Эти схемы не определены в ИСО 15745-3.
6.5.2 Профиль коммуникационной сети
6.5.2.1 Структура классов
На рисунке 26 в виде диаграммы представлена структура классов профиля коммуникационной сети INTERBUS.
Рисунок 26 - Диаграмма классов профиля коммуникационной сети INTERBUS
XML-схема, представляющая профиль коммуникационной сети INTERBUS, определена в Е.2. Имя файла данной схемы должно быть "INTERBUSCommNetworkProfile.XSD".
6.5.2.2 Transport layers
6.5.2.2.1 Общие положения
Объект TransportLayers должен представлять комбинированные профили четырех нижних уровней OSI - модели интеграции коммуникационной сети. Объект TransportLayers должен быть разделен на один или несколько объектов physicalLayerlnterface и объект dataLinkLayerlnterface.
6.5.2.2.2 PhysicalLayerlnterface
Объект physicalLayerlnterface идентифицирует MauType, тип интерфейса и поддерживаемую скорость двоичной передачи в бодах интерфейса физического уровня. Правильные типы интерфейса - localBus и remoteBus.
6.5.2.2.3 DataLinkLayerlnterface
6.5.2.2.3.1 ProcessDataChannel
Объект processDataChannel должен устанавливать длину канала обработки данных в битах.
6.5.2.2.3.2 Parameter Channel
Класс parameterChannel должен устанавливать длину канала параметров в октетах.
6.5.2.3 Application layers
Класс ApplicationLayers должен представлять комбинированные профили трех верхних уровней OSI - модели интеграции коммуникационной сети. Он устанавливает поддерживаемые элементы сервиса приложений и ассоциированные с ними сервисы.
ASE (Application Service Elements), определенные в МЭК 61158-5:2003, 13.2, могут быть установлены следующими объектами профилей:
- applicationProcess;
- applicationRelationship;
- objectManagement;
- functionlnvocation;
- другие.
Для переменных ASE выбираемые типы данных указаны на рисунке 26. Типы данных определены в МЭК 61158-5:2003, раздел 5.
6.5.2.4 Network management
6.5.2.4.1 NetworkAccessType, AssignedlDCode
Класс NetworkManagement должен определять функциональные возможности конфигурации конкретной сети профиля INTERBUS. Он включает коды идентификации (ID) - наименьший значащий октет кода профиля INTERBUS, присвоенный частному профилю коммуникационной сети, и объект networkAccessType, который включает следующее:
- либо основной профиль для основных функциональных характеристик профиля INTERBUS в терминах элементов (объект masterConfigurationElements), необходимых для конфигурирования ведущей части (master) INTERBUS;
- либо подчиненный профиль для подчиненных функциональных характеристик профиля INTERBUS в терминах элементов (объект slaveConfigurationElements), необходимых для конфигурирования подчиненной части профиля INTERBUS.
Примечание - Ведомое устройство профиля INTERBUS представляет собой устройство, получающее доступ к среде только после инициации предшествующим ведомым устройством или ведущим устройством, включая дистанционные шинные устройства, локальные шинные устройства и шинные соединители.
6.5.2.4.2 CommunicationProfile
Объект communicationProffle должен установить идентификаторы готовых к использованию коммуникационных профилей (см. 6.5.2.4.3).
6.5.2.4.3 Communication profile identifier
Communication profile identifiers определены в МЭК 61784-1:2003, подраздел 10.1. Разработчик AIP может установить дополнительные коммуникационные профили, а идентификаторами для новых коммуникационных профилей должны служить 3-значные номера от 680 до 699.
Приложение А
(справочное)
Шаблоны профилей ControlNet
А.1 Общие положения
Содержание верхних уровней сети ControlNet основано на общем промышленном протоколе (CIP). Этот протокол моделирует все коммуникационные и прикладные сущности в виде объектов. Специфические для CIP сервисы запросов сообщений должны выполняться на соответствующих экземплярах объектов (или их атрибутов). Такая схема обеспечивает формальный доступ ко всей конфигурации, статусу и данным переменных во время работы узла. В то же время соединения ввода/вывода допускают прямой обмен с базой данных ввода/вывода без промежуточной обработки. В обоих случаях все обращения к данным устройства определяются путем CIP, то есть в виде потока октетных строк, определяющего экземпляр объекта приложения, атрибут и/или конечную точку соединения.
С помощью интерфейса коммуникаций CIP используют многие опции дистанционной конфигурации устройств, включая следующие:
- сохранение информации устройства в печатном или электронном виде;
- выделенные Parameter Objects, которые предоставляют открытый интерфейс со значениями данных индивидуальных конфигурации/параметра и могут также загружать дополнительную информацию по конфигурации, например дескриптивный текст, тип данных, пределы данных и величины по умолчанию;
- выделенные Configuration Assembly, которые допускают массовую загрузку и перекачку данных конфигурации путем группировки отдельных значений данных конфигурации/параметров;
- комбинации указанных выше методов.
Средства конфигурации, имеющиеся в настоящее время для устройств на базе CIP, используют специально форматированный файл ASCII, называемый электронным бланком данных (EDS), который обеспечивает следующее:
- информацию, необходимую для идентификации присоединенного устройства;
- описание данных устройства, которые могут быть доступны через сеть (например, конфигурируемые параметры);
- описание коммуникационных возможностей, поддерживаемых данным устройством (например, соединения);
- дополнительную, относящуюся к поставщику информацию.
EDS предусматривает использование средств автоматизации выполнения процесса конфигурирования устройства. Требования EDS обеспечивают открытый, последовательный и совместимый подход к выполнению конфигурирования устройства в среде CIP.
Информация EDS в значительной степени аналогична информации, требующейся в профилях как коммуникационных сетей, так и устройств, в связи с чем указанные ниже подразделы устанавливают формат для:
- шаблонов профилей коммуникационных сетей и устройств согласно определениям в ИСО 15745-1;
- инкапсуляции файлов EDS в шаблоны ИСО 15745 ("оболочки");
- EDS, включая общую семантическую информацию.
Примечание - EDS ControlNet некоторого устройства может быть получен исходя из содержания соответствующих XML-файлов профилей устройств и коммуникационной сети, используя соответствующие таблицы стилей.
А.2 Описание шаблона профиля устройства
А.2.1 Описание шаблона профиля устройства на основе XML
А.2.1.1 Общие положения
XML-файлы профиля устройства должны соответствовать XML-схеме профиля устройства, приведенной в А.2.1.3.3.
Содержание XML-схемы выводится из диаграмм класса профиля устройства, представленных в 6.1.1 и расширенных дополнительными элементами, позволяющими дать полное описание требований к устройству или его возможностей.
А.2.1.2 Семантика элементов XML-схемы
A.2.1.2.1 ProfileBody
Этот главный элемент ассоциирован с набором атрибутов, которые предоставляют дополнительную информацию о файле профиля.
Семантика этих атрибутов установлена в А.4.1.4.2.
А.2.1.2.2 Deviceldentity
Этот элемент устанавливает поддерживаемые атрибуты и операции сущности Identity Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с дополнительной информацией для полной идентификации устройства. Когда это целесообразно, он также указывает фактические значения атрибутов экземпляра.
Семантика субэлементов Deviceldentity_lnstanceAttributes установлена в таблице А.1.
Таблица А.1 - Элементы Deviceldentity_lnstanceAttributes
Элемент XML-схемы | Атрибут объекта | Семантика |
SpecificationConformance | Нет | Строка, устанавливающая эталонную версию спецификации ControlNet |
VendCode, ProdType, ProdCode, ProdRevision | Да | См. А.4.1.4.3 |
VendName, ProdTypeStr, ProdName, Catalog, Icon | Нет | См. А.4.1.4.3 |
ExcludeFromAdapterRackConnection | ||
Status, SerialNumber | Да | Не применяется |
State, ConfigurationConsistencyValue, Heartbeatlnterval | Да | Не применяется |
DeviceClassification | Нет | См. А.4.1.4.4 и А.4.2.2.1 |
А.2.1.2.3 DeviceManager
Данный элемент устанавливает поддерживаемые атрибуты класса и сущности Identity Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с дополнительной информацией по управлению устройством. Когда это целесообразно, он также указывает фактические значения атрибутов экземпляра.
Семантика модульных субэлементов элемента DeviceManager определена в А.4.1.5.2.
А.2.1.2.4 DeviceFunction
Содержание данного элемента в настоящем стандарте подробно не рассматривается.
А.2.1.2.5 ApplicationProcess
A.2.1.2.5.1 Assembly
Этот элемент устанавливает поддерживаемые атрибуты и операции экземпляров Assembly Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с описанием отдельных экземпляров.
Семантика субэлементов Assem, ProxyAssem и ProxiedAssem элемента Assembly определена в А.4.1.4.8 и А.4.1.5.3.2.
А.2.1.2.5.2 Parameter
Этот элемент устанавливает поддерживаемые атрибуты и операции класса и сущности Parameter Object совместно с описанием отдельных экземпляров.
Семантика субэлемента Parameter_ClassAttributes элемента Parameter определена в А.4.1.4.5.
Семантика субэлементов Param, ProxyParam и ProxiedParam элемента Parameter определена в А.4.1.4.6 и А.4.1.5.3.1.
А.2.1.2.5.3 ParameterGroup
Данный элемент устанавливает группы связанных параметров для специальных целей.
Семантика субэлемента Group элемента ParameterGroup определяется в А.4.1.4.7.
А.2.1.3 XML-схемы
А.2.1.3.1 MasterTemplateTypes.xsd
Примечание - Данная XML-схема содержит все стили, определенные в составе эталонного шаблона в ИСО 15745-1:2003.
A.2.1.3.2 CIPDataTypes.xsd
Примечание - Данная XML-схема определяет пункты схемы (например, типы данных, типы элементов, группы атрибутов), использованные в других XML-схемах.
A.2.1.3.3 CIP_Device_Profile.xsd
Примечание - Данная XML-схема включает файлы "MasterTemplateTypes.xsd" (см. А.2.1.3.1) и "CIPDataTypes.xsd" (см. А.2.1.3.2).
А.2.2 Описание шаблона профиля устройства - инкапсуляция XML-файлов EDS
А.2.2.1 Общие положения
XML-файлы профиля устройства, используемые для инкапсуляции файлов EDS, должны соответствовать XML-схеме профиля устройства, установленной в А.2.2.2.
Семантика субэлементов элемента ExternalProfileHandle, используемого для ссылки на существующий файл EDS, описана в таблице А.2. В зависимости от значения атрибута WrapperReference ссылка на файл EDS может производиться либо с использованием идентификационных элементов из самого файла EDS, либо из продукта, описываемого этим EDS.
Примечание 1 - Выбор соответствующих идентификационных элементов зависит от ожидаемого применения файла оболочки.
Таблица А.2 - Элементы ExternalProfileHandle
Элементы схемы XML | WrapperReference = FILEINFO | WrapperReference = DEVICEINFO |
Profileldentification | Текст описания в файле EDS | Идентификация поставщика, тип устройства, код продукта |
ProfileRevision | EDS Проверка | Проверка продукта |
ProfileLocation | EDS HomeURL | Имя файла, иконка |
См. в А.4.1.4.2 более подробное описание. | ||
Если элементы Deviceldentity, DeviceManager, DeviceFunction и ApplicationProcess присутствуют, они должны быть совместимы с форматами, установленными в А.2.1.3.3.
Примечание 2 - Это может быть использовано на переходном этапе от устаревшего формата EDS к полному формату XML.
А.2.2.2 XML-схема: EDS_Device_Profile_wrapper.xsd
Примечание - Данная XML-схема включает файл "MasterTemplateTypes.xsd" (см. А.2.1.3.1).
А.3 Описание шаблона профиля коммуникационной сети
А.3.1 Описание шаблона профиля коммуникационной сети на основе XML
А.3.1.1 Общие положения
XML-файлы профиля коммуникационной сети должны соответствовать XML-схеме профиля коммуникационной сети, установленной в А.3.1.3.
Содержание XML-схемы выводится из диаграмм класса профиля коммуникационной сети, представленных в 6.1.2 и расширенных дополнительными элементами, позволяющими дать полное описание требований к коммуникационной сети или ее возможностям.
А.3.1.2 Семантика элементов XML-схемы
А.3.1.2.1 ProfileBody
Этот главный элемент ассоциирован с набором атрибутов, которые предоставляют дополнительную информацию о файле профиля.
Семантика этих атрибутов установлена в А.4.1.4.2.
А.3.1.2.2 Application layers
А.3.1.2.2.1 ConnectionManager
Данный элемент устанавливает атрибуты и операции поддерживаемого экземпляра Connection Manager Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с описанием отдельных экземпляров соединений.
Семантика субэлементов Connection, ProxyConnect и ProxiedConnect элемента ConnectionDescriptions определена в А.4.1.4.9 и А.4.1.5.3.3.
А.3.1.2.2.2 MessageRouter
Данный элемент устанавливает атрибуты и операции поддерживаемого экземпляра Message Router Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)).
А.3.1.2.3 TransportLayers
А.3.1.2.3.1 CNPhysicalLayer
Данный элемент определяет характеристики физического уровня.
Семантика этих субэлементов установлена в таблице А.3.
Таблица А.3 - Элементы CNPhysicalLayer
Элемент XML-схемы | Атрибут XML-схемы | Семантика |
Connectors | Среда | Устанавливает наличие или отсутствие резервной среды устройства |
NetworkAccessPort | Устанавливает наличие или отсутствие Network Access Port в устройстве | |
Delayl | Не применяется | См. А.4.2.4.1 |
А.3.1.2.3.2 CNLinkLayer
Данный элемент определяет некоторые характеристики, связанные с конфигурацией уровня канала передачи данных.
Семантика относящихся к нему субэлементов установлена в таблице А.4.
Таблица А.4 - Элементы CNLinkLayer
Элемент XML-схемы | Атрибут XML-схемы | Семантика |
Mac-IDSetting | Определяет минимальные, максимальные и представленные по умолчанию MAC-ID | |
SwitchType | Определяет имеющиеся аппаратные переключатели для настройки MAC-ID | |
SoftwareSettable | Определяет возможность установки MAC-ID с помощью программного обеспечения | |
Capacity | Не применяется | См. А.4.2.4.4 |
А.3.1.2.3.3 ControlNetObject
Этот элемент определяет атрибуты и операции поддерживаемого экземпляра ControlNet Object (см. МЭК 61158-4:2003 (тип 2)).
А.3.1.2.3.4 Ports
Этот элемент идентифицирует ports, способные маршрутизировать сообщения с одного канала передачи данных на другой.
Семантика субэлемента Port элемента Ports указана в А.4.1.4.10 и А.4.2.2.2.
А.3.1.2.4 NetworkManagement
А.3.1.2.4.1 NM-ControlNetObject
Этот элемент устанавливает атрибуты и операции поддерживаемого класса ControlNet Object (см. МЭК 61158-4:2003 (тип 2)).
А.3.1.2.4.2 NM-ConnectionManager
Этот элемент устанавливает атрибуты и операции поддерживаемого класса Connection Manager Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)).
А.3.1.2.4.3 NM-MessageRouter
Этот элемент устанавливает атрибуты и операции поддерживаемого класса Message Router Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)).
А.3.1.2.4.4 Keeper
Этот элемент устанавливает атрибуты и операции поддерживаемого класса и экземпляра Keeper Object (см. МЭК 61158-4:2003 (тип 2)).
А.3.1.2.4.5 ControlNetScheduling
Этот элемент устанавливает атрибуты и операции поддерживаемого класса и экземпляра ControlNet Scheduling Object (см. МЭК 61158-4:2003 (тип 2)).
А.3.1.3 XML-схема: CNet_CommNet_Profile.xsd
Примечание - Данная XML-схема включает файлы "MasterTemplateTypes.xsd" (см. А.2.1.3.1) и "CIPDataTypes.xsd" (см. А.2.1.3.2).
А.3.2 Описание шаблона профиля коммуникационной сети - инкапсуляция XML-файлов EDS
А.3.2.1 Общие положения
XML-файлы профиля коммуникационной сети, использованные для инкапсуляции файлов EDS, должны соответствовать XML-схеме профиля коммуникационной сети, определенной в А.3.2.2.
Семантика субэлементов элемента ExternalProfileHandle, использованных для ссылки на существующий файл EDS, представлена в таблице А.2. В зависимости от значения атрибута WrapperReference ссылка на файл EDS будет производиться с использованием элементов идентификации из самого файла EDS или из продукта, описанного в этом EDS.
Примечание - Выбор подходящих элементов для идентификации будет зависеть от ожидаемого применения файла оболочки.
А.3.2.2 XML-схема: EDS_CommNet_Profile_wrapper.xsd
Примечание - Эта XML-схема включает файл "MasterTemplateTypes.xsd" (см. А.2.1.3.1).
А.4 Электронный бланк данных (EDS)
А.4.1 Общие требования CIP EDS
А.4.1.1 Общие положения
Данный подраздел устанавливает требования по кодированию файлов электронного бланка данных (EDS), которые являются общими для всех сетей, основанных на CIP. Требования к кодированию EDS определяют стандартный формат кодирования файлов, применяемый в продуктах CIP независимо от конфигурации платформы хоста или файловой системы.
Термин "файл", используемый в данной главе, относится к любому узнаваемому формату файла, связанному с файловой системой средств конфигурации, независимо от способа хранения информации.
Файл EDS определяется как файл ASCII, включающий ASCII - представление объектов в устройстве, к которым имеется доступ из сети (например, Parameter и Assembly), и некоторую дополнительную информацию, необходимую для поддержки адресации объектов.
А.4.1.2 Содержание EDS
А.4.1.2.1 Структура EDS
Один файл должен включать полный EDS. EDS должен состоять из секций. В таблице А.5 содержатся обобщенные данные о структуре и секциях для нескольких основанных на CIP сетей, соответствующие ограничители ранее известных секций и порядок этих секций в EDS.
Таблица А.5 - Структура файлов CIP EDS
Имя секции | Принятый ограничитель | Размещение | Требуемый/ |
File Description | [File] | Первая | Требуемый |
Device Description | [Device] | Вторая | Требуемый |
Device Classification | [Device Classification] | Опциональный | |
Parameter Class | [ParamClass] | Опциональный | |
Parameters | [Params] | Опциональный | |
Parameter Groups | [Groups] | Опциональный | |
Assembly | [Assembly] | Опциональный | |
Connection Characteristics | [Connection Manager] | Опциональный | |
Port | [Port] | Опциональный | |
Modular | [Modular] | Опциональный | |
Vendor Specific | [VendorlD_vendorspecifickeyword] | Последняя | Опциональный |
Эти опциональные группы должны размещаться только за требуемыми группами | |||
Содержание EDS должно быть организовано следующим образом:
- все файлы EDS должны включать раздел File Description, являющийся первой секцией файла EDS и использующий установленный ограничитель [File];
- все файлы EDS должны включать раздел Device Description, располагающийся сразу после раздела File Description и использующий установленный ограничитель [Device];
- опциональные разделы, описанные в настоящей спецификации, могут быть представлены в любом порядке при условии, что внутри файла EDS отсутствуют упреждающие ссылки;
- относящиеся к поставщику опциональные разделы должны использовать установленные ограничители [VendorlD_vendorspecifickeyword], согласно А.4.1.2.2.11, и размещаться после всех разделов, определенных в настоящей спецификации.
А.4.1.2.2 Правила форматирования EDS
А.4.1.2.2.1 Общие положения
Файл EDS должен состоять из разделов, вводов, полей, комментариев и пустых мест. Данный подраздел определяет правила, которые должны соблюдаться при определении EDS.
А.4.1.2.2.2 Пустое место в EDS
Пустые места могут быть использованы в файле EDS, но должны игнорироваться интерпретирующей программой EDS, когда они появляются вне полей и наборов символов в двойных кавычках.
Интерпретирующая программа EDS должна рассматривать указанные ниже знаки как пробелы. Эти знаки, прочитанные интерпретирующей программой, но не кодированные как читаемые человеком знаки, означают присутствие пробелов в файле:
- символ пробела;
- новая строка;
- возврат каретки;
- переход на одну строку;
- символы табуляции вертикальные и горизонтальные;
- переход на новую страницу;
- разметка окончания файла;
- комментарии.
А.4.1.2.2.3 Символы дескриптора
Все дескрипторы внутри файла EDS должны состоять из символов ASCII, входящих в следующий список:
- буквы верхнего регистра от А до Z;
- буквы нижнего регистра от а до z;
- цифры от 0 до 9;
- специальный символ нижнего тире "_";
- символ пробела.
Пробел должен использоваться только в дескрипторе раздела. Пробел должен появляться только внутри имени раздела, множественные последовательные пробелы не допускаются.
А.4.1.2.2.4 Разделы
Файл EDS должен быть разделен на требуемые и необязательные разделы.
А.4.1.2.2.5 Ограничители разделов
Каждый раздел EDS должен быть ограничен ключевыми словами раздела в квадратных скобках (принятыми ограничителями). Принятые ограничители раздела указаны в таблице А.5.
А.4.1.2.2.6 Дескрипторы раздела
Дескриптор каждого раздела определяется как текст между ограничителем "[" дескриптора в начале раздела и конечным ограничителем "]". Символы, разрешенные для использования в дескрипторах раздела, определены в А.4.1.2.2.3. Существует два типа дескрипторов раздела - общий и относящийся к поставщику (продавцу).
А.4.1.2.2.7 Порядок разделов
Каждый требуемый раздел должен располагаться в требуемом порядке, установленном в А.4.1.2. Необязательные разделы могут быть пропущены полностью либо включены с символами - заполнителями пустых данных. Кроме относящегося к поставщику раздела(ов), необязательные разделы могут располагаться в любом порядке. Относящийся к поставщику (продавцу) раздел(ы) должен быть помещен в файле EDS последним.
А.4.1.2.2.8 Вход
Каждый раздел EDS должен включать один или несколько входов, начинающихся дескриптором входа, за которым следует знак равенства. Значение дескриптора входа должно относиться ко всему объему, допуская использование одних и тех же дескрипторов в разных разделах. Каждый вход должен заканчиваться точкой с запятой. Вход может распространяться на несколько строк, если запятые правильно разграничивают поля.
А.4.1.2.2.9 Дескрипторы входа
Дескриптор входа должен состоять из уникальной последовательности символов дескриптора, определенных в А.4.1.2.2.3. Существует два типа дескрипторов входа - общий и относящийся к поставщику (продавцу).
А.4.1.2.2.10 Общий дескриптор
Общий дескриптор должен быть всегда определен в спецификации CIP ассоциациями ответственных поставщиков (продавцов). Общий дескриптор никогда не должен начинаться с цифрового символа.
А.4.1.2.2.11 Дескрипторы, относящиеся к поставщику
Дескрипторы могут относиться к поставщику (продавцу). Эти дескрипторы должны начинаться с идентификатора компании-поставщика (Vendor ID) с последующим дополнением через нижнее тире (VendorID_VendorSpecificKeyword). Идентификатор поставщика должен быть представлен в виде десятичной записи числа, не включающей нули на первых позициях. Каждый поставщик несет ответственность за поддержание и документальное оформление относящихся к нему дескрипторов.
А.4.1.2.2.12 Поля входа
Каждый вход должен включать одно или несколько полей. Все поля должны быть разделены ограничителями в виде запятых. Значение поля(ей) должно зависеть от контекста раздела. Поля ввода могут быть обязательными или необязательными, согласно определениям в данной спецификации. Пробелы или отсутствие данных между запятыми должны использоваться для непредоставленных необязательных полей. Точка с запятой может использоваться для обозначения отсутствия последующих необязательных полей. Термин "Номер поля" должен показывать положение поля на входе. Поля нумеруются слева направо (или сверху вниз) начиная с номера один.
А.4.1.2.2.13 Дескрипторы поля
Дескриптор поля должен состоять из уникальной последовательности символов дескриптора, указанных в А.4.1.2.2.3. Существует два типа дескрипторов поля - общий и относящийся к поставщику (продавцу).
А.4.1.2.2.14 Поля сложных данных
Некоторые поля входа должны быть установлены для данных, которые не могут быть заданы одним значением между ограничивающими запятыми. Возможность дополнительного разграничения поля входа определяется путем использования одного или нескольких наборов фигурных скобок "{" и "}". Контенты между знаками скобок следует рассматривать как единый элемент или ввод. Содержание может быть сгруппировано с помощью нескольких скобок.
А.4.1.2.2.15 Комментарии
Комментарии должны иметь ограничители в виде знака доллара ($) и знака новой строки. Интерпретирующая программа EDS должна рассматривать все символы между ограничителями комментариев как пустое место. Ограничитель комментариев $, стоящий внутри поля или набора символов в двойных кавычках, не должен рассматриваться как ограничитель комментария.
Пример комментария приведен далее.
А.4.1.2.2.16 Пример структуры форматирования EDS
Примеры на рисунке А.1 поясняют структуру EDS.
Рисунок А.1 - Пример структуры форматирования EDS (информативный)
А.4.1.2.3 Требования к наименованию файла
Соглашения по наименованию файлов EDS на диске отсутствуют, кроме файлов в среде DOS/Windows: эти файлы должны иметь суффикс ".EDS", добавляемый к имени файла.
А.4.1.3 Требования к кодированию данных EDS
А.4.1.3.1 Общие положения
В данном разделе установлены требования по кодированию данных в файлах EDS.
Информация, содержащаяся в файле EDS, может представлять атрибуты экземпляров объекта в конфигурируемом устройстве. Все данные в файле EDS должны представлять собой текст ASCII, тогда как класс объекта и атрибуты экземпляра объекта не обязательно должны быть типа ASCII (имеющиеся типы данных определены в спецификации CIP). Следовательно, может быть необходима трансляция между данными, содержащимися в файле EDS, и атрибутами объекта. Такая трансляция установлена в следующих подразделах.
Типы элементарных данных, установленные в спецификации CIP, используются также в других элементах EDS, однако их значение преобразуется согласно описанию в следующих подразделах (см. А.4.1.3.3-А.4.1.3.10).
Некоторые типы данных используются только в файлах EDS (см. А.4.1.3.11-А.4.1.3.14).
А.4.1.3.2 ASCII: соглашение относительно символов в файлах
Все данные в EDS должны быть кодированы с использованием 8-битных символов ASCII, в которых все ссылки на "ASCII-символы" означают 8-битный формат знаков ASCII (согласно определениям в таблицах 1 и 2, строка 00 ИСО/МЭК 10646-1:2000). Символы, которые не могут быть показаны на терминале ANSI, не должны использоваться в идентификаторах имен или в представлении данных. Правильные значения символа ASCII должны включать разделитель строк, табуляцию и десятичные знаки от 32 до 126.
А.4.1.3.3 Соглашение о символьной строке - EDS_Char_Array
А.4.1.3.3.1 Общие положения
Все строковые данные файла EDS должны быть символьными строками фиксированной длины, без символов конца строки и должны быть заключены в двойные кавычки (тип данных EDS_Char_Array).
Существует две формы преобразования строковых данных. Символы, находящиеся между двойными кавычками, должны быть преобразованы в 8-битные символы ASCII. Символы, находящиеся между двойными кавычками, перед которыми стоит прописная буква L, должны быть преобразованы в символы UNICODE (16-битные).
Пример - "Данные результаты представляют собой строку, состоящую из 8-битных символов".
Примечание - Текст \u03C0 определяет единичный 16-битный символ, значение которого 03С0. В наборе символов UNICODE - это таблица 9, ряд 3, греческий символ для строчной "Pi". Описания последовательности переключения кода символов приведены в А.4.1.3.3.5.
А.4.1.3.3.2 Обработка недостаточного количества символов в поле строки
Интерпретирующая программа EDS должна использовать выравнивание знаков в поле по правому знаку или разряду знаков в поле и заполнять все неуказанные символы пробелами (ASCII 0x20) впереди по всей оставшейся длине строки.
Пример - Если параметр имеет максимальную длину строки 8 и получает строку "123АВ", эта строка интерпретируется как "~~~123АВ", где знаки "тильда" (~) соответствуют пробелам.
А.4.1.3.3.3 Обработка избыточного числа символов в поле строки
Если данное поле строки содержит слишком много знаков, интерпретирующая программа EDS должна обрезать знаки слева направо.
Пример - Если в параметрах обозначена максимальная длина строки - 8 знаков, а полученная строка, например, "I23ABCDEFG", она обрезается и интерпретируется как "I23ABCDE".
А.4.1.3.3.4 Конкатенация строки
Множественные строки при отсутствии прерывающих запятых должны быть объединены.
Пример 1 -
The line | : | "ABC" "123" "XYZ" |
is interpreted as | : | "ABC123XYZ" |
Строки могут быть также и на отдельных строчках.
Пример 2 -
The following lines : | |||
"ABC" | $this is a comment | ||
"123" | |||
"XYZ" | |||
are also interpreted as : | "ABC123XYZ" | ||
В случае строки UNICODE (длинная строка) только перед первой маркировкой двойными кавычками должен стоять символ прописной буквы L.
Пример 3 - L "ABC" "123" "XYZ" - то же самое, что L "ABC123XYZ".
А.4.1.3.3.5 Последовательности переключения кода строки
Интерпретирующая программа EDS должна узнавать все последовательности переключения кода, указанные в таблице А.6. Интерпретация зависит от приложения.
Таблица А.6 - Последовательности переключения кода строки
Последовательность переключения | Трансляция |
\\ | \ |
\n | Новая строка |
\t | Табуляция |
\v | Вертикальная табуляция |
\b | Возврат на один символ |
\r | Возврат каретки |
\f | Новая страница |
\a | Символ BELL (0x07) |
\" | "" |
\' | ' |
\xnn | Один байт, содержащий значение ""nn"" при шестнадцатиричном выражении |
\unnnn | Два байта, содержащих значение ""nnnn"" при шестнадцатиричном выражении. Эта форма последовательности переключения кода строки правильна в том случае, если результирующие данные строки 16-битные по длине, например форма L"" спецификации строки |