LON-технология. Построение распределенных приложений 5-88187-052-2

Citation preview

The following companies financed publication of this book: Echelon GmbH Festo GmbH Honeywell Johnson Controls Int. Karl E. Brinkmann GmbH Nodus GmbH TAC AB В финансировании тиража этой книги приняли участие следующие фирмы: Echelon GmbH Festo GmbH Honeywell Johnson Controls Int. Karl E. Brinkmann GmbH Nodus GmbH TAC AB

Dietmar Dietrich, Dietmar Loy, Hans-Jörg Schweinzer (Hrsg.)

LONTechnologie Verteilte Systeme in der Anwendung

Дитмар Дитрих, Дитмар Лой, Ганс-Юрген Швайнцер

LONтехнология Построение распределенных приложений Научный редактор перевода Низамутдинов О.Б.

III Dietmar Dietrich, Dietmar Loy, Hans-Jörg Schweinzer (Hrsg.) LON-Technologie Verteilte Systeme in der Anwendung Authors: o. Univ. Prof. Dr. techn. Dietmar Dietrich, TU Wien, Österreich Prof. Dipl.-Ing. Peter Fischer, Fachhochschule Dortmund, Deutschland Dipl.-Ing. Walter Heil, Fraunhoferinstitut, Karlsruhe, Deutschland Dipl.-Ing. Bruno Hilkens, Johnson Controls, Deutschland Prof. Dr.-Ing. habil. Klaus Kabitzsch, TU Dresden, Deutschland Univ. Ass. Dipl.-Ing. Dr. techn. Dietmar Loy, TU Wien, Österreich Dipl.-Ing. Peter Palensky, TU Wien, Österreich Dipl.-Ing. Ratko Posta, TU Wien, Österreich Dipl.-Ing. Heinrich Reiter, TU Wien, Österreich Dipl.-Ing. Dr. techn. Richard Schmalek, G. Kappl, Österreich Univ. Ass. Dipl.-Ing. Hans-Jörg Schweinzer, TU Wien, Österreich Dipl.-Ing. Joerg Stumpp, Fraunhoferinstitut, Karlsruhe, Deutschland Translators: Dipl.-Ing. Mikhail Gordeev, TU Perm, Russia Dipl.-Ing. Olga Koneva, TU Perm, Russia Dipl.-Ing. Maxim Lobachov, TU Perm, Russia Dipl.-Ing. Lev Maleev, TU Perm, Russia Scientific-technical lectures: Dipl.-Ing. Sergey Belkovsky, TU Perm, Russia Dipl.-Ing. Maxim Zubulin, TU Perm, Russia Scientific lectures Prof. Dr. techn. Oleg Nisamutdinov, TU Perm, Russia Scientific-literutural supervisor Prof. Dr. Tamara Serova, TU Perm, Russia Editors: o. Univ. Prof Dr. techn. Dietmar Dietrich, TU Wien, Österreich Univ. Ass. Dipl.-Ing. Dr. techn. Dietmar Loy, TU Wien, Österreich Prof. Dr. techn. Oleg Nisamutdinov, TU Perm, Russia Univ. Ass. Dipl.-Ing. Hans-Jorg Schweinzer, TU Wien, Österreich Sergey Belkovsky [email protected] Dietmar Dietrich [email protected] Peter Fischer [email protected] Mikhail Gordeev [email protected] Walter Heil [email protected] Bruno Hilkens [email protected] Klaus Kabitzsch [email protected] Olga Koneva [email protected] Maxim Lobachov [email protected] Dietmar Loy [email protected] Lev Maleev [email protected] Oleg Nisamutdinov [email protected] Peter Palensky [email protected] Ratko Posta [email protected] Heinrich Reiter [email protected] Richard Schmalek [email protected] Hans-Jurg Schweinzer [email protected] Tamara Serova [email protected] Joerg Stumpp [email protected] Maxim Zubulin [email protected]

Die Deutsche Bibliothek — CIP-Einheitsaufnahme LON-Technologie: verteilte Systeme in der Anwendung/Dietmar Dietrich ... (Hrsg.). — Heidelberg: Hüthig, 1997 ISBN 3-7785-2581-6

IV

УДК 681.324 Д 492 Дитрих Д., Лой Д., Швайнцер Г.-Ю. Д 492 ЛОН — технология. Построение распределенных приложений/Пер. с нем. под ред. О.Б. Низамутдинова. — Пермь: Звезда, 1999. — 424 с. ISBN 3-7785-2581-6 ISBN 5-88187-052-2 Авторы: Дитмар Дитрих, проф., д.т.н., Технический университет Вены, Австрия Петер Фишер, проф., Высшая техническая школа Дортмунда, Германия Вальтер Хайль, Институт Франховера, Карлсруэ, Германия Бруно Хилкенс, Джонсон Контроле, Германия Клаус Кабич, проф., Технический университет Дрездена, Германия Дитмар Лой, к.т.н., Технический университет Вены, Австрия Петер Паленски, Технический университет Вены, Австрия Ратко Поста, Технический университет Вены, Австрия Генрих Рейтер, Технический университет Вены, Австрия Ричард Шмалек, к.т.н., Г. Каппл, Австрия Ганс-Юрген Швайнцер, Технический университет Вены, Австрия Йорг Штамп, Институт Франховера, Карлсруэ, Германия Переводчики: Гордеев М.В., ПГТУ, Пермь, Россия Конева О.В., ПГТУ, Пермь, Россия Лобашов М.В., ПГТУ, Пермь, Россия Малеев Л.К., ПГТУ, Пермь, Россия Технические корректоры: Белковский СВ., ПГТУ, Пермь, Россия Зубулин М.В., ПГТУ, Пермь, Россия Научный редактор Низамутдинов О.Б., проф., д.т.н., ПГТУ, Пермь, Россия Литературная коррекция Серова Т.С., проф., д.ф.н, ПГТУ, Пермь, Россия Редакция: Дитмар Дитрих, проф., д.т.н., Технический университет Вены, Австрия Дитмар Лой, к.т.н., Технический университет Вены, Австрия Низамутдинов О.Б., проф., д.т.н., ПГТУ, Пермь, Россия Ганс-Юрген Швайнцер, Технический университет Вены, Австрия Белковский СВ. Гордеев М.В. Дитрих Д. Зубулин М.В. Кабич К. Конева О.В. Лобашов М.В. Лой Д. Малеев Л.К. Низамутдинов О.Б.

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

ISBN 3-7785-2581-6 ISBN 5-88187-052-2

Паленски П. Поста Р. Рейтер Г. Серова Т.С. Фишер П. Хайль В. Хилькенс Б. Швайнцер Г.-Ю. Шмалек Р. Штамп И.

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

© ICT TU Wien, перевод, 1999 © ПГТУ, перевод, 1999

V

Предисловие Система LonWorks вызывает огромный интерес во всем мире, который объясняется как техническими, так и экономическими аспектами. Речь идет о системе Fieldbus, созданной сравнительно поздно и поэтому вначале с трудом конкурировавшей с уже известными разработками. Тем не менее концепция LonWorks быстро достигла высокого уровня развития. Уже первые маркетинговые исследования определили наиболее перспективные области ее использования — бытовые системы и автоматизация систем зданий. Кроме того, гибкость технологии позволяет находить ей и другое применение. Таким образом, в LonWorks отразился опыт развития компьютерных технологий, она не была ориентирована на распространенные в то время маломощные восьмиразрядные микропроцессоры, так как уже было очевидно, что при стремительном росте производительности микросхем стоимость их, напротив, с каждым годом падает. В основе LonWorks лежит прогрессивная концепция, сущность которой состоит в сокращении числа иерархических уровней децентрализованной системы: отпадает необходимость в главных устройствах (Master), выполняющих функции централизованного управления. Опосредованный обмен информацией при помощи сетевых переменных облегчает задачу программирования. Аналогично транспьютерным технологиям поддержание коммуникации осуществляется на аппаратном уровне, пользователю предоставляется микросхема (Neuron Chip), в которой функции обмена информацией являются составной частью системного языка. В то же время совсем не обязательно ориентироваться на однопроцессорные решения, возможны коммуникации с несколькими десятками тысяч участников информационного обмена. То, что это стоит потери некоторой избыточности системы и ее быстродействия, не вызывает сомнений, но в будущем эти недостатки могут быть устранены путем использования наиболее передовых технологий и создания соответствующих структур. Неудивительно, что системы Lon Work, требующие нового подхода и дающие фантастические возможности, вызывают большой интерес, используются сотнями фирм почти всех отраслей. Предлагаемая книга рассчитана на техников, инженеров и студентов — всех тех, кто занимается сетевыми технологиями. Большое внимание уделено обзору специальной Литературы, так как тематика книги охватывает ряд областей компьютерных технологий. Книга написана несколькими авторами, что в отдельных главах грозило «отклонением» от рассматриваемой проблемы. Во избежание этого мы вместе работали над каждой главой, хотя это стоило долгих и утомительных трудов, многократной правки текста в целях достижения единства стиля. Мы выражаем глубокую благодарность «продержавшимся до конца» соавторам. Возможно, читатель заметит аналогию: группа авторов действовала подобно LON. Каждый из них, специалист в своей области, был ориентирован на децентрализованную работу, а логическая связь, при условии однозначного определения интерфейсов, обеспечила высокую производительность. В системе LonWorks, однако, достичь этого проще, чем

VI коллективу авторов. Еще одно замечание — относительно социальных последствий развития систем Fieldbus. Эта технология делает возможной экономическую реализацию многих идей автоматизации, которые всего лишь несколько лет назад казались неосуществимыми. Fieldbus может, например, обеспечить экономию энергии, создать в сфере обслуживания системы поддержки услуг, сетевые системы пожарной сигнализации, полностью автоматизировать любой процесс и т. д. Нельзя оставить без внимания и то, что использование сетевых технологий на уровне датчиков и исполнительных механизмов повлечет изменения в сфере занятости, как случилось при внедрении персональных компьютеров. Fieldbus станет причиной появления новых и исчезновения некоторых старых профессий. Следовательно, мы обязаны учитывать последствия внедрения новых технологий (в том числе и LonWorks). Авторы выражают благодарность издательству за определенный риск, связанный с выпуском этой книги, которая, с одной стороны, должна была быть написана одним автором, а с другой — объединить знания двенадцати специалистов. Удачно осуществить такую работу коллективом авторов очень сложно. Мы будем рады получить отзывы читателей на отдельный адрес E-mail: [email protected]. Мы признательны научным сотрудникам Пермского государственного технического университета (Россия) за перевод книги на русский язык. Вена, июль 1997 г. Дитмар Дитрих, Дитмар Лой, Ганс-Юрген Швайнцер, [email protected].

VII

Содержание Список сокращений...............................................................................................................XVI 1. Введение.......................................................................................................................1 1.1. Причины и последствия объединения компьютеров в сеть..................................1 1.2. Управление техническими процессами..................................................................2 1.2.1. Классический подход.............................................................................................2 1.2.2. Децентрализованный подход.................................................................................3 1.3. Информационный обмен как основа распределенных систем..............................5 1.3.1. Иерархия системы...................................................................................................5 1.3.2. Семиуровневая модель ISO/OSI............................................................................6 1.3.3. Топологии..............................................................................................................10 1.3.4. Временная характеристика передачи данных, проблематика систем реального времени............................................................................................................................14 1.3.5. Стратегия передачи данных на прикладном уровне.........................................15 1.3.6. Инструментарий....................................................................................................16 1.4. Основные концепции применения распределенных систем.........................................19 1.4.1. Типы сетевых узлов..............................................................................................19 1.4.2. Декомпозиция приложения с точки зрения параллельной обработки и иерархической структуры.................................................................................20 1.4.3. Управление и контроль........................................................................................21 1.4.4. Сегментация и поток данных...............................................................................23 1.5. Обзор FIELDBUS-систем.....................................................................................25 1.5.1. Обзор LonWorks....................................................................................................25 1.5.2. PROFIBUS..............................................................................................................27 1.5.3. P-NET.....................................................................................................................31 1.5.4. INTERBUS-S.........................................................................................................33 1.5.5. CAN........................................................................................................................37 1.5.6. EIB..........................................................................................................................40 1.5.7. Области и профили в PROFIBUS-системах.......................................................43 1.6 Перспективы децентрализации систем..................................................................43 2. Распределенные системы..........................................................................................47 2.1 Распределенная система на уровне датчики — исполнительные механизмы......................................................................................................................48 2.1.1 Компоненты распределенной системы на уровне датчики исполнительные механизмы........................................................................................49 2.1.2. Особенности распределенной системы управления..........................................51 2.2. Распределенная система на базе технологии LonWorks...................................52 2.3. Пример разработки системы в LonWorks...........................................................56

VIII 2.4. Эффективность передачи данных.......................................................................59 2.5. Перспективы распределенных приложений.......................................................61 3. Узлы LonWorks.........................................................................................................63 3.1. Общий обзор..........................................................................................................63 3.2. Память....................................................................................................................64 3.3. Порты и ввод/вывод..............................................................................................67 3.4. Тактовый генератор и таймер..............................................................................69 3.5. Сброс, функции защиты и «спящий» режим......................................................70 3.6. Идентификационный номер и сервисный вывод...............................................72 3.7. Программно-технические особенности Neuron Chip........................................73 3.8. Соединение с хост-процессором.........................................................................75 3.9. Компоненты для построения узлов LonWorks...................................................76 4. Протокол LonTalk....................................................................................................79 4.1. Общие сведения....................................................................................................79 4.2. Обзор протокола и терминология.......................................................................80 4.2.1. Обзор протокола...................................................................................................81 4.2.2. Терминология........................................................................................................83 4.3. Адресация в системе LonTalk.................................................................................87 4.3.1. Домен.....................................................................................................................87 4.3.2. Подсети и узлы......................................................................................................88 4.3.3. Группа, член группы.............................................................................................88 4.3.4. Neuron ID...............................................................................................................88 4.3.5. Адресация на уровне 3..........................................................................................88 4.4. Физический уровень протокола LonTalk...............................................................91 4.5. Уровень связи...........................................................................................................91 4.5.1. Интерфейс с пограничными уровнями...............................................................91 4.5.2. Способ доступа к шине........................................................................................93 4.5.3. Приоритеты............................................................................................................94 4.5.4. Формат кадра NPDU/LPDU.................................................................................95 4.5.5. Дифференциальное манчестерское кодирование..............................................95 4.6. Сетевой уровень.......................................................................................................96 4.6.1. Интерфейс с транспортным уровнем..................................................................98 4.6.2. Формат NPDU........................................................................................................98 4.6.3. Маршрутизатор.....................................................................................................99 4.7. Транспортный уровень............................................................................................99 4.7.1. Службы подуровня управления транзакциями..................................................99 4.7.2. Службы транспортного уровня..........................................................................100 4.7.3. Форматы и типы TPDU......................................................................................100 4.7.4. Повторение на уровне 4......................................................................................102 4.7.5. Таймер уровня 4..................................................................................................103 4.7.6. Сервер идентификации.......................................................................................103 4.7.6.1. Службы сервера идентификации.......................................................................104 4.7.6.2. Форматы и типы сервера идентификации........................................................104 4.7.6.3. Алгоритм кодирования.......................................................................................105

IX 4.8. Сеансовый уровень...............................................................................................105 4.8.1. Интерфейс уровня представления данных.......................................................106 4.8.2. Форматы и типы SPDU.......................................................................................106 4.8.3. Идентификация...................................................................................................107 4.8.4. Таймер протокола уровня 5...............................................................................107 4.9. Уровень представления данных и прикладной уровень...................................108 4.9.1. Функции уровня представления данных и прикладного уровня...................109 4.9.2. Типы и форматы APDU......................................................................................110 4.9.3. Коды сообщений.................................................................................................111 4.9.4. Интерфейс прикладного уровня........................................................................112 4.9.4.1. Структура данных объектов сообщения и ответа............................................113 4.9.4.2. Транзакция APDU...............................................................................................117 4.10. Сетевой менеджмент и сетевая диагностика....................................................118 4.10.1. Статус узла...........................................................................................................119 4.10.2. Структуры данных конфигурации.....................................................................120 4.10.3. Разделение служб NM/ND....................................................................................121 4.10.4. Функционирование узла LonWorks.....................................................................122 4.10.5. NMM как идентификатор узла.............................................................................124 4.10.5.1. Идентификатор запроса (Query ID)...................................................................124 4.10.5.2. Ответ на запрос...................................................................................................125 4.10.5.3. Сообщение сервисной кнопки (Service Pin Message)......................................125 4.10.6. Обработка таблиц домена.....................................................................................126 4.10.6.1. Обновление домена (Update Domain)................................................................126 4.10.6.2. Запрос домена (Query Domain)..........................................................................126 4.10.6.3. Покидание домена (Leave Domain)...................................................................127 4.10.6.4. Обновление ключа (Update Key).......................................................................127 4.10.7. Обработка таблиц адреса.....................................................................................128 4.10.7.1. Обновление адреса (Update Address)................................................................128 4.10.7.2. Адрес запроса (Query Address)..........................................................................130 4.10.8. Обработка таблиц сетевых переменных.............................................................130 4.10.8.1. Обновление конфигурации сетевых переменных (Update Net Variable Config).............................................................................................130 4.10.8.2. Query Net Variable Config...................................................................................131 4.10.8.3. Запрос SNVT (Query SNVT)..............................................................................132 4.10.8.4. Network Variable Fetch........................................................................................133 4.10.9. Обработка памяти узлов сети...............................................................................133 4.10.9.1. Чтение памяти (Read Memory)...........................................................................133 4.10.9.2. Запись в память (Write Memory)........................................................................135 4.10.9.3. Перерасчет контрольной суммы........................................................................136 4.10.9.4. Обновление памяти.............................................................................................136 4.10.10. Сообщения сетевого менеджмента (NNM) для выполнения особых задач...........................................................................................137 4.10.10.1. Установить режим узла (Set Node Mode).........................................................137 4.10.10.2. Установление (Install)........................................................................................138

X 4.10.10.3. Network Management Escape Code.....................................................................139 4.10.11. Сообщения сетевого менеджмента для маршрутизатора..................................140 4.10.11.1. Режим маршрутизатора......................................................................................141 4.10.11.2. Router Clear Group or Subnet Table....................................................................141 4.10.11.3. Router Group or Subnet Table Download............................................................142 4.10.11.4. Router Group Forward..........................................................................................142 4.10.11.5. Router Subnet Forward.........................................................................................142 4.10.11.6. Router Do Not Forward Group.............................................................................143 4.10.11.7. Router Do Not Forward Subnet............................................................................143 4.10.11.8. Router Group or Subnet Table Report..................................................................144 4.10.11.9. Состояние маршрутизатора (Router Status)......................................................144 4.10.11.10. Router Half Escape Code....................................................................................145 4.10.12. Сообщения сетевой диагностики (NDM)............................................................145 4.10.12.1. Запрос статуса (Query Status).............................................................................145 4.10.12.2. Статус прокси (Proxy Status)..............................................................................145 4.10.12.3. Очистка статуса (Clear Status)............................................................................147 4.10.12.4. Query Transceiver Status......................................................................................147 4.11. Формат кадра LonTalk................................................................................................147 5. Микропрограммное обеспечение Neuron Chip............................................................149 5.1. Модель процессора...............................................................................................149 5.1.1. Архитектура трех процессоров.........................................................................149 5.1.2. Обзор регистров CPU.........................................................................................151 5.1.3. Модель базисной страницы...............................................................................152 5.1.4. Набор команд Neuron Chip.................................................................................153 5.1.5. Интерфейс анализатора логики эмулятора Neuron Chip.................................157 5.2. Инсталляция микропрограммного обеспечения................................................160 5.2.1. Разделение задач трех CPU................................................................................160 5.2.2. Тестирование и инициализация RAM...............................................................162 5.2.3. Старт MAC CPU..................................................................................................162 5.2.4. Старт сетевого CPU............................................................................................164 5.2.5. Старт прикладного CPU.....................................................................................165 5.3. Микропрограммное обеспечение. Режим нормальной работы........................169 5.3.1. Основной цикл MAC CPU..................................................................................169 5.3.2. Основной цикл сетевого CPU............................................................................170 5.3.3. Основной цикл прикладного CPU.....................................................................172 5.3.4. Таймер..................................................................................................................180 5.4. Коммуникация.......................................................................................................182 5.4.1. Коммуникационный буфер................................................................................182 5.4.2. Величина буфера и количество буферов..........................................................183 5.4.3. Коммуникационный таймер...............................................................................186 6. Модель программирования......................................................................................189 6.1. Neuron C..................................................................................................................189 6.1.1. Отличия от ANSI-C.............................................................................................189 6.1.2. Описание языка...................................................................................................190

XI 6.1.3. Библиотека...........................................................................................................194 6.2. Планировщик..........................................................................................................195 6.2.1. Задача Neuron С...................................................................................................195 6.2.2. Принцип функционирования планировщика...................................................196 6.2.3. Управление функциями......................................................................................198 6.2.4. Время, используемое планировщиком..............................................................199 6.2.5. Обработка ошибок..............................................................................................200 6.3. Объекты коммуникации........................................................................................202 6.3.1. Сетевые переменные...........................................................................................203 6.3.2. Явные сообщения................................................................................................206 6.4. Режимы работы узлов............................................................................................208 6.4.1. Способность узла к работе в реальном времени..............................................208 6.4.2. Работа распределенного приложения в реальном времени............................208 6.4.3. Поведение узла в распределенной системе......................................................210 7. Сетевые структуры и переходы между сетями......................................................215 7.1. Характеристики структур шин и открытых сред...............................................215 7.2. Повторители, мосты, маршрутизаторы и шлюзы...............................................219 7.2.1. Повторитель.........................................................................................................219 7.2.2. Мост......................................................................................................................220 7.2.3. Маршрутизатор...................................................................................................221 7.2.4. Шлюз....................................................................................................................223 7.3. Маршрутизация в сети LonWorks........................................................................224 7.3.1. Адресация в LonTalk...........................................................................................224 7.3.2. Адресация уровней 2 и 3....................................................................................224 7.4. Маршрутизатор LonWorks....................................................................................225 7.4.1. Характеристики...................................................................................................225 7.4.2. Таблицы передачи...............................................................................................226 7.4.3. Обучающийся маршрутизатор LonWorks.........................................................226 7-4.4. Конфигурируемый маршрутизатор LonWorks.................................................227 7.4.5. Простая топология зацикливания (петля).........................................................227 7.4.6. Конфигурируемый маршрутизатор LonWorks в открытой среде..................228 7.4.7. Защита данных точка-точка...............................................................................229 7.5. Предпочтительные среды передачи при использовании маршрутизатора LonWorks..........................................................................................230 7.5.1. Физические каналы передачи............................................................................230 7.5.2. Физические каналы и линии электропередач..................................................231 7.5.3. Буферизация сообщений маршрутизатором LonWorks..................................231 7.5.3.1. Функции пригодности....................................................................................232 7.5.3.2. Правильный выбор размера буфера..............................................................233 7.6. Связь между сетями..............................................................................................235 7.6.1. Общая постановка вопроса................................................................................235 7.6.2. Связь между LonTalk и PROFIBUS-FMS.........................................................236 7.6.2.1. PROFIBUS-FMS...............................................................................................237 7.6.2.2. Шина ProfiLon..................................................................................................238

XII 7.6.2.3. Структура ProfiLon.............................................................................................238 7.6.2.4. Передача данных из PROFIBUS в LON............................................................240 7.6.2.5. Передача данных из LON в PROFIBUS-FMS..................................................240 7.6.2.6. Поведение системы при ошибках передачи.....................................................241 7.6.2.7. Адресация пакетов данных................................................................................243 7.6.2.8. Фаза инициализации...........................................................................................244 7.6.2.9. Резюме..................................................................................................................245 7.6.3. Связь между LonTalk и HTTP..............................................................................245 7.6.3.1. HTTP.....................................................................................................................245 7.6.3.2. Задачи LonHttp....................................................................................................246 7.6.3.3. Структура LonHttp..............................................................................................246 7.6.3.4. Передача данных от HTTP к LON.....................................................................247 7.6.3.5. Передача данных от LON к HTTP.....................................................................248 7.6.3.6. Адресация............................................................................................................249 7.6.3.7. Вопросы безопасности.......................................................................................250 8. Сетевой менеджмент...................................................................................................251 8.1. Аспекты сетевого менеджмента..............................................................................251 8.1.1. Аспекты сценариев менеджмента....................................................................252 8.2. Архитектура сетевого менеджмента LON..........................................................253 8.3. Сетевые службы LonWorks..................................................................................263 8.3.1. Архитектура клиент/сервер в LON...................................................................264 8.3.2. Сервер сетевых служб и интерфейс сетевых служб........................................265 8.3.3. API хоста сетевых служб LonWorks..................................................................266 8.3.4. Инструментарий..................................................................................................267 8.4. Архитектура компонентов LonWorks...................................................................268 8.4.1. OLE — ActiveX....................................................................................................268 8.4.2. Объектно-ориентированный подход в LON.....................................................270 8.4.3. Среда разработки LCA-приложений.................................................................277 8.4.4. LCA И совместимость.........................................................................................278 8.4.5. LNS— и LCA-документация от Echelon...........................................................278 9. Объекты ввода/вывода, поддерживаемые микропрограммным обеспечением................................................................................................................279 9.1. Объекты прямого ввода/вывода..........................................................................280 9.1.1. Побитовый ввод/вывод (Bit Input/Output)........................................................280 9.1.2. Побайтовый ввод/вывод (Byte Input/Output)....................................................280 9.1.3. Ввод по уровню (Leveldetect Input)...................................................................281 9.1.4. Полубайтовый ввод/вывод (Nibble Input/Output).............................................281 9.2. Объекты последовательного побайтового ввода/вывода..................................281 9.2.1. Параллельный ввод/вывод.................................................................................281 9.2.2. Ввод/вывод с помощью интерфейса Muxbus (Muxbus Input/Output).............282 9.3. Объекты последовательного побитового ввода/вывода....................................282 9.3.1. Bitshift Input/Output (побитовый ввод/вывод)..................................................282 9.3.2. Ввод/вывод с помощью шины I2C (I2C Input/Output)......................................282 9.3.3. Ввод с магнитной карты стандарта ISO 7811 (Magcard Input).......................283

XIII 9.3.4. Устройство чтения с магнитных карт стандарта ISO/OSI 3554 (Magtrack Input).............................................................................................................284 9.3.5. Ввод/вывод с помощью протокола Neurowire (Neurowire Input/Output)..................................................................................................................285 9.3.6. Последовательный ввод/вывод (Serial Input/Output).......................................285 9.3.7. Ввод/вывод в энергонезависимую память (Touch Input/Output)....................285 9.3.8. Ввод, реализованный на эффекте Виганда (Wiegand Input)...........................286 9.4. Объекты таймера/счетчика...................................................................................286 9.4.1. Двухфронтовый ввод (Dualslope Input).............................................................286 9.4.2. Ввод с записью последовательностей импульсов (Edgelog Input).................287 9.4.3. Инфракрасный ввод (Infrared Input)..................................................................287 9.4.4. Ввод по времени между фронтами (On Time Input)........................................288 9.4.5. Ввод по времени между фронтами сигналов одного типа (Period Input)..................................................................................................................288 9.4.6. Линия счетчика импульсов (Pulsecount Input)..................................................289 9.4.7. Квадратурный ввод (Quadrature Input)..............................................................289 9.4.8. Линия общего счета (Total Count Input)............................................................289 9.4.9. Частотоделительный вывод (Edgedivide Output).............................................289 9.4.10. Частотный вывод (Frequency Output)..............................................................290 9.4.11. Односигнальный вывод малой длительности (Oneshot Output)...................290 9.4.12. Импульсно-счетный вывод (Pulsecount Output).............................................290 9.4.13. ШИМ-вывод (Pulsewidth Output).....................................................................290 9.4.14. Вывод, реализованный на объекте Triac (Triac Output).................................291 9.4.15. Вывод с проверкой счетного количества импульсов на вводе (Triggered Count Output)................................................................................................291 10. Совместимость........................................................................................................293 10.1. От совместимости до Plug'N'Play.......................................................................293 10.2. Терминология......................................................................................................296 10.З. Требования и подтверждение interoperability...................................................296 10.4. Соответствие стандартам и interoperability в LonWorks.................................299 10.4.1. Interoperability физического уровня................................................................299 10.4.2. Interoperability уровней 2 — 6.........................................................................300 10.4.З. Interoperability прикладного уровня................................................................300 10.4.3.1. Функциональные объекты.............................................................................303 10.4.3.2. Конфигурационные параметры....................................................................310 10.4.3.3. Документация на устройство.........................................................................311 11. Профили..................................................................................................................313 11.1. Профили и стандарты.........................................................................................313 11.2. Классы профилей................................................................................................314 11.3. Функциональные профили LonMark.................................................................314 11.4. Профили в протоколе LonTalk...........................................................................314 11.5. Пример функционального профиля..................................................................316 12. Пример декомпозиции распределенного приложения....................................321 12.1. Ход процесса.......................................................................................................323

XIV 12.1.1. Шаги процесса......................................................................................................323 12.1.2. Состояния процесса.............................................................................................324 12.1.3. Параллельные задачи управления......................................................................325 12.1.4. Функциональная иерархия..................................................................................325 12.2. Управляющие элементы процесса........................................................................326 12.2.1. Распределение узлов и типы узлов.....................................................................326 12.2.2. Функциональность типов узлов..........................................................................327 12.2.2.1. Узлы датчиков....................................................................................................327 12.2.2.2. Узлы бинарных исполнительных механизмов................................................328 12.2.2.3. Узлы частотных преобразователей...................................................................328 12.2.2.4. Управляющие узлы.............................................................................................328 12.2.2.5. Узлы мониторинга..............................................................................................329 12.2.2.6. SCADA-узел........................................................................................................329 12.2.2.7. События...............................................................................................................330 12.3. Преобразование задач управления в программы Neuron С..................................331 12.3.1. Сетевые переменные.............................................................................................331 12.3.1.1. Команды и параметры........................................................................................331 12.3.1.2. Состояния датчиков и исполнительных механизмов......................................334 12.3.1.3. Состояния установки..........................................................................................335 12.3.1.4. Данные измерения..............................................................................................335 12.3.2. Структура программы...........................................................................................336 12.4. Мониторинг установки............................................................................................338 12.4.1. Узел мониторинга.................................................................................................338 12.4.2. Права доступа к исполнительным механизмам.................................................338 12.5. Топология сети.........................................................................................................339 12.6. Ограничения приложения.......................................................................................341 12.6.1. Ограничения, вызываемые адресной таблицей.................................................341 12.6.2. Ограничения приложения, вызванные временем реакции...............................342 13. Инструментарий.........................................................................................................343 13.1. Обзор........................................................................................................................343 13.2. Инструментарий проектирования........................................................................347 13.2.1. Разработка программы для отдельного узла....................................................347 13.2.2. Определение компонент проектирования........................................................347 13.2.3. Планирование монтажа......................................................................................349 13.2.4. Установка узлов..................................................................................................349 13.2.5. Определение функций узла................................................................................350 13.2.6. Связывание..........................................................................................................352 13.2.7. Использование модулей.....................................................................................353 13.2.8. Конфигурация и проверка..................................................................................354 13.2.9. Варианты инсталляции.......................................................................................355 13.2.10. Свойства инструментов......................................................................................356 13.3. Инструменты тестирования и диагностики......................................................358 13.3.1. Отладчик для управляемой обработки.............................................................358 13.3.2. Отслеживание (Tracing)......................................................................................365

XV 13.3.3. Анализаторы протокола и сетевые мониторы..................................................366 13.3.4. Интегрированные системы диагностики..........................................................369 13.4. Вспомогательные средства для разработки инструментария…........................373 13.4.1. Адаптация на хостовом компьютере.................................................................373 13.4.2. Библиотеки сетевого менеджмента...................................................................373 13.4.3. Интегрированная архитектура программного обеспечения...........................374 14. Аспекты производительности.................................................................................375 14.1. Методология анализа производительности систем коммуникации…..............375 14.1.1. Измерение производительности систем коммуникации.................................377 14.1.2. Имитация.............................................................................................................377 14.1.3. Математический анализ.....................................................................................377 14.1.4. Сравнение скорости (benchmarks) систем........................................................378 14.1.5. Величины и параметры, характеризующие производительность..................379 14.2. Анализ.....................................................................................................................380 14.2.1. Установка для измерения параметров производительности системы...........381 14.2.2. Величины, характеризующие производительность и сравнение скорости (benchmarks) системы.........................................................................382 14.2.3. Анализ времени реакции....................................................................................384 Список литературы.................................................................................................................386

Список сокращений 0хуууу ACKD ADPCM ALI ALTO ANSI APDU API APINIT ASIC ATM b'xxxxxxx BP CA CAN CD CEN CIM COM CPU CRC CSMA CV DIP DP DPDU DQDB DSP EIB

Шестнадцатеричное представление адреса уууу PDU с подтверждением Adaptive Differential Pulse Code Modulation Application Layer Interface Advanced Lon Tool American National Standards Institute Application Protocol Data Unit Application Programming Interface Application Initialization Application Specific Integrated Circuit Asynchronous Transfer Mode Двоичное представление адреса ххххххх Base Page Collision Avoidance Controller Area Network Collision Detection Европейский комитет по стандартам Computer Integrated Manufacturing Component Object Model [OLE95] Central Processing Unit Cyclic Redundancy Check Carrier Sense Multiple Access Code Violation Dual in Package Decentralised Peripherals Diagnostic Protocol Data Unit Distributed Queue Dual Bus [IEEE8026] Data Stack Pointer European Installation Bus

FAN FCU FDDI FMS FWF FWT GLT GSM

Field Area Network Fan Coil Unit Fiber Distributed Data Interface Field Message Specification Forwarding Flag Forwarding Table Техника автоматизации систем зданий Global System for Global Communication

XVII h'xxxx HiFi HLK HTTP HVAC ID IEC IEEE IP ISDN ISO LAN LCA LNS LON LPDU MAC MAP MDA MIP MMS MPDU MSA NDM NMM NMPDU NPDU NSI NSS NV OCX ODBC OLE OSI PA PAL PC PDU PMS PPDU PROFIBUS RAM

Шестнадцатеричное представление адреса хххх High Fidelity Отопление, вентиляция, кондиционирование Hypertext Transmission Protocol Heating, Ventilation and Air Conditioning Identification Code International Electrotechnical Commission Institute of Electrical and Electronic Engineers Instruction Pointer Integrated Services Digital Network International Organisation for Standardisation Local Area Network LonWorks Component Architecture Lon Works Network Services Local Operating Network Link Protocol Data Unit Media Access Control Manufacturing Automation Protocols Media Destination Address Microprocessor Interface Program Manufacturing Message Service MAC Protocol Data Unit Media Source Address Network Diagnostic Message Network Management Message Network Management Protocol Data Unit Network Protocol Data Unit Network Services Interface Network Services Server Network Variable OLE Custom Control Open Database Connectivity Object Linking and Embedding Open Systems Interconnection Process Automation Phase Alternate Lines Personal Computer Protocol Data Unit Peripheral Message Specification Presentation PDU Process Field Bus Random Access Memory

XVIII RF RNMM RPC RSP RTU SAP SAR SCPT SNVT SPDU SPS SU TOS TPDU UnACKD-RPT VAV WAN

Radio Frequency Router Network Management Service Remote Procedure Call Return Stack Pointer Roof Top Unit Service Access Point Signature Analysis Register Standard Configuration Parameter Type Standard Network Variable Type Session Protocol Data Unit Speicherprogrammierable Steuerung Service User Top of Stack Transport Protocol Data Unit Unacknowledged Repeated PDU Variable Air Volume Wide Area Network

1. Введение 1.1. Причины и последствия объединения компьютеров в сеть Для того, чтобы максимально эффективно использовать вычислительные ресурсы компьютеров, их необходимо объединить в сеть. Задолго до того, как появился микропроцессор, большие вычислительные системы объединяли с помощью телеграфных линий связи. Однако бурное развитие компьютерных сетей началось только с появлением LAN (Local Area Network), когда использование компьютера небольшими фирмами стало экономически обоснованным. С появлением возможности объединять LAN в WAN (Wide Area Network) специалисты начали думать об осуществлении идеи полной автоматизации производства — CIM (Computer Integrated Manufacturing). Однако, несмотря на падение цен на микропроцессоры и оперативную память, идея полностью автоматизированного предприятия в то время так и не осуществилась. LON (Local Operating Network) предназначена именно для автоматизации производства. До XVIII века создавали только механические станки и применяли осязаемые виды энергии. Одной из важнейших предпосылок промышленной революции явились открытия в области физики, например преобразование энергии из одного вида в другой, которое позволило привести в действие ткацкий станок с помощью пара и заставило двигаться автомобиль. Таким образом, появилась возможность ограничить использование людей в качестве рабочей силы и все больше заменять их труд машинами. Следствием этого стало развитие крупных предприятий. Наше время — время информационных технологий. Мы все больше и больше учимся обрабатывать информацию с помощью машин, хранить, передавать и распределять её. Телефонная сеть, персональный компьютер, радио, интернет — примеры того, как изменился мир благодаря информационным технологиям. Компьютер и компьютерные сети все чаще применяются для автоматизации

2 производственных процессов. Fieldbus-системы, которые представляет и LON, могут стать существенной составной частью будущих сетей, базисом для разработок, которые в ближайшем будущем приобретут большую значимость. Идея CIM стала особенно привлекательной сейчас, когда стало известно, каким образом можно объединить датчики и исполнительные механизмы «в поле» (от англ. «in the field», имеется в виду термин Fieldbus — полевая шина)1, не прибегая к большим затратам. Еще несколько лет назад автомобили имели от 20 до 50 датчиков и исполнительных механизмов; через несколько лет, по нашим оценкам, их число должно значительно возрасти — до 500 и более. То же самое будет происходить в области автоматизации систем зданий, домашнего хозяйства, промышленности и т. д. Итак, объединение компьютерных систем управления в сеть может быть экономически эффективно на основе Fieldbus-технологии. До сих пор взгляд человека на организацию окружающего его мира носит ярко выраженный центристский характер. Для многих фирм, партий и т.д. характерна жесткая иерархическая структура. Этот подход привносится и в область управления техникой. О том, что иерархическая структура не оптимальна, известно давно. Это должно натолкнуть нас на мысль, что нужно стремиться к децентрализации технологических процессов. LON создается без использования традиционных PLC (Programmable Logic Controller) — контроллеров с программируемой логикой. Основная идея LON заключается в наиболее децентрализованном распределении интеллекта на основе новых концепций.

1.2. Управление техническими процессами 1.2.1. Классический подход Для управляющих систем традиционная централизованная структура (Рис. 1-16). Исходя из централизованности системы, управляющее вычислительное устройство запрашивает данные датчиков или приборов и после обработки возвращает их обратно. Датчики, как и исполнительные механизмы, не обладают интеллектом. Более современная структура включает в себя концентраторы (Рис. 1-16), которые заменили длинные параллельные линии передачи данных. Преимущества такого подхода известны: улучшенная электрическая совместимость, более простое формирование соединений, низкая стоимость линий передачи данных, экономия на клеммах и т. д. Однако возникают трудности, связанные с переходом от одних принципов передачи данных к другим, так как во многих случаях отсутствует совместимость ряда параметров. Результатом этого становится усложнение управляющей станции. С появлением интегральных микроэлементов широкое распространение получили 1

Примечание переводчика.

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

(а)

САП

(б)

САП

Рис. 1-1. Централизованное управление технологическим процессом: а) принцип линий межсистемной связи; б) интеграция концентраторов данных, где ИФ — интерфейс, МД— делитель, САП— датчики, исполнительные механизмы и приборы, СД — субдемулътиплексоры Тем временем обозначилась новая тенденция — замена контроллеров с программируемой памятью промышленными персональными компьютерами, которые обладают рядом преимуществ. Во-первых, они позволяют применять более доступное по цене аппаратное обеспечение; во-вторых, можно разработать простое в применении и недорогое программное обеспечение, которое поставляют различные фирмы, постоянно совершенствуя его. Значительно реже возникает необходимость самостоятельной разработки и обслуживания. Единственной проблемой может быть выбор подходящих программ реального времени, предлагаемых рынком в достаточном количестве.

1.2.2. Децентрализованный подход С некоторого времени получили широкое распространение шинные системы, в частности Fieldbus-системы2 (Рис. 1-2), которые по сравнению с концентраторами данных экономически более выгодны. Fieldbus-системы представляют собой новую технологию, которая предлагает новый образ мышления при системном проектировании. Узлы Fieldbus-системы могут децентрализованно использовать интеллект для управления, регулирования и контроля. В предельном случае это может быть система с полным отсутствием центрального управления (функции контроллеров с программируемой памятью, очевидно, распределяются между различными узлами сети, такими как датчики, исполнительные механизмы и устройства индикации). То, что данный подход позволяет мыслить совершенно иначе, понятно на таком примере. 2

Более подробно о различных шинных системах далее.

4

Рис. 1-2. Децентрализация системы шин: а) связь посредством концентраторов данных; б) связь посредством системы шин, где КД— концентратор данных, ИФ — интерфейс, ША — шинный адаптер

Рис. 1-3. Различие между централизованным и децентрализованным подходами к управлению системой Представим себе стаю уток, летящих в форме треугольника (Рис. 1-3). Если они управляются централизованно, то «центральный компьютер» постоянно должен рассчитывать траекторию полета для каждой утки. Если хотя бы одна из них будет застрелена охотником, то компьютер с помощью соответствующего алгоритма, должен будет снова заполнить образовавшееся пустое пространство, изменив траекторию полета остальных уток. Естественно, для такой сложной системы, как центральный компьютер, подобный алгоритм реализовать непросто. Предположим теперь, что утки объединены в сеть посредством некой Fieldbusсистемы (Рис. 1-3). Теперь требуется лишь задать каждой утке угол, под которым она должна лететь по отношению к впереди летящей, и расстояние до нее. Если какая-либо из уток будет застрелена, то система относительно быстро восстановится сама и для заполнения пустого пространства не потребуется каких-либо дополнительных затрат. Интеллект каждой утки в этом случае может быть относительно невысоким. Само собой разумеется, что и в центрально-ориентированную систему могут быть встроены простые параллельные процессы, как это сделано в Fieldbus-системах. Однако такое решение при разработке центрально-ориентированной системы не

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

1.3. Информационный обмен как основа распределенных систем 1.3.1. Иерархия системы Объединение систем компьютеров в сеть приобретает настолько сложный характер, что плоская архитектура сети теряет всякий смысл. Во всех областях автоматизации предпочтение отдается сетям с вертикальной иерархией систем3, в которых на каждом уровне можно реализовать логически обособленный набор функций. Рассмотрим пятиуровневую модель некоего автоматизированного производства (Рис. 1-4). Слева от нее находится сеть, с помощью которой можно упорядочить уровни. Понятно, что количество уровней и их вид зависят от набора параметров, определяющих конкретную систему. При автоматизации систем зданий эта схема выглядит совсем не так, как в случае системы управления технологическими процессами. Разумеется, от начальных условий (набора функций для конкретного уровня) зависит, какая сеть и на каком уровне будет использована, — практика заставляет думать более гибко.

3

В связи с этим в технике автоматизации появилось понятие «CIM-пирамида» (CIM - Computer Integrated Manufacturing).

6

Рис. 1-4. CIM -пирамида (вертикальное разделение в зависимости от задач) В основе терминологии, принятой в этой книге, лежит следующее правило: исходя из общепринятого определения LAN (например, IEEE 802.3), все сети, находящиеся иерархически ниже, должны называться FAN (Fieldbus Area Networks). He должно проводиться разделения на «шины датчиков и исполнительных механизмов», «мультиплексные шины» и т. д., так как основным поводом для него служат маркетинговые интересы. Иерархически вышестоящими по отношению к LAN следует считать WAN, связьюающие LAN между собой, а в определенных случаях и FAN (например, при прямом соединении LonWorks сетей ISDN). Для полноты картины назовем GAN-так называемые глобальные спутниковые сети, находящиеся иерархически выше WAN.

1.3.2. Семиуровневая модель ISO/OSI Для описания сетевого взаимодействия Международная организация по стандартизации ISO (International Organisation for Standardisation) разработала модель сетевого объединения компьютеров (в то время речь шла прежде всего об объединении с помощью WAN и LAN), которая была названа OSI (Open System Interconnection, в русской терминологии — модель взаимодействия открытых систем). Встречается и полное название — модель ISO/OSI. Принцип, который лег в ее основу, был относительно прост. Все необходимые коммуникационные функции были собраны и упорядочены в рамках семиуровневой иерархической модели (Рис. 1-5). При меньшем количестве уровней разбиение на модули не дает преимуществ. Большее количество уровней нежелательно, так как существующий между ними интерфейс приводит к так называемым вертикальным издержкам — непроизводительным затратам системных ресурсов. Исходя из этих соображений и было выбрано магическое число семь.

7

Рис. 1-5. Семиуровневая модель (модель ISO/OSI) Когда разрабатывали стандарт ISO/OSI, меньше всего думали о функциях реального времени и не предвидели появления Fieldbus-систем. Несмотря на это, позже модель ISO сочли подходящей для спецификации и описания. Поскольку она положена в основу большинства существующих систем, вырабатывается общий образ мышления, возможно, отчасти сглаживающий ее недостатки. Все физические и механические параметры модели определяются на нижнем уровне, который является передающим. На более высоких уровнях определяется способ доступа к шине, описывается составление кадров данных и осуществление их защиты при передаче (связь абонентов типа «точка-точка»). Если между двумя устройствами установлено соединение, то при этом образуются как минимум две связи типа «точка-точка», которые могут быть совершенно различными. На уровне 3 выполняется маршрутизация, то есть выбор пути. В телефонной сети на этом уровне осуществляют связь пути с номером телефона, поэтому его часто называют коммутационным. Уровень 4 управляет связью «точка-точка»: он отвечает за то, чтобы пакеты данных, посланные отправителем, дошли до получателя в нужном порядке, то есть управляет потоком информации. На уровне 5 организуются сеансы — одновременный обмен данными между различными абонентами. В определенных ситуациях задачей этого уровня является идентификация участников и синхронизация сессий после их прерывания. На уровне 6 происходит согласование общего набора символов (языка). Уровень 7, как и уровень 1, занимает особое место: он представляет собой интерфейс с внешним миром, а также службы прикладного уровня — либо самостоятельно, либо требуя этого от уровней, лежащих ниже него, которые в свою очередь также могут обратиться к ниже лежащим уровням (иерархическая система)4.

4

Можно также представить демократическую систему, затраты на которую будут несравнимо выше.

8

Таблица 1-1. Уровни и функции модели ISO/OSI Обозначение

Функции

7

Application Layer Прикладной уровень

Пользовательские коммуникационные службы

6

Presentation Layer Уровень представления данных Session Layer Сеансовый уровень

Приведение в соответствие языка и набора символов

4

Transport Layer Транспортный уровень

3

Network Layer Сетевой уровень

Построение связи «точкаточка», управление потоком данных Маршрутизация

5

2 Data Link Layer Уровень связи данных 1

Physical Layer Физический уровень

Организация сессий, идентификация участников

Формирование пакетов данных, защита данных «точка-точка», управление доступом к среде Определение всех физических и механических параметров передачи

Рассмотрим различные предметные области (наборы параметров, описывающих систему), например, системы автоматизации зданий и технологических процессов. Требования, предъявляемые к производительности этих двух управляющих систем, совершенно различны. Из соображений безопасности при автоматизации технологических процессов никогда не производят подключения большого количества узлов к одному сегменту. Очевидно, по этой же причине в Fieldbus-системах, применяемых в этой области, стараются использовать не более 1000 или даже 100 узлов. Но если можно ограничить количество узлов и отказаться от маршрутизаторов (коммутационных узлов), то уровень 3 не нужен, может отпасть необходимость и в уровне 4. Выигрыш огромен: из коммуникационной колонны выпадает несколько интерфейсов, система становится дешевле, повышается ее быстродействие. При автоматизации зданий хотят, наоборот, иметь по возможности как можно больше узлов. Помимо того пользовательская сеть, объединяющая системы освещения, обогрева и регулировки климата, должна соединяться с системами сигнализации и охраны. При этом важно, чтобы узлы могли обмениваться данными различными путями. Таким образом, уровни 3 и 4 оказываются необходимы. Приведенные примеры показывают, что модель ISO/OSI не требует интеграции

9 всех семи уровней в реальную систему. Функции нереализованных уровней можно перенести на другие уровни. Почти все Fieldbus-системы, используемые для автоматизации процессов, имеют всего три уровня, тогда как те, что применяются для автоматизации зданий, имеют по крайней мере пять уровней. LonWorks — одна из немногих Fieldbus-систем, в которой присутствуют все семь уровней. Это объясняется двумя причинами. Первая указана почти во всех изданиях корпорации ECHELON5: при универсальности применения LonWorks полностью обеспечивает объединение сетей компьютеров. Вторая причина упоминается не так часто. Уже сейчас видно, что LonWorks в конечном итоге значительно превзойдет производительность всех существующих Fieldbus-систем. Если на сегодняшний день мы еще не можем автоматизировать все возможные процессы с помощью LonWorks, то уже в недалеком будущем такая возможность представится [Loy97]. Еще несколько замечаний относительно модели ISO/OSI. Различают два направления коммуникации (Рис. 1-6). Коммуникация между некоторым уровнем п и уровнем выше (п+1) осуществляется посредством интерфейса, построенного на основе спецификаций служб. Верхний уровень является «пользователем служб» (SU, Service User), а нижний — их «поставщиком» (SP, Service Provider). Обмен информацией между уровнями осуществляется в точках доступа к службе (Service Access Points, SAP), причем элемент более высокого уровня может обращаться к элементу более низкого Уровня. Это важно, если, например, нужно соединить уровни с помощью другого пути, что достигается выбором специальных SAP.

5

Родоначальник и основной производитель продуктов LonWorks (прим. переводчика).

10

Рис. 1-6. Возможности связи SAPs (Services Access Points) Горизонтальная коммуникация (коммуникация между двумя одинаковыми лежащими напротив друг друга уровнями) осуществляется посредством протокола типа Peer-to-Peer — протокола взаимодействия между элементами сети. Таким образом, на семи уровнях существует семь протоколов.

1.3.3. Топологии Сети можно классифицировать по физической и логической структуре. Высказывание «сеть построена по принципу кольцевой или шинной структуры» является неполным. Например, в основе Fieldbus-системы может быть физическая шина, которой на верхнем уровне соответствует логическое кольцо. Возможен и обратный вариант. Вопрос о том, какая архитектура оптимальна, решают по-разному в каждом конкретном случае. LonWorks предполагает различные топологические структуры, и все они имеют право на существование. Рассмотрим их разновидности.

С точки зрения реализации самая простая структура — кольцо (Рис. 1-7), в котором все узлы соединены друг с другом по принципу «точка-точка». Механизмы передачи данных могут использоваться самые различные. Наиболее быстрым в области Fieldbus-систем является «способ сдвигающего регистра»: каждый узел имеет в своем распоряжении такой регистр, который сдвигает поступающие данные. Поскольку все узлы логически соединены последовательно, то кольцо образует один большой сдвигающий регистр, состоящий из отдельных узлов — сдвигающих регистров. Явная адресация в этом случае отсутствует, кадр идентифицируется по его началу; после

11 фазы конфигурации каждый узел может самостоятельно определить, какие биты зарезервированы для него. Если предположить, что все узлы посылают и принимают данные с максимально возможной скоростью, то система теоретически имеет наименьшее время реакции. Однако на практике наибольший интерес представляют кольца другого типа. Представьте себе кольцо, в котором узлы могут принимать и посылать данные в обоих направлениях. Если разрушить такое кольцо в какой-либо точке, то для передачи данных на все остальные узлы можно использовать противоположное направление. Это часто необходимо для систем, требующих высокой надежности6 (например, системы наблюдения). LonWorks допускает такой вид топологии. При топологии типа «звезда» вся информация проходит через центральный узел. Как и в кольце, все связи строятся по принципу «точка-точка», что часто упрощает систему коммуникационной техники и разводки кабеля. Многие локальные сети, физически построенные по типу «линия» или «кольцо», имеют разводку кабеля, подобную «звезде». Однако системы типа «звезда», несмотря на их широкое распространение, являются коммутационными. Все основные функции коммутационной системы сосредоточены в центральном коммуникационном устройстве. Терминальное оборудование (телефонные аппараты, факс-машины и т. д.) обладает относительно невысоким интеллектом; отсюда следует, что его можно покупать по довольно низкой цене. Причем производительность и интеллект находятся в одном центральном устройстве, что упрощает обслуживание системы. Применительно к системам управления топология типа «звезда» обладает рядом преимуществ: контроллер с программируемой памятью является классической централизованной системой. Внедрение интеллектуальных компонентов ввода/вывода в области автоматизации технологических процессов до сих пор не достигло значительного продвижения на рынке; контроллеры с программируемой памятью и на сегодняшний день играют доминирующую роль. Для широкого распространения Децентрализованных систем нужно провести серьезную работу.

6

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

12 «Шина» — лучше называть ее «линия»7 — одна из самых широко распространенных топологических структур. Однако следует помнить об ее недостатке. Несмотря на то, что каждый узел электрически имеет всего одно соединение с линией, физически для подключения требуются либо сдвоенные, либо Т-образные разъемы, затраты на которые часто недооценивают. Значительная часть стоимости узла приходится именно на соединение, из-за чего эта структура не может применяться во многих последовательных системах, хотя в параллельных способна обеспечить более высокую производительность. Основной проблемой этой топологической структуры является доступ к шине (различные методы его реализации описаны в [Tane90, Farb84 и др.]). В связи с этим необходимо упомянуть один очень важный аспект: для многих приложений требование «real-time» (реального масштаба времени) является критическим. Под реальным масштабом времени подразумевается гарантированное время реакции системы. Например, водитель автомобиля должен иметь гарантию, что при нажатии на педаль тормоза желаемый эффект торможения будет достигнут без задержки. Рассмотрим этот аспект более подробно. Полное время задержки реакции есть сумма задержек всех процессов, происходящих в системе. Задержка, вызываемая шиной, может быть минимальной по сравнению с другими — в этом случае она не оказывает существенного влияния на процесс управления. Существует и еще один момент, которому часто не уделяют должного внимания. Real-time требуют многие системы, однако, по экономическим соображениям, определенное время реакции обычно гарантируют лишь с высокой вероятностью. Какой смысл гарантировать время реакции «абсолютно», в то время как надежность системы задается вероятностными величинами (ведь система может включать в себя множество непомехозащищенных электронных компонент)? Если время задержки гарантируется с экономически приемлемой вероятностью, этого вполне достаточно. Эта идея и была подхвачена LonWorks (LonWorks гарантирует время доступа с определенной вероятностью, которую, можно определить так, что система будет пригодна даже в случаях, касающихся безопасности человека). Более подробно об этом — в четвертой главе. И еще несколько кратких замечаний относительно методов доступа. В локальных сетях чаще всего применяют два метода доступа к шине: маркерный и множественный. Последний носит название CSMA/CD (Carrier Sense Multiple Access/ Collision Detection — множественный доступ с контролем несущей / распознаванием коллизий). Маркерный метод доступа проще, но, к сожалению, по сравнению с CSMA/CD его реализация обходится, как правило, значительно дороже. Суть этого метода состоит в следующем. В шинной системе существует один маркер, который передается от узла к узлу согласно определенному алгоритму. Узел, который в какой-то момент владеет маркером, получает право отправлять сообщения (занимать шину). 7

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

13 Нужно следить за тем, чтобы во время работы системы не происходило обмена двумя или более маркерами, чтобы маркер не терялся и т. д. Метод CSMA означает, что прежде чем получить доступ к шине, узлы «прислушиваются» к среде (listen before talk -слушать, прежде чем говорить). «/CD» означает, что в сети осуществляется распознавание и устранение коллизий. Методы устранения коллизий: управление по приоритету на основе выборки случайного числа, управление по приоритету на основе типа устройства и т. д. В области Fieldbus-систем все значительно сложнее. Существует целая палитра различных методов доступа. Так, для CAN (Controller Area Network) был введен CSMA/CA метод, где «/СА» означает «предотвращение коллизий» (Collision Avoidance). Подразумевается, что приоритетный узел получает право доступа к шине раньше остальных и нарушения целостности отправляемой им информации не происходит (поскольку коллизии отсутствуют). В системах PROFIBUS маркер предоставляется управляющему устройству типа Master8, которое опрашивает подчиненные устройства (типа Slave)9. Существуют Fieldbus-системы, работающие по слотовому принципу, и т. д. В рамках этой книги мы не будем приводить полного описания всех существующих принципов, ограничившись всего лишь некоторыми из них. К сожалению, в данной области не существует единообразия терминологии. Если понятия «метод маркерного доступа» и «CSMA/CD» стабильны, то в остальных случаях следует проверять, какой способ доступа к шине подразумевает тот или иной термин. В LonWorks используется метод CSMA/CD, которому посвящена глава 4. Структура типа «дерево» (Рис. 1-7) имеет большое значение прежде всего потому, что сети становятся все сложнее и сложнее, в связи с чем все более актуально разбиение их на отдельные иерархические «уровни» с различными функциями. К тому же в области автоматизации технологических процессов, систем зданий и т.д. при различных уровнях часто используют сети различных топологий. Корпорации Echelon и Motorola избрали другой путь. По их мнению, если LonTalk-протокол реализовать на достаточно мощных микропроцессорах, то его можно будет интегрировать в высшие сетевые уровни (Рис. 1-4). Полностью замкнутые и гетерогенные структуры как топологические формы организации сетей особой значимости для FAN не представляют. Они применяются в основном в системах, для которых важна безопасность (например, в авиастроении), и в больших вычислительных комплексах. Гетерогенность может быть реализована в структурах типа «линия», «кольцо» и т. д., соединение которых между собой зависит от специфики конкретного приложения и поэтому интереса для нас не представляет.

8 9

Примечание переводчика. Примечание переводчика.

14

1.3.4. Временная характеристика передачи данных, проблематика систем реального времени На основе данных, поступающих от датчиков, прикладная программа вырабатывает определенные команды для исполнительных механизмов. Время, прошедшее с момента измерения до начала работы исполнительного механизма после поступившей команды, должно быть так мало, чтобы величина его, измеряемая датчиком, значительно не менялась. Оно складывается из времени измерения датчиком требуемой величины, времени передачи и обработки данных по прикладной программе, времени передачи данных исполнительному механизму и времени его срабатывания (результатом обычно является механическое движение). Связь между измеряемыми величинами, выходными величинами и временем иллюстрирует Рис. 1-8. Если вышеупомянутое время меньше 2*=t, то ошибка выдаваемой величины имеет максимальное приращение. Нужно учитывать то обстоятельство, что величина At не постоянна, а наоборот, обратно пропорциональна времени производной измеряемой величины. Таким образом, при быстром изменении измеряемой величины время между ее измерением и действием исполнительного механизма (ИМ) должно быть меньше, чем в случае ее медленного изменения.

Рис. 1-8. Измеряемые и выходные величины как функции времени Если отдельные слагаемые общего времени (или само общее время) известны с достаточной степенью точности, их можно учесть в прикладной программе и тем самым улучшить динамику системы. Более критическим, чем общее время, фактором являются фазовые флуктуации — непредсказуемое варьирование времени передачи, которое заметно мешает процессу управления. Чаще всего их причиной является прикладная программа и процесс передачи данных, реже — датчики и исполнительные механизмы. Фазовые флуктуации, возникающие в процессе передачи данных, могут иметь самую различную природу. Для маркерных методов доступа характерны фазовые флуктуации, зависящие от конкретного протокола и загруженности шины. Фазовые

15 флуктуации, зависящие от нагрузки на шину10, возникают и при использовании метода CSMA/Cx. Задержки могут возникнуть при использовании множественного доступа (Carrier Sense multiple Access)' или из-за появления коллизий (в обоих случаях причиной является высокая нагрузка на шину), фазовые флуктуации, возникающие при высокой нагрузке, зависят от времени занятия шины отдельными устройствами, которое, в свою очередь, зависит от длины сообщения и скорости передачи данных. Практически все протоколы, реализованные как аппаратно, так и программно, порождают зависящие от конкретики реализации фазовые флуктуации. Их можно избежать только централизованным управлением доступом к среде передачи данных, но тогда увеличивается среднее время задержки. Особенно заметно это при небольшой нагрузке на шину.

1.3.5. Стратегия передачи данных на прикладном уровне Стратегия передачи данных в Fieldbus-системах на прикладном уровне должна рассматриваться в совокупности с функциональным назначением отдельных узлов и способом управления средой передачи данных. В рамках классического подхода, ориентированного на централизованное управление, принято оперировать такими понятиями, как «Master» (основное устройство), «Slave» (подчиненное устройство), «Polling» (опрос), «гарантированное максимальное время доступа» и «детерминированная система». Эти понятия, как правило, относятся к неинтеллектуальным датчикам и исполнительным механизмам. Такой подход привел к возникновению Fieldbus-систем с централизованным управлением доступом к среде передачи данных, а также с маркерным методом доступа. Оба этих способа надежны при высокой нагрузке на шину. В Fieldbus-системах с методом доступа CSMA (например, в LON-системах), следует придерживаться другой стратегии — стараться не допускать высокой нагрузки на шину. Преимущество метода доступа, используемого в LON, заключается в том, что при малой нагрузке на шину время доступа к ней стремится к нулю. Следовательно, необходимо минимизировать загруженность шины и передавать данные только тогда, когда это действительно необходимо. Самый простой способ уменьшения фазовых флуктуации, возникающих из-за высокой загруженности шины, заключается в минимизации времени передачи сообщений: флуктуация не может превышать времени передачи. В LON-системе этого можно достичь следующими мерами: — отказом от опроса — датчик посылает данные только тогда, когда измеряемая им величина меняется (принцип «send on delta» — посылать при изменении); — сообщения о событиях датчик посылает, как только измеряемая им величина, например температура, достигает заранее заданного значения. Сравнение заданного

10

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

16 значения величины с текущим выполняется самим датчиком циклически, с высокой частотой, без загрузки шины; — максимальной частотой посылки сообщений, которую датчик не может превышать, что исключает «наводнение» шины сообщениями при быстром изменении измеряемой величины; — изоляцией сегментов шины — локально используемые сообщения могут быть изолированы от остальной Fieldbus-системы посредством маршрутизатора. В качестве примера можно привести «петлю быстрого управления» (датчик и регулятор), по которой шина получает передачу текущего значения. При методе «send on delta» из-за небольшого значения delta частота передачи сообщений датчика очень велика, но они необходимы только регулятору.

1.3.6. Инструментарий Одна из наиболее важных причин успеха на рынке Fieldbus-систем — наличие инструментария для их разработки, настройки и сопровождения. Здесь уместно привести классический пример из истории 16-разрядных микропроцессоров. После разработки разными компаниями первых трех моделей анализ их производительности показывал: у 8086 она была очень небольшой, у 68000 — значительно выше, а наибольшую производительность демонстрировал Z8000 со своим чрезвычайно гибким набором регистров. Но именно последний исчез с рынка в первую очередь. 68000 также не смог приблизится по объему продаж к 8086. Это объясняется рядом причин, но одна из них стала решающей: фирма Zilog, разработавшая Z8000, не смогла своевременно предложить соответствующий инструментарий. Кому нужен процессор, пусть даже обладающий блестящими характеристиками, но требующий вложения огромных средств на разработку систем и их обслуживание? Компании, представляющие на рынок новые типы микропроцессоров, должны четко представлять себе полную стоимость будущей системы на всех этапах ее существования (разработка, реализация и сопровождение). Несомненно, что с появлением Neuron Chip («нейронного чипа»)11 в распоряжение разработчиков поступил и необходимый инструментарий — LonBuilder12. Echelon не стала повторять ошибок других компаний и не концентрировала все свои ресурсы на разработке новых версий Neuron Chip. Наоборот, приоритет был отдан разработке нового и улучшению существующего инструментария. Если сравнить результаты, достигнутые в этом направлении LON-технологией и другими Fieldbus-системами, то LON значительно опережает все остальные. Наконец, нам не нужно убеждать пользователей в том, что LON лучше других Fieldbus-систем. Вместо этого нам нужно доказать пользователям, что с помощью 11

См. главу 5 Программно-аппаратный комплекс, предназначенный для разработки и отладки приложений для Neuron Chip 12

17 распределенных систем (то есть Fieldbus-систем) можно получать более эффективные решения, чем с помощью традиционных технологий, а следовательно, Fieldbus-системы должны заменить классические контроллеры с программируемой памятью, традиционной прокладкой кабеля и т. д. Однако для традиционных систем давно существует отличный инструментарий. Таким образом, наша цель должна состоять в том, чтобы разработать доступные и мощные инструментальные средства для Fieldbusсистем. Для достижения этой цели необходимо сформулировать новый подход и продумать новые технологии построения инструментария, поскольку он представляет собой одну из наиважнейших составляющих будущего развития Fieldbus-систем. Это — полнота и взаимная совместимость инструментария, построенного по принципу «сверху вниз». Данная идея возникла давно. В области компьютерных технологий предпринимались попытки проектировать цифровые схемы аппаратного обеспечения не на уровне транзисторов, а на значительно более абстрактном уровне (насколько это представляется возможным). Цель — упростить проектирование, абстрагироваться от электронных (а иногда и физических) параметров схемы и вести разработку на функциональном, прикладном уровне. В области Fieldbus-систем надо стремиться к аналогичной цели-вести проект исключительно на высоком абстрактном уровне. Конечно, ситуация в области Fieldbus-систем серьезно отличается от ситуации в разработке традиционного цифрового оборудования. Существует множество предметных областей и, соответственно, множество различных реализаций Fieldbusсистем. Но при достаточно высоком интеллекте отдельного узла и тщательно разработанном инструментарии процессы интеграции, конфигурации, сопровождения и т. д. могут стать полностью (или почти полностью) автоматизированными. Несомненно, средства для интеграции, конфигурации, анализа протокола, мониторинга, отладки, тестирования, сопровождения и т. д. должны создаваться не однойединственной фирмой. Fieldbus-системы имеют множество областей применения, поэтому инструментарий должен быть различным. Рассмотрим понятия полноты и взаимной совместимости инструментальных средств на небольшом примере «домашней системы». Когда архитектор проектирует дом, он вносит в пространственный чертеж (Рис. 1-9, левый овал) стандартные обозначения выключателей, ламп, датчиков температуры, пожарной сигнализации. Затем с учетом мощности и особенностей осветительного оборудования, а также требований техники безопасности (Рис. 1-9, средний овал) проектируется топологическое размещение датчиков и исполнительных механизмов. Наконец, определяется логическое соответствие узлов, то есть предусматривается, какой выключатель включает определенную лампу, и т. д. Все остальные шаги должны выполнятся полностью автоматически. Компьютер должен спроектировать пространственные планы разводки кабеля, программы для узлов Fieldbus-системы, список ее компонентов, алгоритмы тестирования и т. д. Вмешательство инженера в этот процесс минимально. В дополнение к инструментам нужны такие средства, с помощью которых потребитель, не обладающий специальными знаниями, сможет быстро

18 «переконфигурировать» свой дом. Эти средства должны позволять проводить простейшее тестирование системы; более тщательную проверку может провести инженер по обслуживанию (на месте или удаленно).

Рис. 1-9. Взаимная совместимость инструментария Исходя из этих соображений, в основу LonBuilder были заложены концепции, отличные от общепринятых в области разработки микропроцессоров. Аппаратная часть LonBuilder представляет собой модульную систему с семью слотами, к каждому из которых можно подключить узел LON. Управляющим устройством является IBM, совместимый с ПК. Он связан с LonBuilder посредством интерфейсного адаптера. Важнейшим из всех подключаемых узлов является модуль сетевого менеджмента (Network Management Node), в функции которого входит передача управляющих данных, идущих по сети LON от ПК к различным узлам. Остальные слоты можно использовать для установки других модулей: одноплатных компьютеров (SBC-Single Board Computer), эмуляторов Neuron Chip, маршрутизаторов и т.д. Таким образом, пользователь может наблюдать работу отдельных узлов и получать информацию о функционировании сети. Программное обеспечение разработчика (ПК) позволяет создавать прикладные программы для узлов (редактор, компилятор, отладчик), разрабатывать и конфигурировать сеть (сетевой менеджер), а также следить за ее функционированием (анализатор протокола). Все перечисленные утилиты имеют однотипный пользовательский интерфейс. К сожалению, из-за конструкции отдельных компонент использование LonBuilder при установке системы на производстве или в здании крайне затруднительно. Устройство велико само по себе, кроме того, к нему добавляется еще и ПК. LonBuilder имеет высокую стоимость, а его ресурсы во многих случаях превышают необходимые. Но, несмотря на эти недостатки, LonBuilder — перспективен для дальнейшей разработки.

1.4. Основные концепции применения распределенных систем Для

обеспечения

высокой

производительности

системы,

состоящей

из

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

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

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

20 установку вновь поступивших деталей. Оба процесса, как правило, не зависят друг от друга, и синхронизация связана только с их окончанием; затем следует новый шаг обработки. Одна из важнейших особенностей независимых параллельных процессов состоит в том, что в них используются различные выходные данные. Кроме того, всегда существует некоторый механизм для координации этих параллельных процессов (в простейшем случае — распознавание их начала и завершения), который находится иерархически выше самих параллельных процессов и работает одновременно с ними, причем обмен данными между процессами и координирующей программой крайне незначителен. В ходе декомпозиции технического процесса выделяются блоки, обладающие этими свойствами (Рис. 1-10). Если машина многоцелевая, имеет смысл рассматривать каждую ось как независимый блок, координация производится «сверху». Однако эта модель хороша только тогда, когда требования, предъявляемые к координации, невелики (например, при двух— или трехосевом движении с четко заданной целью и неопределенной траекторией). В начале движения координаты цели и скоростные/временные характеристики задаются для каждой из осей в отдельности, никакого контроля в процессе движения не осуществляется. Для фрезерного станка с ЧПУ, который, например, должен вырезать круг, такой подход неприемлем, поскольку требует очень точной координации осей.

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

21

1.4.3. Управление и контроль Во избежание аварий технический процесс, устройство или машина должны не только управляться, но и контролироваться. Проанализируем функции контроля, предоставляемые внешним программным обеспечением. В централизованной автоматизированной системе функции управления и контроля невозможно отделить друг от друга. В одном случае они выполняются одним и тем же аппаратным устройством, в другом — программируются одним и тем же человеком, но могут быть перепутаны друг с другом. Все это усложняет программное обеспечение и приводит к ошибкам при проектировании. А к надежности центральной системы управления и контроля предъявляются высокие требования. Функции контроля осуществляются в течение всего времени работы устройства или технического процесса. Поступающие по ходу процесса данные непрерывно обрабатываются и при возникновении опасной ситуации (например, невыполнении системной функции в соответствии со спецификацией) к исполнительным механизмам и системе управления поступают команды. Функции контроля не требуют знания процесса управления. Они реализуются узлами мониторинга. Программа управления может не брать на себя обработку возможных аварийных ситуаций, так как это входит в функции контроля. Блоки контроля занимают в иерархии наивысшее положение. Они влияют на программу управления, обрабатывают выходные данные, блокируют доступ к исполнительным механизмам (Рис. 1-11 и 1-10).

22

Рис. 1-11. Иерархические и параллельные блоки контроля и управления станком Иерархические и параллельные блоки контроля и управления станком можно преобразовать в сеть с распределенными функциями управления (Рис. 1-12). С техническим процессом связаны только датчики и исполнительные механизмы. Все остальные узлы по своей природе являются управляющими и обмениваются данными только через шину. Разделение функций между узлами производится по следующему принципу: активные функции одновременно распределяются между различными одновременно активными узлами. Сюда включаются и независимые от приложения функции, поскольку они активны в течение всего времени работы системы. Из этого следует, что: — независимые от приложения функции «сбор данных» и «выдача данных» выполняют узлы-датчики и исполнительные механизмы. Количество таких узлов зависит от их пространственного расположения и сложности; — функции «управление» и «контроль» осуществляют различные узлы, активные в одно и то же время; — функции «смена деталей» и «смена инструмента» протекают в различных узлах, которые активны одновременно с узлами, выполняющими функции «управление», «контроль», «сбор данных» и «выдача данных»; — функции «обработка #1, #2» могли бы выполняться одним из двух узлов«смена деталей» или «смена инструмента», поскольку одновременной активности узлов нет. Но из соображений модульности и обозримости программы функцию «обработка» можно выделить в отдельный узел. Для оптимального решения задачи управления декомпозиция автоматизации устройства должна основываться на его анализе. Наряду с уже названными критериями, могут играть определенную роль и другие, такие как поведение после выхода из строя, ремонтопригодность, многообразие типов сетевых узлов и пространственные размеры всей системы в целом.

23

Рис. 1-12. Сеть автоматизации станка, схематически изображенного на Рис. 1-10 и 1-11. Сетевые узлы обозначены прямоугольниками, функции — текстом внутри них

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

24

Рис. 1-14. Сегментированная сеть. Поток данных подсегмента 1 состоит из потоков между контроллером и датчиком 1, между контроллером и исполнительным механизмом 1 (ИМ1), между маршрутизатором и контроллером. В подсегменте 2 существуют потоки данных между обоими датчиками и исполнительным механизмом 2 (ИМ2), а также между датчиками и маршрутизатором. Потоки данных, не попадающие на магистраль через маршрутизатор, не загружают ее

25

1.5. Обзор FIELDBUS-систем Сравнивать LAN друг с другом, когда обычно известны все начальные условия, гораздо проще, чем Fieldbus-системы. С Fieldbus-системами ситуация обстоит иначе. Таблицы, подобные приведенным в [Вött95], в которых сравнивается такой параметр различных Fieldbus-систем, как скорость передачи данных, абсолютно бессмысленны: в них сравниваются «яблоки с грушами»13. Вызывает недовольство то обстоятельство, что автор не отметил решающих преимуществ и недостатков соответствующих Fieldbus-систем, информация представлена не полностью и т. д. Объем требований, предъявляемых к Fieldbus-системам, значительно больше объема требований, предъявляемых к LAN. Поэтому в ближайшем будущем будут иметь большое значение множество различных Fieldbus-систем. Попытка оценить, сравнить и классифицировать Fieldbus-системы была предпринята [Schm96]. Из этого источника видно, насколько сложна тематика и какие конкретные проблемы возникают в ее рамках. Цель этого раздела — выделить те особенности, которые являются решающими для той или иной системы, в частности LON.

1.5.1. Обзор Lon Works Исходная цель: создать Fieldbus-систему, которая, с точки зрения корпорации Echelon, покрывала бы до 80% возможных применений Fieldbus. Для быстрого распространения система должна была концептуально поддерживать децентрализованное функционирование и предлагать пользователю универсальную поддержку. Эти требования воплотились в Fieldbus-системе, которая значительно выделяется среди других, хотя при детальном сравнении с Fieldbus-системами обнаруживает некоторые общие черты. Сравнение коммуникационных уровней модели ISO/OSI приводит к следующим выводам: — LON благодаря Neuron Chip осуществляет дифференциальное манчестерское кодирование (Differential Manchester Coding), которое применяется и в других системах, например в Fieldbus-системах стандарта IEC. Его преимущество заключается в том, что питание устройств осуществляется прямо через шину, а трансформаторы можно изолировать от остальных устройств. На физическом уровне LON поддерживает различные скорости передачи и передающие среды, в то время как другие Fieldbusсистемы не так универсальны. Это — серьезное преимущество LON (например в плане совместимости и взаимодействия). Наиболее распространенная скорость передачи данных в LON — 78 Кбит/с получена при трансформаторном сопряжении и так называемом трансивере с произвольной топологией. Топология сети может быть 13

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

26 произвольной в рамках максимальной общей длины шины (500 метров); — LON использует метод доступа к шине CSMA, который другими Fieldbusсистемами не используется, допускающий обусловленные коллизиями сбои при передаче сообщений, но ограничивающий вероятность их возникновения. Для предотвращения сбоев используется принцип «основное устройство-подчиненное устройство» (Master-Slave, иногда с меняющимися основными устройствами), маркерная передача или CSMA/CA, при котором осуществляется побитовый арбитраж; — схема адресации, используемая в LON, предусматривает разделение сетей на подсети, то есть сегментацию сети с помощью маршрутизаторов. Поскольку во многих Fieldbus-системах определены только коммуникационные уровни 1, 2 и 7, для них логически существует только одна сеть, что делает невозможной изоляцию коммуникационной нагрузки; — транспортный уровень в LON реализован ограниченно. Он предоставляет в распоряжение пользователя службу подтверждения, но не фрагментирует длинные блоки данных на несколько коротких; — на сессионном уровне LON обладает способностью к идентификации, которой лишены другие Fieldbus-системы. Идентификация обеспечивает защиту коммуникационной сети LON от несанкционированного доступа и может применяться в системах, требующих повышенной безопасности; — на прикладном уровне LON предлагает очень удобный, с точки зрения разработки программного обеспечения, вид коммуникации — связь через сетевые переменные. Прикладная программа предполагает возможность запроса данных какихлибо узлов специальной командой. В то же время она предусматривает передачу информации другим узлам; — очень важная особенность LON-наличие широкого набора сообщений для сетевого менеджмента. Их используют утилиты конфигурации, инсталляции и сопровождения сети. В настоящее время ситуация в области реализации LON такова: — существует два вида нейронных чипов (Neuron Chip), которые выпускаются двумя различными производителями. Протокол обмена данными не только стандартизирован, но и реализован для некоторых других Fieldbus-систем, таких как INTERBUS-S или CAN. На этих чипах выполняются пользовательские приложения, которые связываются с протоколом инструментарием разработчика; — компилятор и компоновщик (редактор связей), а также коммуникационное программное обеспечение (в инструментарии разработчика) поставляются только корпорацией Echelon. Однако в ближайшем будущем ситуация может измениться благодаря открытой публикации LON-протокола в 1996 году; — вопрос совместимости играет особую роль во всех Fieldbus-системах, поскольку один производитель не в состоянии охватить весь спектр Fieldbus-систем и поставить все их компоненты. Благодаря реализации коммуникационного протокола в одном чипе и разработке пользовательских программ единым инструментарием, некоторые препятствия совместимости устраняются уже в самом начале. Другие Fieldbus-системы, такие как INTERBUS-S или ЕШ, имеют схожую основу. То, что этого для достижения полной совместимости недостаточно, было обнаружено довольно

27 быстро. В LON были введены так называемые стандартные типы сетевых переменных, которые, как минимум, обеспечивают полную совместимость типов данных. Кроме того, была основана Ассоциация по совместимости LonMark (LonMark Interoperability Association), которая вырабатывает руководства по разработке прикладных объектов и их функциональных профилей, что означает следующий шаг в направлении совместимости. Другие работающие в области Fieldbus-технологий организации получили профили для всех классов приложений, а также подвели к необходимости использования тестов на совместимость и сертификации продуктов на базе Fieldbusсистем. Вероятно, в будущем продукты LON будут также подвергаться тестированию и сертификации. Концептуальное развитие LON проходило не так, как других Fieldbus-систем, большинство которых было рассчитано на узкий спектр применения. Позже начались работы по их универсализации. LON же предназначалась для широкого использования, и этот принцип отразился в ее конструктивных особенностях. Например, поддержка устройств ввода/вывода встроенным программным обеспечением включает не только обмен аналоговыми и двоичными данными, но и протоколы передачи для магнитных карт, устройств инфракрасного управления, дифференциальных кодеров, UART и последовательного обмена UART и устройств последовательного обмена данными со специальными запоминающими устройствами (Touch Memories). Другой концептуальной особенностью является четкая поддержка децентрализованной структуры систем. Поэтому: — разделения абонентов шины (узлов) на основные и подчиненные устройства не происходит; — инициатором передачи данных по умолчанию выступает отправитель, опрос является исключением; — программы в Neuron Chip активизируются событиями, например, получением данных.

15.2. PROFIBUS PROFIBUS (Process Fieldbus) [Bend90] принят CENELEC (EN50170) как европейский стандарт. Но процесс стандартизации еще не завершен. Многие фирмы и организации (группы пользователей) стараются распространить PROFIBUS во всем мире, прежде всего в США. Основная цель, которая преследовалась при разработке PROFIBUS, — построение Универсальной Fieldbus-системы. Однако через несколько лет выяснилось, что такой подход не оправдывает себя экономически. PROFIBUS существует в трех вариантах: PROFIBUS FMS (Fieldbus Messaging Specification), PROFIBUS DP (Decentralized Peripherals) и PROFIBUS PA (Process Automation). PROFIBUS FMS представляет собой сложную и мощную multimaster-систему. Как правило, ее применяют в различных приложениях в качестве магистрали, а на уровне датчиков и исполнительных механизмов используют другие Fieldbus-системы. PROFIBUS DP является усеченным вариантом PROFIBUS FMS, оптимизированным по времени

28 реакции. Это в чистом виде система типа master-slave с одним устройством типа master. PROFIBUS PA применяется для автоматизации технологических процессов; уровень 1й модели ISO/OSI в этой системе реализован в соответствии со стандартом IEC 1158-2 (защищенная система, которая может эксплуатироваться в отраслях, связанных с взрывоопасными работами). PROFIBUS был разработан для систем промышленной автоматизации, но сегодня он применяется во многих областях, где количество узлов ограничено (в противоположность, например, Fieldbus-системам, применяющимся при автоматизации зданий) по причинам надежности и безопасности. Поэтому в PROFIBUS ограничиваются топологической структурой типа «линия» (физическая среда), которая может разделяться на несколько сегментов, соединенных повторителями (Рис. 1-15). Поскольку в качестве передающей среды, как правило, используется стандарт EIA RS485, допускающий максимум 32 узла, то общее количество их в одном сегменте ограничивается 32 (основные устройства, подчиненные устройства, повторители). Более того, стандарт не позволяет устанавливать более трех повторителей на одну линию, в противном случае время задержки становится слишком большим. Общее количество узлов во всей системе ограничено 127 (Рис. 1-16). Адрес 128 используется для широковещательных запросов всем или нескольким абонентам сети. Теоретически можно спроектировать систему с 31 повторителем. Другие электрические характеристики, соответствующие EN50170: длина сегмента— 200-1200 м, в зависимости от скорости передачи; при использовании повторителей возможно ее увеличение до 4800 м; длина ответвления до абонента — 30 см; скорость передачи — 9,6 Кбит/с-500 Кбит/с (PROFIBUS DP: 12 Мбит/с).

29 Рис. 1-15. Возможная топология системы PROFIBUS

PROFIBUS допускает применение нескольких различных передающих сред, но чаще используется среда, определяемая спецификацией RS485. В этом случае применяется экранированная витая пара, на обоих концах которой установлены терминаторы. Логически сквозная линия позволяет отказаться от третьего и четвертого уровней модели ISO/OSI14. Поскольку при разработке данной Fieldbus-системы решили, что пароли, «телеконференции» и т. д. не имеют никакого отношения к промышленной автоматизации, а набор символов на уровне 6 всегда постоянен, в PROFIBUS полностью отказались от уровней 3-6, что увеличило быстродействие системы (за счет небольшого числа внутренних интерфейсов между уровнями).

14

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

30

Рис. 1-16. Физическая и логическая структура PROFIBUS Метод доступа к шине, используемый в PROFIBUS, часто называют «гибридным» [Bonf92], так как в нем интегрированы одновременно два принципа. В системах, построенных по принципу master-slave (Рис. 1-16), правом доступа к шине обладает только основное устройство (master). Подчиненное устройство (slave) может только отвечать на запросы, посылаемые master. Какое из slave-устройств станет активным, определяет master-устройство. При ошибке в программе до определенных slave-устройств очередь может и не дойти. В системах типа master-master все устройства типа master связаны в логическое кольцо. Это означает, что все masterустройства пронумерованы в порядке возрастания, и высший адрес следует за низшим в точке замыкания. Логическая очередность доступа к шине определяется маркером (Token Passing), который с программно-технической точки зрения по сравнению с методом доступа CSMA/CD более ресурсоемок (проверяет, не существует ли нескольких маркеров, не потерян ли маркер и т. д.). С другой стороны, маркерный механизм передачи гарантирует детерминированное поведение системы. В PROFIBUS определены два уровня приоритетов, и master-устройство, имеющее первый уровень приоритета, всегда имеет преимущество доступа относительно узлов с более низким уровнем приоритета. Высокоприоритетный доступ осуществляется только после освобождения шины другим master-устройством. При замене или добавлении узлов нет необходимости заново инициализировать систему, можно подключать узлы в процессе работы. Доступ к шине осуществляется на конкурентной основе. Время цикла шины постоянно, оно не изменяется даже при добавлении или удалении узлов. Нехватку времени на обработку «новых» узлов компенсируют «старые». Временные интервалы задаются не жестко. Master не обязан полностью использовать отведенное ему время, он может заранее передать свой маркер следующему узлу. [Borst92] писал, что «PROFIBUS можно рассматривать как систему реального времени только с оговорками»15. 15

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

31 Седьмой уровень выполняет функцию, которая отличается от режима mastermaster или, соответственно, master-slave второго уровня, — связь типа клиент-сервер. Узел PROFIBUS может быть запрограммирован либо как клиент, либо как сервер. Он не может работать одновременно в обоих режимах. В качестве сервера он предоставляет клиенту услуги, в качестве клиента запрашивает у сервера какие-либо переменные. Сравнивая PROFIBUS и LonWorks, можно констатировать, что PROFIBUS FMS нужно рассматривать скорее как магистраль для систем, в которых существует требование реального времени. PROFIBUS DP — это высокоскоростная система с ограниченным числом узлов. Поскольку протоколы master-узлов не могут быть полностью реализованы аппаратно, вопрос совместимости не является тривиальным. Именно по этой причине повсеместно организуются центры сертификации PROFIBUS.

1.5.3. P-NET P-NET представляет собой часть введенного в 1996 году стандарта CENELEC EN50170. Это — multimaster-система (до 32 master-устройств на шину), в которой узлы подразделяются на master и slave. Однако, в противоположность PROFIBUS, masterузел может использоваться и как slave, благодаря чему другой master может относительно легко установить с ним связь. В основе P-NET лежит стандарт RS485, но в несколько видоизмененной форме. Для уменьшения влияния отраженных волн [Bott94] кабель витой экранированной пары замыкается в кольцо (Рис. 1-17), хотя с физической (и тем самым с топологической) точки зрения по-прежнему представляет из себя линию. Доступ к шине осуществляется при помощи передачи виртуального маркера: master-устройства получают доступ к шине циклически, в порядке возрастания их адресов (данная схема была специально разработана для P-NET). Каждое master-устройство может передать slave-устройству только одно сообщение (один кадр); каждое slave-устройство также может ответить только одним сообщением. Если запрос посылается одновременно всем slaveустройствам (широковещательный запрос), то ни одно из них не имеет права отвечать на него. Время цикла передачи маркера зависит от длины сообщения, а оно ограничено. Следовательно, P-NET является детерминированной системой, поскольку имеется возможность точно просчитать «наихудший случай».

32

Рис. 1-17. Конфигурация сегментов в P-Net. Слева — структура разводки, справа — физическая структура А — исполнительный механизм (Actuator), S — датчик (Sensor) Наибольший интерес в P-NET представляет сегментация сети. Для построения относительно независимых сегментов реализован третий уровень модели ISO/OSI (Рис. 1-18), сегменты соединяются друг с другом через так называемый шлюз (в обычной терминологии — маршрутизатор), преимущество которого заключается в простоте. Он предоставляет разработчику возможность организовать статическую или динамическую маршрутизацию в соответствии с программой. Для этого контроллер сохраняет информацию о прохождении через него сообщений master-устройства, а при ответе slave-устройства обратный маршрут ему уже известен.

Рис. 1-18. Сегментация в P-Net Скорость передачи данных определена жестко-76,8 Кбит/с, что характерно для всей P-NET. С одной стороны, предлагаются интересные функции и возможности для получения простой, полностью обозримой системы, с другой — ограничены важные аспекты, параметры и т. д. При сопоставлении P-NET с LonWorks обращаем внимание на то что протокол P-NET, как и протокол PROFIBUS, интегрирован в стандартный

33 контроллер, что порождает вопросы совместимости16.

1.5.4. INTERBUS-S INTERBUS-S (S — от слова Speed, скорость) [Bagi94], разработанная фирмой Phoenix Contact, значительно отличается от других известных Fieldbus-систем. В ее основе лежит топологическая структура типа «кольцо», функционирующая по принципу сдвигающего регистра. INTERBUS строится как система master-slave. Master рассматривает все slave-устройства как одно большое периферийное устройство — регистр. Размер регистра определяется количеством slave-устройств. Master (его также называют контроллером) сдвигает весь кадр сообщения через периферийные устройства по всему кольцу, в результате чего получает этот же кадр обратно в свой буфер. Задержка определяется количеством периферийных устройств (Рис. 1-19). Этот метод называется «передачей суммы». Прежде чем суммарный кадр будет пошагово перемещен, каждое slave-устройство выставляет в буфер отправки свои данные для master, прежде всего ID -идентификационный код (Рис. 1-20). После этого master сдвигает слово кольцевой проверки (Loopback Word, LBW— 16 бит), а также управляющие биты, пока снова не получит LBW (Рис. 1-21). Таким образом он получает идентификационные коды всех узлов, первый цикл завершается. При втором цикле сдвига в начале суммарного кадра снова посылается LBW, за которым следуют выходные данные для slave-устройств. Когда весь кадр с LBW возвращается master, он содержит выходные данные slave. При этой технологии метод INTERBUS-S обнаруживает явный детерминизм. Структура сдвигового регистра определяет минимальные непроизводительные затраты в передаваемом кадре. Адресация узлов чрезвычайно проста: адрес непосредственно предопределяется позицией в кольце, уровни приоритета отсутствуют и т. д. Детерминизм достигается посредством операции сдвига: несмотря на то, что каждый абонент имеет свой собственный тактовый генератор, они действуют асинхронно относительно друг друга на частоте 16 МГц, но синхронизируются по первому биту поступающего кадра данных.

16

Безусловно, в LonWorks вопросы совместимости также возникают (даже несмотря на то, что все семь уровней модели ISO/OSI «зашиты» в кремний - Neuron Chip, а протокол жестко фиксирован). Однако технически протокол обмена LonWorks значительно проще.

34

Рис. 1-20. Распределение данных перед циклом

35

Рис. 1-21. Распределение данных после прохождения цикла В качестве передающей среды рекомендуем использовать пятижильный экранированный кабель (что также определяется стандартом RS485): две линии для каждого направления, одну — для массы. Поскольку в основе лежит кольцевая структура, то на узел должно выводиться 10 жил (в PROFIBUS их всего 4). Master-устройство обеспечивает и функции связи с находящимися иерархически выше сетями и может использоваться, в частности, как шлюз, если в качестве магистрали используется PROFIBUS/FMS. Принцип передачи суммы ограничивает размер суммарного кадра-256* 16 бит = 4096 бит (в общем случае абонент имеет один 16-битный сдвиговый регистр). Ограничение вводится для того, чтобы объем памяти master-устройства, и прежде всего время цикла, не были слишком большими (при определенной длительности цикла безразлично, имеется ли один абонент с длиной слова 32 бита или два абонента с длиной слова 16 бит). При передаче большого объема сведений (параметров, программных данных и т. д.) их передают частями (Рис. 1-22). Полная передача информации требует N кадров.

36

Рис. 1-22. Кадр данных в INTERBUS-S: Ctrl -управляющее слово; DA — данные; FCS — Frame Check Sequence (последовательность проверки кадра); Неа — заголовок; Ind — индекс; LBW-Loop Back Word; Pa — параметр; Pdi — данные процесса i-го модуля Скорость передачи составляет, как правило, 500 Кбит/с. При такой скорости общая длина линии «точка-точка» может достигать 400 м (удаленная шина), а при использовании повторителей и медных кабелей-до 12,8 км (при оптоволоконным кабеле-до 80 км). При соответствующем аппаратном обеспечении система может работать со скоростью до 2 Мбит/с. Поскольку каждый абонент имеет прямую и обратную линии связи, он требует два повторителя (Рис. 1-23).

Рис. 1-23. Расположение усилителей в повторителе Большим недостатком INTERBUS-S часто считают то, что, во-первых, топология типа «кольцо» может быстро привести систему к полному выходу из строя. Но как показывает практика эксплуатации этой системы в типичных для нее областях (промышленная автоматизация), полный выход из строя одного узла требует остановки всего процесса. Во-вторых, Phoenix Contact были созданы активные клеммы шины (Рис. 1-24), которые позволяют частично отключать дефектные части сети. Существуют три принципиально различные системы шин: удаленная, о которой шла речь до сих пор, инсталляционная и периферийная. Инсталляционная шина отличается от удаленной тем, что содержит линию энергоснабжения абонента. Периферийная шина имеет TTL-переключатель, причем расстояние между абонентами ограничивается 125 см [Schn94].

37

Рис. 1-24. Разводка кабеля и структура шины

1.5.5. CAN Система CAN (Controller Area Network) разработана фирмой Bosch для автомобилей. Она выделяется среди всех других Fieldbus-систем прежде всего помехоустойчивостью. В CAN встроен многоступенчатый механизм распознавания ошибок, а также механизм самоконтроля и самоуправления, роль которых настолько велика, что в случае необходимости они могут самостоятельно отключить отдельные устройства. Это означает, что основным приоритетом в CAN является безопасность (в противоположность другим Fieldbus-системам, для которых важнее надежность). Философия CAN предполагает отказ от гибкой реконфигурации и изменения параметров узлов. Следствием этого является упрощение интеграции любых узлов в существующую сеть и снижение цены на электронные компоненты. Широкое распространение CAN получила тогда, когда фирма Intel начала сотрудничать с Bosch, поставляя соответствующие компоненты, а фирма Daimler Benz приняла решение использовать их в своих автомобилях. Это гарантировало, что CAN станет продуктом массового производства, а стоимость компонентов будет предельно низкой. Цена интегральных схем CAN около 2$ за штуку17. Эти два фактора — высокая помехозащищенность и низкие цены — делают CAN серьезным конкурентом Fieldbusсистем. Сегодня CAN применяется во многих областях: в медицине, промышленной 17

Нужно учесть, что в этих «недорогих компонентах» не содержится контроллер.

38 автоматизации, технологии производственных процессов и т. д. Каковы же важнейшие показатели мощности CAN? Адресация CAN ориентирована не на станции, а на сообщения. Каждое сообщение распределяется согласно идентификатору (Рис. 1-25)-11-битному слову. Таким образом, узлы характеризуются специальными кадрами, которые они отправляют или ожидают. Замена одного узла на другой происходит без установки адреса «на месте». Это — один из подходов, принятых в автомобильной промышленности.

Рис. 1-25. 11-битный кадр данных Для обеспечения малого времени реакции пакет данных задается жестко, единственно допустимым изменением является количество байт данных; максимально ограничивается длина событий: наименьший элемент состоит из 44 битов, наибольший -из дополнительных 8 байт; в качестве метода доступа к шине избран CSMA/CA; подтверждение (на самом низком логическом уровне) передачи атомарной единицы происходит еще в течение отправки 11-битного слова, получатель устанавливает в слоте подтверждения соответствующий бит на «low»18. Более подробного разъяснения требует реализация метода CSMA/CA. CAN-это система типа master-master. Чтобы применение обычного /CD метода не приводило к задержкам доступа к шине, используют побитовый арбитраж, при котором значения low и high реализуются технически настолько по-разному, что возникают рецессивные (‘1’) и доминантные (‘0’) двоичные величины. Таким образом, если к шине одновременно обращается несколько устройств, пытаясь отправить свои данные, от шины отстраняется тот элемент, рецессивный бит данных которого будет перезаписан раньше доминантного бита другого (недеструктивный доступ). Преимущество получает то сообщение, которое имеет наивысший приоритет (идентификатор с низшим значением). Время ответа гарантировано только для сообщения с наивысшим приоритетом; сообщения с низшим приоритетом при интенсивном трафике могут надолго задерживаться. При интеграции на седьмом уровне алгоритма, вновь переупорядочивающего идентификаторы, можно динамически влиять на детерминированное поведение системы. 18

Этот принцип - причина того, что в этой шине, как ни в какой другой, скорость передачи данных зависит от ее длины.

39

Рис. 1-26. Подключение к шине в CAN Особым аспектом CAN является безопасность. Распознавание и устранение ошибок происходит на нескольких уровнях, но реализовывать его в каждом случае не нужно. С физической точки зрения передача данных на нижнем уровне выглядит, как в RS485 (Рис. 1-26а). Для исключения помех монтируют нагрузочные сопротивления, используют кабель типа «витая пара». При более подробном рассмотрении схемы подключения бросаются в глаза компоненты, обеспечивающие дополнительные функции (Рис. 1-266). Если на линии передачи возникает короткое замыкание на массу или питающее напряжение, то встроенный компаратор не распознает ни один бит. По этой причине дефектные линии будут отключены позже, и компаратор будет держать опорное напряжение. Затем передача по линии может осуществляться асимметрично. При такой реакции схемы распознаются все простые и некоторые сдвоенные ошибки. На уровне защищенной передачи данных учитывается подстановка битов разрешается подавать на вход максимум 5 бит одинаковой полярности) и КС-проверка. Меры защиты срабатывают на уровне узлов. Они отключаются от шины, еcли фиксируют помехи в работе шины (демократический принцип отключения).

40

1.5.6. EIB EIB (European Installation Bus) базируется на стандарте instabus. Данная система была разработана рядом фирм, работающих в этой области, причем фирма Siemens была ответственной за чипы, первую версию технологии передачи, а также средства инсталляции, тогда как другие фирмы занимались разработкой и стандартизацией приложений. Для координации общих интересов была образована организация EIBA (European Installation Bus Association) с резиденцией в Брюсселе. В ноябре 1992 года в Германии был издан предварительный стандарт DIN V VDE 0829 «Системная техника для дома и зданий», составной частью которого была ЕГО (Рис. 1-27). Уровень 7

6

Доступные службы Объекты коммуникации, кодонезависимая передача данных, запрос/ответ, защита доступа -

5

-

4

Подтверждения, адресация точкаточка/групповая, распознавание переповторов, подсчет последовательностей Маршрутизация, распознавание циклов на линии Кадры, кодирование, контрольные суммы, CSMA/CA, приоритеты, адресация, распознавание и устранение ошибок Интерфейс со специфичной средой передачи данных и определения сигналов, ЕМС-спецификация, техника сопряжения

3 2

1

М Е Н Е Д Ж М Е Н Т

Рис. 1-27. Стек протокола EIB (ISO/OSI модель), а также функции, реализованные на отдельных уровнях Передача данных осуществляется через витую пару с определенными физическими характеристиками. Экранированная витая пара позволяет устанавливать шину длиной до 1000 м без повторителей. Максимальное расстояние между двумя абонентами не должно, однако, превышать 700 м. К одному сегменту шины может быть подсоединено максимум 64 абонента. Топология шины допускает как структуры типа «линия», так и структуры «звезда» или «дерево», характеристики которых подходят для использования в зданиях.

41 Скорость передачи данных по витой паре составляет 9600 бит/с и не может быть изменена. В качестве других передающих сред могут быть использованы линии электропередачи, коаксиальный кабель, свет, радио— и инфракрасные волны. Как и в LON, на уровне связи данных применен CSMA/CA-метод доступа к шине. Передача осуществляется асинхронно с 8 битами данных, 1 битом четности и 1 стоповым битом. Уровень 3, как и уровень 2, использует режим передачи данных без организации соединения (connectionless mode). Обмен между транспортным и прикладным уровнями ориентирован на режим с установлением соединения (connection-oriented mode). Таблица 1-2 дает перечень служб прикладного уровня, а также список услуг, которые транспортный уровень предоставляет в распоряжение прикладного. Существует несколько служб доступа к объекту коммуникации, а также служба независимой передачи данных кодом. Таблица 1-2. Службы прикладного уровня EIB Службы Функции прикладного уровня A_VALUE_READ Чтение значений, флагов и статуса объектов коммуникации A_VALUE_WRITE Изменение значений, флагов и статуса объектов коммуникации A_FLAGS_READ Чтение флагов, параметров и типов значений объектов коммуникации A_USER_DATA Кодонезависимая передача данных на транспортный уровень по уже имеющейся логической связи Максимальная длина сообщения данных составляет 23 октета. Для передачи начения отводится только 13 октетов (Рис. 1-28). Контрольная информация 8 бит Адрес источника

16 бит

Адрес назначения

16 бит + 1 бит

Счетчик маршрутизации Данные Контрольная сумма

Длина

3 бита, 4 бита Макс. 16*8 бит 8 бит

Рис. 1-28. Структура кадра данных Сам коммуникационный объект содержит следующую информацию:

42 — коммуникационный номер; — приоритет передачи; — разрешение на передачу данных; — разрешение чтения и записи; — флаг на требование чтения; — статус отправителя; — внешний флаг текущих событий; — тип значения; — значение. До сих пор не определены профили применения EIB в GLT-системах. Первым шагом в этом направлении со стороны EIBA была публикация спецификации так называемого EIS-EIBA Interworking-стандарта, в котором даны стандарты прикладных служб. Количество их постоянно увеличивается за счет предложений различных рабочих групп EIBA. Таблица 1-3 содержит приблизительный и далеко не полный список этих служб. Таблица 1-3. Выдержки из сетевого стандарта EIBA (E1S) EIS Функции EIS1 Подключение и отключение EIS2 Настройка EIS3 Время EIS4 Дата EIS5 Значение (температура, напряжение и т.д.) EIS6 Масштабирование EIS7 Управление приводом EIS8 Приоритеты В отличие от LON, основной упор в ЕГО делается на автоматизацию электрических сетей; особое внимание уделяется автоматизации систем зданий и помещений. Таким образом, ЕГО предназначена для применения не только в промышленности, например для управления приводом. Сравнение LON с ЕГО имеет смысл только тогда, когда они используются в одной и той же области.

43

1.5.7. Области и профили в PROFIBUS-системах Описанные в предыдущих разделах коммуникационные системы, за исключением некоторых, могут применяться в самых различных областях автоматизации. Благодаря использованию большого количества однородных компонентов снижается стоимость систем. Но стандартные приложения зачастую не удовлетворяют требованиям конкретной области их использования, а различные реализации допускают слишком большую свободу действий при разработке протокола. Примером служит PROFIBUS. Параллельно с разработкой прикладного уровня работа над профилем автоматизации систем зданий [PROF93], который позволил ввести в прикладной уровень PROFIBUS специальные функции этой предметной области (в этом случае можно говорить о «профиле области»). Профили LON можно определить как «профили приложений», поскольку они описывают определенные приложения или сложные устройства. Таким образом, задача разработки профиля заключается в повышении взаимной совместимости различных средств коммуникации посредством ограничения набора служб и компонент протокола. Точное определение профиля и его применение в LON дает Глава 11.

1.6. Перспективы децентрализации систем Сложно предвидеть технологии, которые будут существовать завтра. Однако уже сегодня видны прообразы технологий, за которыми будущее. Они рождаются в процессах поиска наиболее приемлемых решений технологических проблем. Из предыдущих глав очевидно следующее: протоколы, базирующиеся на 7уровневой модели, а также профили — это только начало целой серии исследований, основную часть которых еще предстоит провести. Вероятно, наиболее важные из них можно определить следующими ключевыми понятиями: — сетевой менеджмент; — избыточность; — избыточность распределенных знаний; — средства моделирования, мониторинга и тестирования; — человеко-машинный интерфейс. Сетевой менеджмент Количество узлов в сетях будет увеличиваться, одновременно будут расти требования к надежности. Следовательно, управление сетью должно стать более простым и защищенным. Совместное функционирование различных сетей, подключение виртуальных каналов будет успешным только на основе исследований сетевого менеджмента Fieldbus-систем. Многие научно-исследовательские институты уже осознали этот факт и уделяют данной области большое внимание. Следует отметить, что фирма Echelon, поняв это одной из первых, начала интенсивную

44 проработку актуальной темы и предложила довольно большое количество решений. Избыточность Избыточность узлов будет необходима по многим причинам. Во-первых, она необходима самому узлу, чтобы снизить вероятность выхода его из строя. Во-вторых, при низкой стоимости узла, с целью повышения надежности всей системы имеет смысл включать в нее параллельные узлы. В-третьих, параллельные каналы передачи данных (смешанная сеть, возможно даже с физически различными передающими средствами) будут использоваться все шире, сегодня это уже обычное явление в самолето— и кораблестроении. Если распространить эту мысль дальше и провести сравнение с природой, то мы увидим определенное сходство: в природе существует множество систем, для которых характерна «избыточность» узлов, причем они действуют совершенно самостоятельно. Речь идет о самоорганизующихся системах, в которых при возникновении дефекта элементы отключают сами себя (демократический принцип). Наиболее подходящее понятие, раскрывающее суть таких систем, заключено в слове Holon. Оно образовано от двух греческих слов — Holos (целое) и on (часть) — и обозначает философию отказа от использования жестких, четко взаимосвязанных элементов системы. Создают узлы, которые «знают» различные возможные конфигурации и выбирают в том или ином случае оптимальную. Или, согласно теории хаоса, в основу узла могут быть положены простые алгоритмы, которые сами по себе находят оптимальные структуры. Избыточность распределенных знаний Если проводить дальнейшее сравнение с природой, можно обнаружить еще один принцип, от которого природа редко отказывается. В природе знания распределены в большинстве своем так, что отключение одного их элемента не является трагедией для всех остальных. Подумайте о голографическом методе запоминания информации человеческим мозгом. Разрушение единственной ячейки приводит лишь к потери какой-либо детали. Почему же этот принцип не может найти применения в домовых системах? Что можно возразить против того, чтобы с избыточностью распределить сведения о доме между всеми его узлами? Преимущество такого подхода заключается не только в том, что потеря хотя бы одного узла из-за пожара или других причин не ведет к полной потере всех знании, но также и в том, что в определенных случаях процессы и анализ могли бы протекать параллельно и в пространстве, и во времени. Средства мониторинга и тестирования Системы становятся все более сложными и одновременно все менее обозримыми. Сравните сегодняшнее программное и аппаратное обеспечение с существовавшим ранее. Тот, кто хотел получить качество и надежность, должен был с особой тщательностью продумать, как заранее устранить все возможные ошибки. Вспомните методы тестирования программного обеспечения, при которых на

45 основании результатов тестирования пытались гарантировать отсутствие ошибок в программе. Сегодня это невозможно по экономическим причинам. Необходимы другие концепции моделирования алгоритмов верификации, избыточности, мониторинга, методов тестирования. Можно сформулировать признаки качества и надежности, которые будут постоянно проверяться службами, активизирующимися в сети, и деактивизирующимися в случае нехватки ресурсов. Эти службы могут работать хаотически, их размещают в сети с той или иной плотностью в соответствии с установленными вероятностными параметрами. Человеко-машинный интерфейс Человеко-машинный интерфейс можно считать «историей, не имеющей конца». Это — модель, которая будет совершенствоваться вместе с ростом знаний человека о своем собственном поведении, восприимчивости и ответных реакциях. Fieldbusсистема — это система датчиков и исполнительных механизмов. Для того чтобы люди, обслуживающие устройства, машины и т. д., могли быстрее, лучше, эффективнее работать с ними, придется «прощупать многие каналы». В будущем интерфейсе человек-машина основные задачи возьмут на себя, наряду с клавиатурой и возможными камерами, микрофоны, датчики вкуса, запаха и температуры, молниеносно реагирующие на любые действия человека.

46

2. Распределенные системы В дальнейшем под распределенной системой следует понимать совокупность автономных процессоров и систем, объединенных в коммуникационные подсети для накопления данных и действующих совместно для решения общей задачи. Посредством сети происходит координация распределенных процессов и обмен информацией. Определение распределенной системы в техническом смысле тесно связано с передачей информации и организацией обработки данных. Согласно [Ens78] существует по меньшей мере пять критериев, которыми можно охарактеризовать распределенную систему: архитектура аппаратного обеспечения, обработка и накопление данных, управление системой, ее инвариантность. Общая память, при помощи которой различные процессы могут обмениваться данными, в распределенной системе почти не используется. Поэтому классические методы синхронизации и коммуникации (семафоры, память общего доступа и т. д.) исключаются. Единственно возможным методом коммуникации является обмен сообщениями, причем отправитель и получатель выступают в роли равноправных коммуникационных партнеров, между которыми происходит неструктурированный обмен данных. Неструктурированная система сообщений требует эффективных, мобильных, коммуникационных служб, которые обычно иерархически упорядочены и допускают высокую степень свободы при разработке распределенных приложений. Понятие «распределенная система» применяется сегодня очень широко, независимо от того, идет ли речь о комплексах из нескольких машин или мультипроцессорных системах различных архитектур. Благодаря этому в большинстве случаев оно потеряло свои смысл. В этой работе рассмотрена концепция распределенных систем, полученных объединением датчиков и исполнительных механизмов в сеть, формирующая систему автоматизированного управления. Распределенная система управления представляет собой некоторое упорядоченное соединение узлов, обменивающихся друг с другом Данными об измерениях и управлении, с одной стороны, и осуществляющих коммуникацию человека и машины — с другой. Согласно модели Энслоу (Рис. 2-1), для достижения по-настоящему высокой степени децентрализации распределенная система должна отвечать пяти критериям. В прошлом из-за высокой стоимости системы, отсутствия необходимого инструментария

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

Рис. 2-1. Модель типизации распределенных систем Энслоу [Ens78]

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

49

2.1.1. Компоненты распределенной системы на уровне датчики — исполнительные механизмы Узлом называется коммуникационный элемент, связанный с передающей средой. Каждый узел обладает логическим интеллектом — микропроцессором. Узел имеет интерфейс с передающей средой и поддерживает общий протокол коммуникации. Максимальное число узлов зависит от передающей среды и количества сегментов. Если система адресации ориентирована на абонента, то есть требует наличия адреса у каждого из абонентов, то число узлов ограничивается максимально допустимым числом адресов. Количество абонентов одного сегмента сети зависит от передающей среды и используемого протокола передачи данных. В спецификации RS485, например, допускается максимум 32 устройства (EIA83). Коммуникационная модель распределенной системы описывает логическую структуру интерфейса всей коммуникационной системы. Архитектура открытой коммуникационной системы базируется на иерархически упорядоченных коммуникационных моделях, определяющих топологию, связи в сети и протокол передачи данных. Коммуникационная модель ответственна за то, чтобы при передаче сообщений между удаленными абонентами не возникало ошибок и задержек. Компоненты передачи данных — те электрические и механические компоненты, которые используются для передачи бит данных между двумя узлами, объединенными сетью. Обмен данными в передающей среде осуществляется путем изменения физических параметров, таких как напряжение, сила тока, сила света, частота и т. д. В качестве передающей среды может быть использован кабель типа витая пара, силовой кабель, оптоволоконный кабель. Для передачи данных на большие расстояния может потребоваться регенерация сигнала.

50

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

51

2.1.2. Особенности распределенной системы управления Благодаря применению последовательной связи в распределенных системах управления расходы на инсталляцию и прокладку кабеля в целом ниже, чем в обычных системах, имеющих форму звезды. Легко осуществляется расширение системы. Кроме того, в некоторых системах, в любом их месте, могут выполняться производственные, конфигурационные и обслуживающие задачи. Распределенная система характеризуется следующими особенностями: — она предполагает среду, в которой пространственно разделенные датчики и исполнительные механизмы обладают достаточной вычислительной мощностью для обработки локальных данных и сигналов; — поток информации в распределенной системе формируется посредством коммуникационных устройств, объединенных в сеть (сеть управления); — длина сообщения составляет в большинстве устройств всего несколько бит или байт; сигнал датчика подвергается предварительной обработке в Fieldbusустройстве и только потом, посредством сети, передается соответствующему исполнительному механизму; — на уровне датчиков исполнительных механизмов при автоматизации производственных процессов время реакции составляет несколько миллисекунд; при автоматизации зданий время реакции на несколько порядков выше. Пространственное распределение системы приводит к тому, что обмен данными между ее компонентами не может осуществляться через общую область памяти. Объединенный в сеть распределенный интеллект может относительно легко удовлетворять высоким требованиям, предъявляемым к надежности системы управления. Каждый абонент, имеющий в коммуникации равные права со всеми остальными, при выходе из строя передающей среды может принимать локальные решения и тем самым напрямую управлять частью процесса.

52

Рис 2-3. Центральные и автономные механизмы управления в распределенной системе На Рис. 2-3 сравниваются принципы центрального и автономного управления структурами типа master-slave. Отдельные компоненты распределенной системы работают автономно, на основании знаний о текущем статусе других компонент или всей системы в целом. Выход из строя или ошибочное поведение компоненты проявляется в задержке. Там, где задержки недопустимы или необходим высокий уровень защищенности, встраиваются средства контроля.

2.2. Распределенная система на базе технологии LonWorks Сети LON (Local Operating Networks) являются наиболее подходящим средством для построения децентрализованных систем. Как правило, системы LON строятся разветвленными (с пространственно распределенными ресурсами программного и аппаратного обеспечения, динамически конфигурируемыми распределенными устройствами, инвариантностью системы и кооперативной автономией) и могут содержать до нескольких десятков тысяч узлов. Узлы могут быть предназначены для применения в различных областях и сконфигурированы под определенные приложения. Сетевая техника LonWorks предполагает возможность использования различных передающих сред. К ним, наряду с витой парой и коаксиальным кабелем, причисляют также радио-, инфракрасные и световые волны, ультрафиолетовое излучение, силовые линии и т. д. На рис. 2—4 изображены важнейшие особенности технологии LonWorks.

53

Рис 2-4. Особенности LonWorks-технологии Основные правила коммуникации в системе LonWorks определяет протокол LonTalk. Все узлы LON должны в полной мере его поддерживать, так как в противном случае система не будет открытой. Ассоциация по совместимости LonMark, основанная производителями компонент LonWorks, разработала рекомендации для создания Lonсовместимых узлов [LONNM92]. Спецификации совместимости LonMark [LONNM92], [LONNM94] предоставили базу для разработки LonWorks-совместимых систем. В рамках программы LONMARK предусматривается также сертификация на совместимость продуктов, имеющих отношение к LonWorks. Протокол LonTalk может стать стандартным протоколом коммуникационных систем, используемых в целях промышленной автоматизации и автоматизации зданий. Примером тому являются стандарты CEN (Technical Committee 247, Controls for Mechanical building services) в области коммуникационных протоколов нейтральных к системам передачи данных устройств отопления, вентиляции и кондиционирования в Европе [Fis95] и BACNet для сетей автоматизации зданий в США [New96]. Технология LonWorks в будущем сыграет важную роль в области автоматизации: LonWorks уже находится на начальной стадии стандартизации техническим комитетом Integrated Home Systems [IHS] ассоциации электронной промышленности. Областью применения LON-систем является автоматизация процессов, зданий,

54 бытовых электроприборов, а также многие другие области, где требуется децентрализованное измерение и управление. Сейчас применение сетей управления LON ограничивается теми устройствами, для которых требуются скорости передачи данных до 1,25 Мбит/с и время реакции от 10 до 20 мс. В ближайшем будущем можно ожидать, что скорость передачи в LON возрастет в несколько раз, а время реакции резко снизится [Lo97]. Однако, как показано на рис. 2—4, протокол LonTalk (наряду со многими другими протоколами систем управления) плохо подходит для передачи видео— и аудиоинформации [Sch96]. Поскольку процесс коммуникации в сети управления зачастую происходит в сильно зашумленной среде (например, в среде с высоким электромагнитным полем), то защита пакетов данных при передаче в LON является очень важным, иногда решающим критерием для применения этой коммуникационной системы. Наряду с 16-битным полиномом ошибок (в каждом пакете гарантировано расстояние Хэмминга 6), в службы транспортного уровня также встроены подтверждения типа End-to-End. На прикладном уровне протокол LonTalk также содержит ряд мер для повышения защиты данных при их передаче. Способ доступа к шине представляет собой одну из важнейших особенностей сети управления. Сеть LON может состоять из нескольких десятков тысяч узлов, а также поддерживать несколько различных передающих сред в рамках одной сети. Встроенный в LonTalk способ доступа к шине — CSMA — дает возможность узлам производить доступ к шине в неактивном состоянии, позволяет увеличить скорость передачи данных и снизить время реакции, особенно для коротких, ограниченных по времени сообщений. У стандартных способов доступа, применяемых в LAN, это отсутствует. Таким образом, метод доступа к шине CSMA подходит для сетей с большим количеством узлов и устройств. Каждый узел LonWorks физически связан с коммуникационным каналом. Электрический интерфейс с передающей средой (трансивер), а также физическая топология, скорость передачи данных и максимальное удаление узлов друг от друга определены ассоциацией LonMark для различных передающих сред и служат стандартом для построения LON-совместимых систем. В дальнейшем будут рассмотрены примеры, демонстрирующие использование технологии LonWorks для реализации вышеуказанных приложений. Критерии выбора коммуникационных систем для разработки этих приложений в первую очередь должны основываться на динамике сигналов, которые подлежат передаче (ширина спектра сигнала), а также времени, которое требуется для передачи сообщения. В используемых в машино— и приборостроении сетях время реакции составляет в основном менее 3 мс (для обмена управляющей информацией между удаленными устройствами), а длина проводника — больше 100 м [ВК93]. Существуют различные критерии выбора конкретной распределенной системы, базирующейся на LON, например, величина расходов на инсталляцию, обслуживание, совместимость, распространение системы на международном уровне, надежность и т. д. Список некоторых информационных, коммуникационных и измерительных устройств представлен в таблице 2-1. В качестве решающего критерия применения технологии LonWorks как коммуникационной системы для перечисленных устройств здесь принята скорость передачи данных. При использовании максимального размера

55 пакета в LON можно достичь максимальной «нетто» — скорости передачи данных порядка 250 Кбит/с [LONW95]. В качестве остальных критериев использования систем, базирующихся на LonWorks, можно назвать, например, качество услуг, время реакции, а также величину временного интервала при обмене данными. Таблица 2-1. Пригодность существующих на сегодняшний день устройств для передачи аналоговых и цифровых измерительных и управляющих, а также речевых и видеосигналов Устройство Количество Спектр сигнала Цифровая Пригодность каналов скорость для передачи использования данных c LON PAL-TV [Sims69] 1 5 МГц 200 Мбит/с Не подходит Audio Compact Disc Стерео [IEC908] Hi-Fi [DIN445000] 1

2 х 20 кГц

1,4 Мбит/с Не подходит

20 Гц-20 кГц

2 Мбит/с

Не подходит

ISDN [Tan89] 1 Телефон 1 (ADPCM) [Kaf96] Преобразователь 1 аналогового сигнала в Цифровой

300 Гц-3,4 кГц 300 Гц-3,4 кГц

64 Кбит/с 16 Кбит/с

Не подходит Условно подходит

1кГц

10 Кбит/с

Подходит

Цифровой Датчик. 1 Время опроса 10 мс (10 клавиш)

10 х 100 Гц

10 Кбит/с

Подходит

56

2.3. Пример разработки системы в LonWorks В предыдущих разделах мы объяснили преимущества распределенной системы по сравнению с централизованной. Однако сложность программного обеспечения и негибкие механизмы управления процессом коммуникации могут значительно затруднить использование распределенной системы. Поэтому для быстрого проектирования коммуникационной системы в распределенные компоненты необходимо вводить соответствующие службы и функции менеджмента, такие как конфигурация интерфейса, модель связи, логическая адресация и т. д. В этом разделе рассматриваются некоторые важные функции для проектирования систем, базирующихся на LonWorks. Проектирование устройства управления поясняется графически. В качестве примера рассмотрим систему наблюдения за входом в дом, состоящую из устройства чтения чип-карт (chip cards), электронного замка и устройства оповещения. Физическая структура системы представлена как сеть связанных узлов LonWorks (Рис. 2-5). Каждый узел управляет своими датчиками или исполнительными механизмами и обрабатывает локальные данные. Иерархия программных компонент и логическая структура связей должны обеспечить выполнение следующих функций: — если чип-карта прочитана, то определяется ее идентификационный номер, который передается другим узлам системы. Исполнительный механизм «электронный замок» получает сообщение и проверяет, имеет ли данный идентификационный номер право на вход. Второй исполнительный механизм «устройство оповещения» проверяет действительность полученного идентификационного номера; — как только узел «электронный замок» проверил идентификационный номер, он посылает ответное сообщение на узел «устройство чтения чип-карт». В случае разрешения входа лицо будет допущено, в противном случае узел «устройство чтения карт» выдаст сообщение «ВХОД ВОСПРЕЩЕН»; — узел «устройство оповещения» проверяет, известен ли полученный идентификационный номер системе наблюдения за входом, и если код неизвестен, посылает сигнал тревоги на два оставшихся узла системы. После этого «устройство оповещения» подает сигнал о невозможности входа.

57

Рис. 2-6. Функционирование устройства наблюдения за входом Схема распределенного приложения (Рис. 2-6) демонстрирует внешний коммуникационный интерфейс и вспомогательные функции аппаратного обеспечения. Наряду с узлами, непосредственно взаимодействующими с окружающей средой, в системе LonWorks могут быть также и узлы, не имеющие прямого соединения с датчиками или исполнительными механизмами. В их задачи входит, например, выполнение управляющих или контролирующих алгоритмов, а также диагностика состояния системы. В отличие от систем типа master-slave, ни один узел не берет на себя функции перепроверки и контроля всего распределенного приложения; вместо

58 этого управление системой и менеджмент сети осуществляют сразу несколько узлов. Эти отличительные особенности распределенной системы создают потенциал для проектирования устойчивых от сбоев и гибких приложений. Изображенное на Рис. 2-6 логическое соединение между узлами соответствует обычному представлению коммуникационного объекта LON. Стрелки внутрь и наружу обозначают объекты данных, которые могут программно изменяться и, посредством среды передачи данных, быть доступны другим узлам. Стандартное описание узлов в сети LON охватывает коммуникационный интерфейс, документацию на сами устройства (номер модели, руководство пользователя, обозначение стандартных соединений и т. д.), а также описание параметров функций, которые могут быть изменены. Подробное объяснение модели стандартного описания приводится в главе 10. Логические коммуникационные связи между узлами LON (Рис. 2-6) могут быть построены различными способами. Связь между узлами формируется благодаря внесению конфигурационных данных в адресные таблицы нейронных чипов. Логическое коммуникационное связывание LON-системы может выполняться по одному из следующих четырех сценариев: — Прединсталляция: узлы LON конфигурируются производителем заранее и вводятся в эксплуатацию на предопределенные места применения. — Самостоятельная инсталляция: при проектировании системы предусматривается ограниченный набор возможностей для конфигурации сети и распределения функций между узлами. Конкретная конфигурация (логические адреса и функции узлов) устанавливается непосредственно при вводе в эксплуатацию. — Автоматическая инсталляция: интегрированные в систему узлы сетевого менеджмента или встроенные в каждый узел инсталляционные алгоритмы «заботятся» о том, чтобы пользователь решал как можно меньше проблем при инсталляции системы. Поскольку такой способ инсталляции требует обладания большим набором сведений о системе (это необходимо для автоматизации процесса инсталляции), данный сценарий применяется только в системах LON, узлы которых поставляются J одним производителем или обладают одинаковой функциональностью. — Полевая инсталляция: конфигурация системы, а иногда и пользовательские приложения, загружаются в узел через сеть при вводе в эксплуатацию. Определение сетевых адресов и конфигурационных параметров производится на фазе планирования, причем окончательный проект будущей LonWorks-системы сохраняется в базе данных. В ходе инсталляции сохраненные конфигурационные данные загружаются из узла сетевого менеджмента в соответствующие LON-узлы. Сегодня рынок предлагает большое количество средств разработки программного обеспечения, инструментария сетевого менеджмента, средств управления и диагностики сети. Все эти средства частично или полностью поддерживают вышеописанные сценарии инсталляции. Точная классификация инструментария LON приводится в главе 13.

59

2.4. Эффективность передачи данных Часто можно достичь значительного повышения производительности распределенного приложения путем сокращения в нем количества обращений к удаленным данным. В сложной системе управления для обработки алгоритмов требуется выполнение более ста миллионов команд процессора в секунду. Распределенная система управления имеет преимущество, поскольку вычислительные процессы могут протекать параллельно на нескольких устройствах. Недостатком распределенной системы является необходимость проектирования процесса передачи данных между распределенными компонентами. Передача данных в распределенной системе определяется как критическая и подверженная помехам часть. Оптимизация коммуникационного процесса в распределенной системе, как правило, связана с очень большими затратами и требует определенного know-how. Распределение данных и функций в значительной степени определяется требованиями к распределенному приложению. При проектировании системы, базирующейся на LonWorks, требуется определить необходимость локального накопления и обработки данных в узле или их непосредственной передачи соответствующему узлу. На методику проектирования LonWorks-систем серьезное влияние оказывают два фактора. Первый фактор касается затрат на накопление данных. Небольшие объемы данных, до нескольких сотен байт, могут находиться в оперативной памяти самого нейронного чипа. Расширение этого объема требует дополнительных ресурсов памяти в самом узле, а также разработки алгоритмов управления памятью. Эти затраты могут значительно повысить стоимость узла и увеличить время его проектирования. Второй ограничивающий фактор — это производительность узла. Процесс коммуникации между узлами распределенного приложения должен происходить посредством соответствующих служб. Имеющиеся способы реализации подобных приложений подтверждают необходимость большого количества универсальных коммуникационных механизмов систем управления. Между узлами распределенной системы управления существуют многочисленные коммуникационные связи, которые трудно контролировать без достаточно полного инструментария. Кроме того, распределенные приложения требуют динамической модификации компонент в случае замены узла или изменения размеров системы. В языках параллельного программирования существует ряд функций для описания коммуникационных примитивов. Наиболее часто встречающиеся коммуникационные примитивы имеют форму RPC (Remote Procedure Call) или форму коммуникационных объектов прикладного уровня модели ISO/OSI. Таблица 2-2 показывает важнейшие отличительные черты языков параллельного программирования. Рассмотренные критерии сравнения охватывают виды обмена данными, параллельность коммуникационных процессов, а также механизмы обнаружения ошибок.

60 Таблица 2-2. Сравнение основных характеристик языков параллельного программирования Язык Вид обмена параллельного сообщениям программиров ания ADA [Bli91]

Концепция рандеву

Conic [MKS89]

Асинхронные сообщения, косвенная адресация Прямая адресация (протокол IP) Асинхронный обмен сообщениями, косвенная адресация (сетевые переменные) и прямая (явные сообщения) Синхронные сообщения с косвенной адресацией

JAVA [An96] Neuron С [ЕСН92]

Occam [RDP92]

Поддержка Выборочное квазипаполучение раллельных недетерминиропроцессов ванных уровней Статическое Выборочная или ссылка динамическое создание процессов Динамическое число процессов

Устойчивость к ошибкам

Обращение с исключениями

Динамическая реконфигурация

Динамическое Синхронизирова управление нные методы и приоритизация Статическое «When»-условия Проверка количество по приоритетам посланных параллельно сообщений протекающих процессов

Динамически получаемое число процессов

Конструкция ALT

программирования. Обработка ранее полученных сообщений по приоритетам поддерживается в Neuron С1 также посредством «when»-условий. В распределенных системах большое значение имеют обработка ошибок и устойчивость к ним. В некоторых языках параллельного программирования поддерживается такой механизм достижения устойчивости к ошибкам, как, например, динамическая реконфигурация устройства, обращение к исключающим условиям, а также разработка сообщений, которые могут быть посланы обратно. В LonWorks, 1

Язык программирования для LonWorks систем.

61 благодаря архитектуре LonWorks Network Services2 (LNS) [LNS96], поддерживаются механизмы повышения устойчивости к ошибкам на основе архитектуры типа клиентсервер.

2.5. Перспективы распределенных приложений Развитие распределенных на уровне датчиков — исполнительных механизмов систем в ближайшие годы, вероятно, будет определяться двумя направлениями. Распределенное управление конфигурацией. Гибкие и адаптируемые системы автоматизации требуют использования распределенных приложений с гибкой конфигурацией новыми функциями. Современные разработки интеллектуальных сетей поддерживают распределенные приложения, компоненты программного обеспечения которых могут меняться самостоятельно при вводе в эксплуатацию и при конфигурации. Эти системы содержат мигрирующие компоненты программного обеспечения, которые являются их частью в течение ограниченного времени и в определенном месте. Об исследованиях в области повышения мощности систем с миграцией данных и процессов можно узнать из [Нас89]. Интегрированная среда проектирования. Интеграция различных методов проектирования в гетерогенную системную среду будет играть в ближайшем будущем очень важную роль для распространения распределенных систем управления. Кроме того, все родственные методы разработки и унификация представления данных должны иметь форму интегрированного инструментария. Подробный обзор и библиография этой тематики представлены в [Heg93].

2

Более детальное описание см. в разделе 8.3.

62

3. Узлы LonWorks 3.1. Общий обзор Различные модификации Neuron Chip содержат почти все основные компоненты (ядро) компьютера, могут быть подключены к сети и, если к ним добавить несколько схем (Рис. 3-1), могут быть использованы в качестве независимого микроконтроллера для решения простых задач. При решении более сложных задач ядро можно расширить.

Рис. 3-1. Размещение нейронного чипа в узле LonWorks Каждый Neuron Chip, наряду с тремя микропроцессорами, содержит ROM (ПЗУ), RAM (ОЗУ), EEPROM (ППЗУ), 11-битный порт ввода/вывода, а также 5-битный коммуникационный порт для последовательной связи в сети LonTalk (Рис. 3-2). При этом только один процессор — процессор приложений (3) — непосредственно отвечает за обработку прикладных программ. Два других процессора предназначены для поддержки протокола LonTalk. Процессор (1) управляет доступом к сетевой среде (уровни 1 и 2 модели ISO/OSI); процессор (2) предназначен для обработки остальных уровней (с 3-го по 6-й).

64

3.2. Память Современные Neuron Chip, поставляемые компаниями Motorola и Toshiba, можно разделить на две основные категории. У небольших и недорогих устройств типа 3120 все функциональные блоки интегрированы в корпус SO-32 (Таблица 3-1). Внутренняя ROM объемом 10 Кбайт содержит встроенное программное обеспечение; прикладное программное обеспечение загружается в EEPROM объемом 512 байт (туда помещается только одна программа, написанная на С, размером около двух листов формата А4). Поскольку типичная прикладная программа может использовать службы, предоставляемые встроенным программным обеспечением, большую часть выполняемого кода составляют обращения к операционной системе. Однако, несмотря на это, в самой прикладной программе можно реализовать довольно большой объем функций. Более того, в EEPROM размещаются конфигурационные данные протокола LonTalk, а также, по мере необходимости, некоторые параметры пользователя. Тем самым они защищаются от потери при выключении питания. В связи с этим часть EEPROM является зарезервированной, и прикладная программа не может занимать весь доступный в EEPROM объем памяти.

Рис. 3-2. Блок-схема чипа Neuron 3150 Простейшее устройство 3120 уже содержит все необходимые элементы и должно дополняться лишь кварцевым генератором, а также специфическим для конкретного устройства портом ввода/вывода и энергообеспечением. Для использования устройства 3120 в сети LonTalk необходимо добавить к нему соответствующий трансивер. Таблица 3-1. Ресурсы памяти основных типов Neuron Chip

65 Neuron Chip

Характеристика 3150

3120

3120Е2

Объем RAM (байт)

2048

1024

2048

Объем ROM (байт)

-

10240

10240

Объем EEPROM (байт) Доступный пользователю объем EEPROM (байт)

512 413

512 418/255

2048 1949

Внешний интерфейс памяти Корпус Количество выводов

Да

Нет

Нет

PQFP 64

SOG 32

SOG 32

Предназначенный для более сложных систем чип 3150 практически идентичен 3120. Однако, благодаря корпусу PQFP-64, в нем предусмотрен внешний интерфейс памяти с двунаправленной 2-битной шиной данных и 16-битной шиной адреса. В общей сложности к нему можно подключить 58 Кбайт памяти, оставшиеся 6 Кбайт адресов резервируются для внутреннего использования. 16 Кбайт из 58 занимает встроенное программное обеспечение, которое в этом случае должно предоставляться извне, например, в виде EPROM. Оставшиеся 42 Кбайт могут использоваться для прикладных программ. К шине расширения можно подключать различные элементы памяти (ROM, RAM, EPROM, EEPROM, Flash) или дополнительные отображаемые в память (memory mapped) элементы ввода/вывода. Все эти устройства поддерживают произвольную адресацию 256-байтными блоками.

66

Рис. 3-3. Распределение памяти в различных типах Neuron Chip Каждый узел LonWorks может быть снабжен различными типами памяти в четыре различные области (Рис. 3-3), причем адресное пространство может быть занято не полностью. Компилятор и компоновщик Neuron С самостоятельно размещают различные части прикладных программ в соответствующие области памяти. Благодаря устранению в чипе 3150 внутренней ROM-памяти, объем RAM, по сравнению с чипом 3120, расширен на 2 Кбайт.

67

Рис. 3-4. Добавление портов ввода/вывода по принципу memory-mapping

3.3. Порты и ввод/вывод Таблица 3-2 поясняет назначение портов Neuron Chip. Различные типы чипов (и, соответственно, формы корпусов) могут иметь не все перечисленные порты, а только некоторые из них. Стробовый сигнал /Е (Enable Clock) генерируется микросхемой 3150 для синхронизации передачи по шине. В течение второй половины цикла доступа к памяти сигнал находится в состоянии low и тем самым показывает, что 3150 считывает и записывает данные. Управляющий вывод чтения/записи определяет направление передачи по шине данных. В момент чтения он находится в состоянии high, в момент записи — low. Различные варианты Neuron Chip обнаруживают большие различия по своим рабочим электрическим характеристикам. Таблица 3-2. Описание выводов корпуса нейронного чипа Линия I/O Функции CLK1

Input

CLK2

Output

/RESET

I/O (Pull-Up)

Подключение генератора тактовой частоты или внешний ввод импульсов Подключение генератора тактовой частоты (остается открытым, если в качестве внешнего ввода импульсов используется CLK1) Сброс (low-активный)

SERVICE

I/O (Pull-Up)

Сервисный контакт (вывод сигнала во время работы)

IO0 – IO3

I/O

Общие порты ввода/вывода (с возможностью источника тока 20 мА)

68 IO4 -107

I/O (Pull-Up)

IO8-IO10

I/O

D0-D7

I/O

Общие порты ввода/вывода (один можно специфицировать как вход № 1 таймера/счетчика с IO1 в качестве вывода. 104 можно использовать как вход № 2 таймера с 101 в качестве вывода) Общие порты ввода/вывода (можно использовать для последовательной коммуникации) Шина данных, например, для внешней памяти

R,/W

Output

Управляющий вывод чтения/записи для внешней памяти

/Е

Output

Управляющий вывод для внешней памяти

А15-А0

Output

Адресная шина, например, для внешней памяти

VDD

Power

Vss

Power

СРО-СР4

Сеть

Напряжение 5 В (все Vdd-выводы должны быть внешне соединены) Масса (0 В, GND, все VSs— выводы должны быть внешне соединены) Двунаправленный интерфейс коммуникации LonTalk

NC

Без внутреннего порта, не подключен Таблица 3-3 демонстрирует пример зависимости силы тока от тактовой частоты.

Интерфейс Neuron Chip включает в себя 11 портов ввода/вывода (TTL), причем порты, конфигурируемые в качестве вывода, также можно опрашивать. Комбинация стандартных аппаратных портов и функций встроенного программного обеспечения предоставляет широкие возможности для управления различными типами датчиков и исполнительных механизмов. В большинстве случаев требуется дополнительное подключение всего лишь нескольких внешних схем. Для портов IO0-IO3 на чипе можно реализовать встроенные источники питания (20 мА), с помощью портов IO4-IO7 — встроенное сопротивление типа Pull-Up.

69

Таблица 3-3. Увеличение тока чипа 3150 при различной тактовой частоте Тип чипа/тактовая Типичная Время доступа к частота сила тока памяти 3150 при 10 МГц

32 мА

3150 при 625 кГц

12 мА

3150 в Sleep-Mode

0,5 мА

90 нс

Если для какого-либо приложения недостаточно стандартных 11 портов ввода/вывода, их количество на чипе 3150 можно увеличить посредством внешней шины памяти, используя технологию отображения портов в память — memory mapping (Рис. 3-4).

3.4. Тактовый генератор и таймер Neuron Chip генерирует внутренние такты путем деления на две частоты, поступающие извне. Если для задания тактовой частоты используется генератор, встроенный в чип, то требуется подключение только одного кварцевого или керамического резонатора (Рис. 3-5). На вход CLK1 также можно подключить внешний независимый генератор. В этом случае CLK2 должен оставаться свободным. Для синхронизации бинарных тактов необходима точность 1,5% (15 000 ррm), в то время как протокол LonTalk предоставляет точность 0,02% (200 ррm). Выбор тактовой частоты определяется компромиссом между скоростью обработки/передачи данных, с одной стороны, и стоимостью памяти/декодирующей логики — с другой. Так, чипу, генерирующему тактовую частоту 5 МГц, требуется время доступа к памяти 200 нс, в то время как на частоте 10 МГц требуется значительно более дорогая память со временем доступа 90 нc. Кроме того, потребление тока в последнем случае увеличивается на 40%.

Рис. 3-5. Внешнее подключение тактовых входов на Neuron Chip

70 Каждый Neuron Chip содержит два независимых 16-битных таймера-счетчика (Рис. 36). Оба блока образуют ядро для управления процессом ввода/вывода объектов через 11-битный интерфейс, а также используются в 15 программных таймерах, доступных из Neuron С.

Рис. 3-6. Аппаратное обеспечение ввода/вывода и таймера-счетчика на Neuron Chip

3.5. Сброс, функции защиты и «спящий» режим Порт «Сброс» (Reset) имеет внутренний источник тока Линия RESET может перейти в состояние «Low» как по внешнему сигналу, так и «изнутри» самого чипа, например, с помощью: — программного обеспечения (прикладная программа или сетевое сообщение); — сигнала Timeout от схемы Watchdog; — сигнала о недопустимо низком рабочем напряжении (не все типы Neuron Chip содержат внутренний контроллер сброса). Начальное состояние сигнала Reset по-разному определяется производителями для конкретного типа Neuron Chip. Однако, как только сигнал Reset переходит в состояние «High», встроенное программное обеспечение начинает системную инициализацию и всегда отрабатывает следующую последовательность шагов: — запуск тактового генератора; — стабилизацию генератора; — инициализацию стека и внутреннее самотестирование чипа; — инициализацию вывода Service; — инициализацию различных внутренних состояний; — инициализацию внешней RAM; — расчет внутренних случайных чисел;

71 — инициализацию системной RAM; — инициализацию коммуникационных портов; — инициализацию контрольной суммы; — инициализацию секундного таймера; — инициализацию таймера. В течение фазы инициализации на всех выходах сохраняется высокое сопротивление до тех пор, пока прикладная программа не назначит им некоторое определенное состояние. Для того чтобы обеспечить детерминированное поведение чипа, необходимо при подаче рабочего напряжения держать линию Reset в состоянии «Low» до тех пор, пока напряжение не стабилизируется. При снятии рабочего напряжения Reset должен перейти в состояние «Low» прежде, чем рабочее напряжение достигнет минимально допустимого значения и прикладная программа потеряет управление. Подобные проблемы характерны для устройств с низкой стоимостью. Если во время доступа на запись к EEPROM нажать Reset, вероятность того, что только что записанные в EEPROM данные будут искажены, довольно высока. Поэтому некоторые типы Neuron Chip содержат внутренний Reset-контроллер, который распознает переход через минимально допустимое рабочее напряжение и поддерживает чип в течение некоторого времени во избежание неконтролируемой потери данных в EEPROM. Таким образом, вывод Reset выполняет следующие функции: — при подаче и снятии рабочего напряжения гарантирует определенное поведение Neuron Chip; — в случае колебаний сетевого напряжения, после его стабилизации Reset гарантирует повторный старт чипа; — если был распознан сбой системы (ошибки адресации, данных, сигнал от схемы Watchdog), предоставляет возможность повторного старта программного обеспечения; — если Reset инициируется самим чипом (например, выключается таймер схемы Watchdog или узлом было получено сообщение сетевого менеджмента Node Reset), то сообщение об этом поступает через порт Reset во внешнюю схему. Целостность внешней и внутренней памяти может проверяться на совпадение нескольких контрольных сумм как при каждом включении системы (Reset), так и непрерывно, в ходе фоновой диагностики. В новых версиях чипов пользователь может сам определить желаемый метод обработки ошибок. Neuron Chip содержит также различные регистры диагностики и статуса. Например, реализованы счетчики таких событий, как timeout, ошибка контрольной суммы, а также регистр для хранения причины последней перезагрузки (Watchdog, Reset, включение питания, сигнал программного обеспечения и т. д.).

72 Прикладная программа может перевести Neuron Chip в энергосберегающий «спящий» режим. При этом отключаются системный тактовый генератор, все таймеры и счетчики, но сохраняется вся внутренняя информация, включая содержимое RAM. Все порты ввода/вывода и сервисные контакты сохраняют свое последнее состояние. Повторное включение (пробуждение) осуществляется при изменении состояния портов ввода/вывода или через сеть, причем условия повторного включения могут задаваться программно для: — портов 104 -107 (маскируемые); — сервисного вывода (немаскируемый); — коммуникационного порта (маскируемый). После того как повторное включение распознано, запускается генератор, и, по достижении синхронизации, Neuron Chip начинает работать. 3.6. Идентификационный номер и сервисный вывод Наряду с основными элементами Neuron Chip содержит вспомогательные, которые важны при его практическом применении. Они упрощают инсталляцию, диагностику и обслуживание. Для каждого чипа изготовителем задается уникальный 48-битный идентификационный номер — Neuron ID. Он «прошивается» в EEPROM и не может быть впоследствии изменен. Гарантируется, что этот серийный номер никогда не появится дважды, то есть каждый чип можно в любое время однозначно идентифицировать. Сообщения LonTalk могут использовать Neuron ID для адресации тех узлов, чьи логические сетевые адреса еще не определены.

73

Рис. 3-7. светодиода)

Разводка

сервисных

контактов

(ввод/вывод

для

сервисного

Таблица 3-4. Значение сигналов светодиода Состояние узла Состояние светодиода Без конфигурационных данных и без Постоянно светится прикладной программы (unconfigured and applicationless) Без конфигурационных данных, но с Мигает прикладной программой Полностью сконфигурированный Не светится Сервисный вывод может управлять светодиодами на 20 мА, которые отображают текущее состояние Neuron Chip. Это позволяет производить простую диагностику без привлечения вспомогательных средств (Рис. 3-7, Таблица 3-4), что особенно необходимо в ходе инсталляции.

3.7. Программно-технические особенности Neuron Chip Каждый из трех процессоров Neuron Chip имеет свой собственный набор регистров, но все они используют общую вычислительную сеть данных и адресов, а также общую логику доступа к памяти. Передача данных между этими процессорами осуществляется через два буфера (сетевой буфер и прикладной буфер, Рис. 3-8).

74

Рис. 3-8. Варианты соединения Neuron Chip и хоста Все Neuron Chip, как правило, программируются на Neuron С. Средства тестирования и разработки также рассчитаны на этот язык. Обычно пользователю не обязательно знать, каким образом компилятор С формирует исполняемый код и как аппаратное обеспечение чипа его обрабатывает. Однако в случае необходимости компилятор может сформировать подробный протокол трансляции, содержащий ассемблерный код программы. Встроенное программное обеспечение чипа содержит определенный набор сложных и наиболее часто используемых функций. Пользователь может вызвать их непосредственно из программы на Neuron С. Все эти функции можно разделить на следующие группы: — программное обеспечение протокола LonTalk; — управляемый событиями менеджер задач; — система реального времени для объектов ввода/вывода; — различные арифметические и логические функции, а также функции преобразования. Поскольку отпадает необходимость описывать эти функции в прикладной программе, из нее генерируется очень компактный выполняемый код, который эффективно использует ресурсы и не требует большого объема памяти. Однако пользователю, имеющему определенный опыт программирования на языках низкого уровня, будет не хватать ряда возможностей, обеспечивающих прямой доступ к внутренней архитектуре процессора, в особенности это касается языковых средств обработки прерываний. В связи с этим, при решении задач обработки событий в реальном масштабе времени, нельзя рассчитывать на привычную скорость реакции и время необходимо снижать. Для программирования подобных приложений в Neuron С используют

75 встроенный в Neuron Chip диспетчер задач, который, в качестве ядра операционной системы, управляет прикладной программой. Он регистрирует события, происходящие в аппаратном и программном обеспечении, и в ответ на них активизирует определенную задачу (условие «when» прикладной программы). Однако из-за особенностей своего внутреннего алгоритма он не может прерывать текущие задачи, соответственно, время реакции на происходящие события повышается.

3.8. Соединение с хост-процессором Если некоторое приложение требует повышенной производительности или realtime обработки событий, то Neuron Chip можно соединить с другим процессором — «хост-процессором». В этом случае Neuron Chip продолжает работать в качестве коммуникационного процессора и обрабатывает протокол LonWorks, а прикладная программа выполняется на хост-процессоре. В большинстве случаев соединение процессоров осуществляется с помощью параллельной линии ввода/вывода, поддерживаемой встроенным программным обеспечением (Рис. 3-8). Для осуществления обмена данными программа должна накапливать их в прикладном буфере RAM, однако такой подход приводит к потере производительности. Для решения этой проблемы существует специальная технология, названная Microprocessor Interface Program (MIP). Существуют три основных способа физического соединения Neuron Chip и хостпроцессора: — соединение через порты ввода/вывода Neuron Chip с использованием параллельной и последовательной побитовой передачи (MIP/P50, MIP/Р20); — принцип memory mapping (для чипа 3150) с использованием адресного порта, портов данных и управления шиной (Рис. 3-4) совместно с двухпортовой RAM и семафорами (MIP/DPS), что сокращает непроизводительные затраты CPU-3 и поэтому еще более эффективен; — соединение через последовательный интерфейс (универсальный асинхронный приемопередатчик, UART) Neuron Chip; этот метод является довольно медленным, но может применяться для таких универсальных компонент, как SLTA и LTS-10, используемых для связи с персональным компьютером. Вспомогательное программное обеспечение состоит из программной компоненты Для Neuron Chip и драйвера, находящегося на соответствующем хосте. Программная компонента для Neuron Chip захватывает пятый уровень протокола LonTalk и осуществляет передачу данных на хост. Чаще всего она пишется на Neuron С в виде when(reset)-yровня, не имеющих точки выхода. Если в результате ошибки на чипе будут размещены другие прикладные программы, они никогда не будут исполняться.

76 Находящийся на хосте драйвер реализует оставшиеся уровни 5, 6 и 7, на которых производится управление сетевыми переменными и обработка команд сетевого менеджмента. Основная часть драйвера пишется на С; некоторые его фрагменты, связанные с организацией прерываний, таймером, аппаратной поддержкой ввода/вывода, — на Ассемблере. На сегодняшний день существуют драйверы для хостов любых классов мощности — от недорогих 8-битных микроконтроллеров до 32-битных контроллеров для персонального компьютера.

3.9. Компоненты для построения узлов LonWorks Основными компонентами узла Lon Works являются Neuron Chip, память и небольшое количество внешних схем. Кроме этого, узел содержит ряд вспомогательных компонент. Трансивер служит для физического подключения чипа к той или иной передающей среде, то есть осуществляет модуляцию и фильтрацию сигнала, а также отрабатывает элементарные функции протокола. Одним из основных преимуществ технологии LonWorks является широкий набор различных передающих сред, каждую из которых можно применять для построения сети с помощью соответствующего трансивера (Таблица 3-5). Таблица 3-5. Типы трансиверов, используемые для различных сред Передающая среда Типичная скорость Примечания передачи данных EIA-485

До 1,25 Мбит/с

Витая пара (Twisted Pair) Витая пара (Twisted Pair)

78 Кбит/с 78 Кбит/с

Произвольная топология С одновременной передачей энергообеспечения (link power)

Витая пара (Twisted Pair)

До 1,25 Мбит/с

Коаксиальный кабель Силовая линия переменного тока больше 230 В Беспроводная (радо 49 — 900 МГц) Инфракрасное излучение Светопроводники

До 1,25 Мбит/с 2-10 Кбит/с

Параллельно напряжению сети

1,2 -9,6 Кбит/с

Радиус действия — до 8 км

78 Кбит/с До 1,25 Мбит/с

Сетевой интерфейс — это группа компонент, которые связывают сеть LonWorks с хост-компьютером аналогично тому, как это описывалось в разделе 3.8

77 (Microprocessor Interface Program). Сетевые интерфейсы, включая драйвер, доступны для широкого спектра хостов (Таблицы 3-6, 3-7).

Таблица 3-6. Компоненты интерфейса, используемые хост-компьютерами для подключения к сети LonWorks Интерфейс к хосту Типичный хост ISA-Bus

PC

STD32-Bus

PC (на последовательном интерфейсе) или модем ОЕМ-РС (устройства, управляемые PC) PC

VME-Bus

OEM-компьютер

EXM-Bus

OEM-PC (устройства, управляемые PC)

EIA RS-232 PC-104-Bus

Таблица 3-7. Доступные драйверы для используемых хост-компьютеров Драйвер для Хост операционной системы MS-DOS

PC

UNIX

Рабочая станция

MS-Windows (так же как и DLL) MS-Windows/NT

PC

Для 8-битного микроконтроллера Для 32-битного микроконтроллера

Семейство Motorola 68HC11

PC

Семейство Motorola 683xx

78

4. Протокол LonTalk 4.1. Общие сведения Протокол коммуникации определяет методы, с помощью которых узлы сети могут обмениваться данными. При этом процесс коммуникации должен быть «прозрачен» и независим от прикладных программ, функционирующих в узлах сети. В распоряжение прикладных программам LonTalk предоставляет два различных класса объектов коммуникации1: — сетевые переменные; — явные сообщения. Объекты коммуникации размещаются в интерфейсе прикладного уровня (ИПУ) и используются стоящими иерархически выше приложениями (Рис. 4-1). Протокол, занимающий положение иерархически ниже ИПУ (LonTalk), осуществляет коммуникации между узлами. Приложение контролирует правильность выполнения обмена данными.

1

См. главу 6 книги.

80

Рис. 4-1. Коммуникация между узлами LonWorks Дополнительно к протоколам обмена данными LonTalk предоставляет протоколы для сетевого менеджмента и диагностики, гарантируя обслуживание, конфигурацию и ввод сети в эксплуатацию независимо от программ, выполняющихся узлами. Протоколы сетевого менеджмента и сетевой диагностики базируются на сеансовом уровне, используя для коммуникации функции прикладного уровня — ИПУ с прикладной задачей. Заметим, что предлагаемое описание протокола немного расходится в методах и обозначениях формализмов, применяемых в других протоколах.

4.2. Обзор протокола и терминология Протокол LonTalk разработан специально для коммуникации сетей управления, особенности которых — небольшая длина сообщения, низкая стоимость отдельного узла, многообразие физических каналов, часто небольшая полоса пропускания, низкие эксплутационные затраты, возможность установки устройств различных производителей в одной сети. Следующие разделы представляют все семь уровней модели OSI. Следует отметить, что физический уровень LonTalk не ограничивается определенной передающей средой, а определяется в зависимости от используемой передающей среды, то есть трансивера. Интерфейс трансивера подробно рассмотрен в главе 3, а также в [LONW 96].

81

4.2.1. Обзор протокола Семь уровней OSI, а также корреспондирующие уровни протокола LonTalk представлены на Рис. 4-2. Для каждого уровня указаны предоставляемые им службы. Обзор отдельных уровней и служб приводится ниже. Многообразие различных передающих сред поддерживается физическим уровнем используемых протоколов. Каждая среда требует собственного метода кодирования сигнала и доступа к шине. Например, дифференциальное манчестерское кодирование используют при проводнике типа витая пара, кодирование распределенным спектром -при передаче по сети в 230 В, частотно-импульсную модуляцию — при передаче радиосигналов. Как показано в разделе 4.4, любой из методов можно использовать на уровне 1, поддерживающем три основные службы — P_Data_Indication() (индикации данных), P_Channel_Active() (активности канала) и P_Data_Request() (запроса данных). Во избежание коллизий (predictive p-persistent CSMA) на подуровне контроля доступа к среде (MAC-Media Access Control) предоставляется множественный доступ к шине с контролем несущей и случайным временем ожидания. Уровень связи предполагает функционирование службы передачи данных без соединения между узлами (connectionless). Его функции ограничиваются составлением пакета данных и распознаванием ошибок. Распознанные ошибки посылают на вышележащий уровень для устранения. Сетевой уровень пересылает пакеты данных в пределах домена, предоставляя службу передачи данных без создания соединения. Сегментирование и сборка пакетов не обеспечиваются. Поддерживаются самообучающиеся маршрутизаторы, предусматривающие топологию типа «дерево». В отличие от них сконфигурированные таблицами коммутации и маршрутизаторы могут использоваться и в сетях с физическими петлями при условии сохранения «древовидной» топологии логических каналов. Основные задачи протокола LonTalk обрабатываются транспортными и сеансовыми уровнями. Уровень 4 объединяет: подуровень управления транзакциями (а)-для обнаружения дуплицированных пакетов и поддержки их последовательности, сервер идентификации (б) — для представления защищенного обмена данными и транспортный Уровень (в) — для представления защищенной связи типа «точка-точка» между источниками и одним или несколькими узлами назначения. Идентификацию сообщения можно использовать при всех видах адресации протокола LonTalk, за исключением широковещательной (broadcast).

82

Рис. 4-2. Модель OSI с корреспондирующими семью уровнями протокола LonTalk Для представления клиенту доступа к удаленному серверу на сеансовом уровне используют простой механизм запросов/ответов. С помощью этого механизма определяются специфические для той или иной прикладной задачи вызовы удаленных процедур (Remote Procedure Calls). В частности, протокол сетевого менеджмента LonTalk использует механизм запросов/ответов на сеансовом уровне посредством интерфейса прикладного уровня (ИПУ). Уровни представления данных и прикладной составляют основу совместимости. На прикладном уровне, где размещена система сетевых переменных, предоставляются все службы для отправки и получения сообщения. Независимое от прикладной задачи представление данных (уровень 6) делает возможным простой обмен информацией между узлами сети различных производств фирм. В режиме дифференциального манчестерского кодирования после арбитража шины (время х*2β, см. подраздел 4.5.2) посылается преамбула битовой синхронизации и со стартового бита (0) выполняется побайтовая синхронизация (Рис. 4-3). Далее следует информация о содержании кадра, адресная информация, собственно данные, 16 битов CRC и стоповый код (CV), нарушающий правило кодирования и тем самым

83 индиццрующий конец пакета. В течение времени Ыв передающей среде отсутствуют какие-либо сообщения.

Рис. 4-3. Компоненты пакета LonTalk

4.2.2. Терминология Терминология LonTalk отходит от формализмов других известных описаний протоколов, поэтому для упорядочивания понятий вносим поясняющие замечания. Простой канал

Рис. 4-4. Простой канал Простой канал — физическая среда, к которой подключены рассматриваемые узлы (Рис. 4-4).

84 Повторитель с сохранением и пересылкой (Store & Forward Repeater)

Рис. 4-5. Повторитель с сохранением и пересылкой Повторители с сохранением и пересылкой (Рис. 4-5), работающие на уровне 1, пересылают принятые пакеты данных без изменений, то есть производят их дубликат. Они могут работать в одной и той же среде (а) или использоваться для физического разделения двух сред (б). Применение нескольких повторителей может зациклить пакет (Packet Loops)2. Мост

Рис. 4-6. Мост LonTalk Мосты LonTalk (Рис. 4-6) связывают две физические среды (каналы) друг с другом. Все пакеты пересылаются от А к В и наоборот, если домен передатчика соответствует одному из двух доменов, между которыми находится мост. Маршрутизатор 2

См. также раздел 7.4.5.

85

Рис. 4-7. Маршрутизатор LonTalk Маршрутизатор LonTalk выборочно пересылает пакеты к подсети назначения. Маршрутизатор LonTalk связывает два разных множества подсетей (на Рис. 4-7 подсеть А, А’... — слева, а подсеть В, В’... — справа от маршрутизатора LonTalk). Подсеть никогда не получит выход для своих сообщений, минуя маршрутизатор. Маршрутизатор LonTalk может изменять адреса уровня 3, чтобы избежать зацикливания пакета. Шлюз

Рис. 4-8. Шлюз LonTalk Шлюз соединяет два протокола коммуникации через уровень 7. Шлюз LonTalk (Рис. 4-8) может использоваться для связи двух различных доменов.

86 Номенклатура, используемая при описании отдельных уровней модели OSI, представлена на Рис. 4-9 согласно OSI [Kern 93], а список сокращений для обозначения различных модулей данных протокола (Protocol Data Units) — в таблице 4-1.

Рис. 4-9. Номенклатура предоставляемых служб

Таблица 4-1. Сокращенные обозначения различных Protocol Data Unit PDU Обозначение Вид Уровень сообщения MPDU Модуль данных протокола MAC (MAC Кадр 2 Protocol Data Unit) LPDU

Модуль данных протокола связи (Link Protocol Data Unit)

Кадр

2

NPDU

Модуль данных сетевого протокола (Network Protocol Data Unit)

Пакет

3

TPDU

Модуль данных транспортного протокола (Transport Protocol Data Unit)

Сообщение

4

SPDU

Модуль данных сеансового протокола (Session Protocol Data Unit)

Запрос/ответ

5

NMPDU

Модуль данных протокола сетевого менеджмента (Network Management Protocol Data Unit) Модуль данных протокола диагностики (Diagnostic Protocol Data Unit)

-

6-7

-

6-7

Модуль данных протокола приложений (Application Protocol Data Unit)

-

6-7

DPDU APDU

87

4.3. Адресация в системе LonTalk Иерархическая структура адреса LonTalk базируется на трех основных форматах адресов с тремя компонентами (Таблица 4-2). Каждый передаваемый пакет данных содержит как адрес источника, так и адрес назначения, то есть адресные пары. Адреса LonTalk являются комбинированными адресами уровня 3 и 4, уровень 2 не имеет адреса. Используемые при маршрутизации домены и подсети обозначаются как компоненты сетевого адреса. Neuron ID, 48-битный идентификационный номер узла, соответствующий одному Neuron Chip, обозначается как имя узла и понимается как адрес уровня 4. Таблица 4-2. Три основных формата адреса в системе протокола LonTalk Формат адреса Домен, подсеть узел Домен, подсеть Neuron ID Домен, группа, член Адресная информация пакета LonTalk (Таблица 4-2) может быть различной длины, причем длина отдельного компонента, за исключением домена, является жестко установленной. Адрес подсети занимает 8 бит, что допускает 255 подсетей внутри домена (подсеть 0 зарезервирована). Под адрес узла выделено 7 бит, нулевой адрес не применяется. При 8 бит можно организовать до 256 групп в одном домене. Поле члена группы имеет длину 6 бит, a Neuron ID — 48 бит. Исключение составляет компонент «домен», который в зависимости от структуры сети может иметь длину 0, 1, 3 или 6 байт. Таким образом, в сумме может быть адресовано до (число подсетей) * (количество узлов) = (28-1) * (27-1) = 32385

узлов внутри домена, а в принципе возможно до 248 доменов. Подробное объяснение основных особенностей доменов, подсетей, узлов, групп и Neuron ID приведено в следующих разделах.

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

88 только в сфере их влияния. Длина адресного поля домена варьирует, зависит, в частности, от физической особенности структуры сети, и может составлять 0,1, 3 или 6 байт.

4.3.2. Подсети и узлы Подсеть (Subnet) объединяет некоторое количество (0-127) узлов сети в один из подмногих узлов домена, причем внутри подсети маршрутизация не выполняется. Подсети можно рассматривать как логические каналы, которые не связываются с физическими. Подсети можно связать одними физическими каналами, соединенными друг с другом повторителями или мостами. С помощью 8-битной адресной информации подсети можно задать адреса для 255 подсетей внутри домена, причем подсеть 0 представляет неопределенную или неизвестную сеть. Адресный компонент «узел» (Node) ссылается на отдельный узел внутри подсети. Один физический узел может принадлежать как максимум двум различным подсетям с различным номером узла при условии, что они находятся в разных доменах.

4.3.3. Группа, член группы Аналогично адресной информации подсети, адресный компонент «группа» (Group) объединяет узлы в группу внутри одного домена. Внутри этой группы можно идентифицировать отдельного ее члена посредством третьего адресного компонента «член» (Member). «Группа» находит применение при групповой адресации, может обозначаться как адресация типа 1-к-п и несет систему обозначений сетевых переменных. Внутри одного домена можно образовать максимум 256 групп, однако отдельный сетевой узел может принадлежать максимум 15 различным группам.

4.3.4. Neuron ID Уникальность 48-битного Neuron ID определяется при изготовлении узла и воспринимается как его имя. Neuron ID как адресная информация может быть только адресом назначения, так как структурой кадра не предусмотрено использование его в качестве адреса источника.

4.3.5. Адресация на уровне 3 При адресации NPDU основополагающие адресные форматы (Таблица 4-2) объединяются в адресные пары источник — получатель (Рис. 4-3). Каждый NPDU содержит как адрес источника, так и адрес назначения в одном из пяти вариантов: #0,

89 #1, #2а, #2Ь и #3 (Таблица 4-3). Тип #0 представляет собой широковещательную (Broadcast) адресацию с двумя различными группами назначения. Если адрес подсети 0, то все узлы внутри домена, а не только внутри подсети будут получателями сообщения. Тип #1 предназначается для групповой или множественной (Multicast) адресации. Основная форма адресации — тип #2а, называемый логической адресацией узлов подсети (Subnet-Node). #2b — множественная адресация, которая применяется для подтверждения сообщения в группах (Acknowledgement). Наконец, тип #3 — уникальная адресация по идентификатору Neuron ID в качестве адреса назначения, которая применяется преимущественно при инсталляции нового сетевого узла, пока этому узлу не присвоен логический адрес узла подсети (Subnet-Node). Таблица 4-3. NPDU/TPDU и SPDU-адресация Тип Формат Логические адресные компоненты адреса #0 #0 #1

Broadcast Domain, sourceSub-Node, destSubnet = 0 Broadcast Domain, sourceSub-Node, destSubnet Multicast Domain, sourceSub-Node, destGroup

#2а Unicast

Domain, sourceSub-Node, destSub-Node

Пункт назначения Все узлы одного домена Все узлы одной подсети Все узлы одной группы Один узел подсети

#2b Multicast Domain, sourceSub-Node, destSub-Node, Один узел подсети Group, Group Member #3 Unicast Domain, sourceSub-Node, destSub, Один узел с именем = Neuron ID Neuron ID Для всех адресных форматов адрес подсети источника равен 0, который не входит во множество значений адресов подсетей и указывает узел сети как еще не конфигурированный, не получивший логического адреса (Subnet-Node). Адресные типы #2a и #2b (Рис. 4-10) отличаются установленным или сброшенным битом Most Significant Bit в адресном поле узла-источника (SrcNode). Второй байт кадра называется заголовком NPDU (NPDU-Header). В нем двумя битами задается тип адреса (AdTyp), a следующими двумя битами — длина информации домена (длина). Адресная информация, содержащаяся в остальных байтах (Таблица 4-3), незначительно варьируемая по длине идентификации домена, ставится в конец. Байт 3 содержит адрес подсети узла-источника и используется маршрутизаторами при изучении структуры сети и во избежание зацикливания пакетов (Packet Loops). Вместе с адресом узлаисточника эти два поля адреса образуют адрес назначения для подтверждения пакета (Acknowledgement), его идентификации (Authentication), ответа службы запрос/ответ и распознавания и фильтрации пакетов данных, адресуемых узлу-источнику.

90

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

Рис. 4-11. Физическая топология и логическая адресация в LonTalk Логическая адресация выполняется в двух доменах. Зданию 1 соответствует домен 1, зданию 2 — домен 2. Общее освещение при входе обслуживается обоими доменами и может включаться и выключаться из обоих зданий. Внутри одного здания трафик ограничивается маршрутизатором на уровне этажа, причем различным этажам соответствуют различные адреса подсетей. Сообщения, следующие с этажа на этаж, попадают на маршрутизатор, который с участием адреса подсети назначения отправляет пакет данных получателю или отклоняет его. В здании 1 освещение коридоров организует группа 1. Группы могут выходить за пределы подсети и зоны

91 действия маршрутизатора и ограничиваются только границами домена.

4.4. Физический уровень протокола LonTalk Физический уровень LonTalk не связан с одной определенной средой передачи, он определяется видом трансиверов для различных коммуникационных сред. Об интерфейсе трансивера можно прочитать в [LONW 96]. Список трансиверов (см. [Lonm 96], а также главу 13) имеет широкий спектр — от кабельных сред до радиоволн и оптоволокна. Интерфейс физического уровня достаточно подробно описан, так что на основе публикаций можно проектировать и применять некоторые трансиверы для коммуникации по низкочастотным каналам высокого напряжения, громкоговорителей, железных дорог и т.д.

4.5. Уровень связи Уровень 2 модели OSI подразделяется в LonTalk на подуровни контроля доступа к среде (MAC) и передающий. Подуровень MAC управляет доступом к шине с приоритетами выбора и обнаружения коллизий. Множественный доступ к шине с контролем несущей и случайным временем ожидания (predictive p-persistent CSMA), устраняя коллизии, не исключает их. Передающий уровень позволяет без подтверждения обмениваться кадрами LonTalk в форме LPDU в пределах подсети, распознавать, но не устранять ошибки. Содержащие ошибки кадры опознаются циклическим кодом (CRC) и сразу же отбрасываются. Передающий уровень, кроме того, гарантирует сохранение последовательности пакетов и отвечает за формирование линейного сигнала.

4.5.1. Интерфейс с пограничными уровнями Интерфейс между подуровнем КДС и передающим уровнем, а также с пограничными уровнями (Рис. 4-12) физически реализуется с помощью трех простых служб при следующих условиях: — физическое состояние покоя трансивера — состояние энергосбережения; — вероятность битовой ошибки на уровне 2 лучше, чем 10-4 [LONTALK]; — физический уровень поддерживают три службы — P_Data_Indication(), P_Data_Request() и P_Channel_Active().

92 Коммуникация с физическим уровнем возможна в одном из двух режимов. В прямом режиме (Direct Mode) применяется дифференциальное манчестерское кодирование, в режиме специальных задач (Special Purpose Mode) передача осуществляется в двух направлениях последовательно и без кодирования. В обоих режимах при отправке рассчитывается 16-битная контрольная сумма [Swee 91], которая перепроверяется при приеме. Прием кадра (LPDU/MPDU) проводится передающим уровнем посредством P_Data_Indication()— На подуровень MAC посредством Frame_OK() сообщается только об успешном получении кадра вместе с Backlog. При отправке кадр (LPDU/MPDU) с помощью службы M_Data_Request/P_Data_Request передается сначала на подуровень MAC, а потом на физический уровень, причем передача начинается с байта или бита с высшим приоритетом.

Рис. 4-12. Интерфейс между подуровнем MAC, передающим уровнем и граничащими с ними уровнями Обнаружение коллизий хотя и поддерживается протоколом LonTalk, но в настоящее время при проектировании трансиверов не используется и поэтому здесь только упоминается3.

3

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

93

4.5.2. Способ доступа к шине В качестве способа доступа к шине LonTalk использует predictive p-persistent CSMA. Как во всех CSMA, перед отправкой кадра проверяется, не занята ли шина. Если шина активна (занята), то отправка откладывается и происходит переключение на прием. В противном случае, начинают с отправки преамбулы. Момент отправки преамбулы определяется случайным образом, причем в противоположность Ethernet не с фиксированной вероятностью р = 1, а с вероятностью 0 передача всем)

} bcast_struct; typedef struct nrnid_struct { addr_type type; unsigned domain : 1; unsigned : 7; unsigned rpt_timer : 4; unsigned retry : 4; unsigned : 4;

115 unsigned unsigned unsigned } nrnid_struct;

tx_timer

: 4;

subnet; nid [NEURON_ID_LEN];

typedef union msg_out_addr { addr_type no_address; group_struct group; snode_struct snode; nrnid_struct nrnid; bcast_struct beast; } msg_out_addr;

// // // // //

UNBOUND(0) if no address объявлена выше объявлена выше объявлена выше объявлена выше

// Typedef for 'msg_in_addr', which is the type of the field 'msg_in.addr'. typedef struct msg_in_addr { unsigned domain : 1; unsigned flex_domain : 1; unsigned format : 6; //NOT the 'addr_type' enum.INSTEAD: //0 => Broadest, 1 => Group, 2 => Subnet/Node,3 => Neuron ID struct { unsigned subnet; unsigned : 1; unsigned node : 7; } src_addr; union { unsigned bcast_subnet; unsigned group; struct { unsigned subnet; unsigned : 1; unsigned node : 7; } snode; struct { unsigned subnet; unsigned nid [NEURON_ID_LEN]; } nrnid; } dest_addr; } msg_in_addr; /* Typedef for 'resp_in_addr', which is the type of the field 'resp_in.addr'.*/ typedef struct resp_in_addr { unsigned domain : 1; unsigned flex_domain : 1; struct { unsigned subnet; unsigned is_snode : 1; // 0=>group resp, // l=>snode resp unsigned node : 7; } src_addr;

116 union { struct { unsigned subnet; unsigned : 1; unsigned node : 7; } snode; struct { unsigned subnet; unsigned : 1; unsigned node : 7; unsigned group; unsigned : 2; unsigned member : 6; } group; } dest_addr; } resp_in_addr; struct { int code; int len; int data[]; boolean authenticated; authenticated service_type service; boolean duplicate; unsigned rcvtx;

// // // //

message code length of message message data TRUE if message was

// service type used to send // this message // TRUE if msg is duplicate // index to the transaction

record msg_in_addr addr; struct { boolean priority_on; msg_tag tag; codes int code; // message code int data[]; // message data boolean authenticated; service_type service; the

// source address } msg_in; // TRUE if a priority msg // to correlate completion

// TRUE if to be authenticated // service type used to send

// message msg_out_addr dest_addr; //destination address } msg_out; struct { //struct for receiving responses int code; //message code int len; //length of message int data[]; //message data msg_in_addr addr; //source address } resp_in; struct { //struct for sending responses int code; //message code int data[]; //message data } resp_out;

Листинг 4-2. Структура данных объектов сообщений и ответов 4.9.4.2. Транзакция APDU

117

В качестве примера рассмотрим транзакцию Idempotent — множественный запрос/ответ (Рис. 4-30). Msg_alloc() резервирует буфер отсылки для сообщения. Если буфер предоставлен в распоряжение клиента, то по вызову msg_send(msg_out) данные передаются объекту msg_out. После успешной передачи приемнику посылается сообщение посредством службы msg_receive(msg_in) прикладной программы. После оценки сообщения приемник посылает ответ, для которого с помощью resp_alloc() резервируется буфер отсылки для ответа. Если буфер доступен, то по вызову resp_send(resp_out) отсылается ответ. После этой транзакции приемник должен вызвать службу msgjree(), чтобы освободить буфер приема, содержащий данные объекта msg_in, для следующих сообщений. Передатчик получает ответ от приемника, с помощью msg_completes() сообщает прикладной программе исход транзакции и передает данные ответа resp_received(resp_in). После оценки ответа отправитель снова освобождает приемный буфер командой resp_free().

118

Рис. 4-30. Диаграмма работы протокола прикладного уровня

4.10. Сетевой менеджмент и сетевая диагностика Протоколы сетевого менеджмента и сетевой диагностики (NM/ND — Network Management/Network Diagnostic) находятся на сеансовом уровне. Чтобы NM/ND были возможны, необходимо использовать принятую в LonTalk семантику. Конструкторские проработки некоторых служб NM/ND очень близки к реализации в виде аппаратного обеспечения, поэтому в этой главе есть ссылки на Neuron Chip8. За небольшим исключением, сообщения NM/ND манипулируют областью памяти узлов LonWorks. Часть служб занята обработкой полей данных, которые содержат параметры конфигурации LonWorks. Для сбора данных Neuron Chip обладает энергонезависимой EEPROM-памятью. Адреса данных конфигурации в узлах LonWorks управляются самим узлом. Если назначение адреса узла выполнено с помощью NMM (сообщения сетевого менеджмента-Network Management Messages), то узел-приемник знает, где хранятся эти данные. Абсолютные адреса в узлах должны загружаться только программами сети, чтобы к ним можно было обращаться командами Read— и Write-Memory. Прикладная задача сетевого менеджмента представляет собой распределенное 8

Детали реализации LonTalk в Neuron Chip даны в главе 5.

119 устройство по принципу клиент-сервер, причем можно задать несколько клиентов и несколько серверов. Функции сервера должны быть доступны всем узлам, в то время как функции клиента предусмотрены только для узлов сетевого менеджмента. NM/ND поддерживает следующие функции: — назначение адреса; — опрос статуса узлов и статистика узлов; — обработка таблиц маршрутизатора (конфигурированные маршрутизаторы). За некоторым исключением, функции сетевого менеджмента можно осуществить как удаленный вызов процедур через уровень сессий. Некоторые NMM различают, выполняется ли прикладная задача на Neuron Hosted Node или на Micro Processor Hosted Node. Часть структур данных Micro Processor Hosted Nodes имеют конфигурации Neuron Chip (если он используется как процессор коммуникации) и могут храниться резидентно. Для облегчения понимания отдельных служб NM/ND предлагаем обзор возможных статусов узла LonWorks, а затем структуры данных конфигурации.

4.10.1. Статус узла Узлы LonWorks могут находиться в одном из четырех рабочих состояний: — Applicationless. В узле не выполняются прикладные программы: ни одно приложение не загружено, приложение загружается, обнаружена неверная контрольная сумма с помощью Application Image; — Unconfigured. Данные конфигурации не загружены или загружаются в настоящий момент, или на их основе рассчитана неверная контрольная сумма В этой ситуации прикладная программа может решать сама, будет она выполняться или нет. — Hard-Offline. Узел принимает этот статус, если данные конфигурации загружены, а загрузка приложения не выполняется. — Configured. Нормальное рабочее состояние узла LonWorks. Приложение выполняется, подходящие данные конфигурации загружены. Статус узла можно запросить командой NDM Query Node (Network Diagnostic Message — сообщение сетевой диагностики).

120 Примечание. Конфигурированный узел может находиться в состоянии Configured или Hard-Offline. Если сконфигурированный, он может находиться в состоянии Unconfigured или Applicationless.

4.10.2. Структуры данных конфигурации

Рис. 4-31. Обзор структур данных конфигурации Данные конфигурации представлены в узлах LonWorks в виде таблиц. Они разделяются на прикладные специфические и сетевые специфические структуры данных. Прикладные специфические данные составляются на время компиляции и

121 могут измениться только тогда, когда прикладная задача будет заново откомпилирована и загружена. Сетевые специфические структуры данных содержат все параметры, которые укладывают в адресную схему LonTalk; дополнительно — данные конфигурации объектов коммуникации (сетевые переменные и связанные тэги сообщений), а также параметры протокола LonTalk, например трансивера (Рис. 4-31). Подробное описание структур данных конфигурации находится в [Lonw 96], приложении А, структуры данных Neuron Chip.

4.10.3. Разделение служб NM/ND Службы сетевого менеджмента и сетевой диагностики располагаются на сеансовом уровне. Network Management PDUs (NMPDU) и Network Diagnostic PDUs (NDPDUs) отличаются от APDU только значением бита в поле destinjype (Рис. 4-28), а также Message Code (Таблица 4-5). Предусмотренная область кода сообщения для NDPDU — 50-5F (HEX), для NMPDU — 60-73. // Определение кодов сообщения сетевого управления typedef enum NM_msg_code { NM_query_id = 0x1, NM_respond_to_query = 0x2, NM_update_domain = 0x3, №l_leave_domain = 0x4, NM_update_key = 0x5, NM_update_addr = 0x6, NM_query_addr = 0x7, NM_query_nv_cnfg = 0x8, NM_update_group_addr = 0x9, NM_query_domain = 0xA, NM_update_nv_cnfg = 0xB, NM_set_node_mode = 0xC, NM_read_memory = 0xB, NM_write_memory = 0xD, NM_checksum_recalc = 0xF, NM_install = 0x10, NM_wink = 0x10, //псевдоним для NM_install NM_memory_refresh = 0x11, NM_query_SNVT = 0x12, NM_nv_fetch = 0x13, NM_service_pin = 0xlF, } NM_msg_code;

122 // Определение кодов сообщения для диагностики сети typedef enum ND_msg_code { ND_query_status = 0xl, ND_proxy = 0x2, ND_clear_status = 0x3, ND_query_xcvr = 0x4, } ND_msg_code; //Определение смещения и масок для построения ответов и кодов ответа #define NM_opcode_base 0x60 #define NM_opcode_mask 0x1F #define NM__resp_mask 0xE0 #define NM_resp_success 0x20 #define NM_resp_failed 0x00 #define ND_opcode_base 0x50 #define ND_opcode_mask 0x0F #define ND_resp_mask 0xF0 #define ND_resp_success 0x30 #define ND_resp_failed 0x10

Листинг 4-3. Определение кода сообщения для всех NDM (сообщения СД) и NMM no [LonT 96] NMM (Network Management Message — сообщение сетевого менеджмента) распоряжается почти всеми типами служб: acknowledged, unacknowledged, unacknowledged/repeated и Request/Response. Те или иные NMM, которые используются только службами типа Request/Response, обозначены особо. Если сообщение отослано службой Request/Response, то кодом сообщения распоряжается как сообщение запроса, так и сообщение ответа. У ответа, отосланного узлом, различают Success Response и Failed Response. Код сообщения запроса и ответа NMM явно связаны: — Request Code (код ответа) = (Message Code) or (NM_opcode_base) — Message Code (код сообщения) = (Request Code) & (NM_opcode_mask) — Success Response (успешный ответ) = (Message Code)or (NM_resp_success) — Failed Response (ошибочный ответ) = (Message Code) or (NM_resp_failed) Примечание. Все связи можно понять побитно (Листинг 4-3). В последующих листингах код сообщения представлен в байте.

4.10.4. Функционирование узла LonWorks Чтобы через сеть считать содержимое таблицы домена из узла, узел-сервер делает запрос и посылает ответ на него узлу-«клиенту». Функции сервера реализуются в LonTalk узлом Lon Works независимо от прикладной задачи (Рис. 4-32).

123

Рис. 4-32. Функционирование NMM со службой запрос/ответ Если узел не конфигурирован в сеть, он не помещается в логическую иерархию сети, поэтому невозможно дать его логический адрес. В таких случаях LON предоставляет собственное NMM, сообщающее узлу 48-битный номер. Каждый узел LonWorks имеет свой 48-битный номер. В Neuron Chip этот номер называется Neuron ID — идентификатор чипа. В Neuron Chip предусмотрен собственный порт для переключателя, при обращении к которому в домен посылается свой Neuron ID в виде широковещательной передачи (Рис. 4-33, Раздел 1.10.5.3).

Рис. 4-33. Функционирование Service Pin Message

124

4.10.5. NMM как идентификатор узла С помощью NMM можно целенаправленно искать узлы, которые имеют определенные параметры. Узлы идентифицируются этим сообщением своего Neuron ID9 и Program ID. 4.10.5.1. Идентификатор запроса (Query ID) Только служба запрос/ответ Это сообщение требует от адресованных узлов идентификационные данные (48-битный Neuron ID и Program ID).

сообщить

их

При инсталляции сети это сообщение можно использовать, для ознакомления с узлами, входящими в сеть. Для этого всем узлам (широковещательная адресация) внутри домена направляется запрос Query ID, и узлы сообщают свои идентификационные данные. Посредством селектора можно различать неконфигурированные, выбранные или конфигурированные узлы. Выбранными будут узлы с флагом respond to query bit (см. также Respond to Query). Можно выбрать узлы с определенным содержимым памяти, начиная с определенного адреса (Листинг 4-4). typedef struct { enum { unconfigured selected selected_uncnfg

= 0, = 1, = 2,

// Ответ на запрос // установки // бита.

} selector; typedef struct { enum { read_only_relative config_relative } mode;

= 1, = 2,

struct query_id_request { unsigned command; nm_selector selector; nm_mode mode; unsigned address_hi; unsigned address_lo; unsigned count; unsigned data[MAX_DATA]; };

// Чтение соот. пер как Read-Only // или // таблицы конфигурации

// value = 1 // Начало необязательных полей

struct query_id_response { 9

Даже если LonTalk не реализуется в Neuron Chip, Neuron ID применяется для обозначения 48-битного номера, которым должен обладать любой узел LonWorks.

125 unsigned unsigned unsigned

command; neuron_id[6]; Program_id_string[8];

// value = 1

};

Листинг 4-4. Декларация Query ID Первый байт в Request Message определяет, к каким узлам выставляется требование ответить на запрос (неконфигурированные, выбранные узлы или и те, и другие). Ответ (Response Message) всегда состоит из 6 байт Neuron ID и 8 байт Program ID.

4.10.5.2. Ответ на запрос Узлу можно сообщить, должен ли он отвечать на запрос Query ID селектором =1 или нет. С помощью NMM можно установить или стереть respond to query bit. Можно использовать эту службу как инструментарий сетевого менеджмента, представляя топологию рассматриваемой сети (Листинг 4-5). struct respond_to_query_request { unsigned command; unsigned mode; };

// value = 2 // 1=> on; 0=> off

struct respond_to_query_response { unsigned command; };

// value = 2

Листинг 4-5. Структура данных Respond to Query Сообщение-ответ (Response Message) состоит только из кода ответа (Response Code).

4.10.5.3. Сообщение сервисной кнопки (Service Pin Message) Service Pin Message — сообщение, которое, в отличие от всех других NMM, автоматически (без требования) отсылается каждым узлом Lon Works, если была нажата сервисная кнопка. Оно содержит идентификационные данные узла (Листинг 46). typedef struct { unsigned command; unsigned neuron_id[6]; unsigned id_string[8]; } NM_service_pin_msg;

// value = 31

Листинг 4-6. Декларация структуры Service Pin Message

126

4.10.6. Обработка таблиц домена Таблица домена содержит все те данные, которые необходимы для размещения узла в адресной схеме LonTalk. С помощью NMM можно обрабатывать данные таблицы домена.

4.10.6.1. Обновление домена (Update Domain) Это сообщение переписывает содержимое таблицы домена и пересчитывает контрольную сумму конфигурации: узлы включаются в сетевую иерархию, получая в качестве адреса номер домена, подсети и узла. Для каждого узла домена возможно получение разрешения на доступ в форме кодирующего ключа (Authentication Key). Если запись в таблицу выполняют посредством Update Domain, то нужно помнить, что ключевое слово передается явным текстом, и каждый, находящийся в данный момент на шине, может узнать его. Update Domain осуществляют также узлы, которые защищены от чтения/записи. struct update_domain_request { unsigned command; unsigned domain_index; unsigned id[6]; unsigned subnet; unsigned must_be_one : 1; unsigned node : 7; unsigned domain_id_len; unsigned encrypt_key[6]; }; struct update_domain_response { unsigned command;

// value = 3

//этот бит должен быть установлен в 1 // 0, 1, 3, или 6

// value = 3

Листинг 4-7. Структура данных Update Domain Request Message состоит из индекса (0 или 1) в таблице домена, следующего за отображением записи таблицы домена ([Lonw 96] — приложение А, Листинг 4-7). Важно: MSB-байт, содержащий номер узла (NODE ID), должен быть установлен!

4.10.6.2. Запрос домена (Query Domain) Используется только служба запрос/ответ Если необходимо считать запись таблицы домена, пользуются NMM «Query Domain». На запрос (Request), который состоит из индекса домена (местонахождение в

127 таблице 0 или 1), узел посылает в качестве ответа содержимое записи таблицы (Response) (Листинг 4-8). Если таблица домена указывает только один домен, а запрашивается запись для двух доменов, то узел отвечает кодом ошибок. struct query_domain_request { unsigned command; unsigned index; }; struct query_domain_response { unsigned command; unsigned domain_id[6]; unsigned subnet; unsigned node; unsigned domain_id_len; unsigned encrypt_key[6]; };

// value = 10 // Domain Index, 0 or 1

// value = 10

// 0, 1, 3, or 6

Листинг 4-8. Структура данных Query Domain-Request и Response

4.10.6.3. Покидание домена (Leave Domain) Когда Leave Domain позволяет NMM стереть запись таблицы домена, автоматически пересчитывается контрольная сумма конфигурации. Если после этого узел перестает принадлежать какому-либо домену (потеря иерархии сети), он становится неконфигурируемым, и приходится проводить его переустановку: поле domain_id_len устанавливается в FF (шестнадцатеричное) (unused), адрес подсети/узла — 0/0; Encrypt Key (ключ домена) стирается; Request Message состоит только из индекса таблицы домена (Листинг 4-9). struct leave_domain_request { unsigned command; unsigned domain_index; };

// value = 4 // 0 or 1

struct leave_domain_response { unsigned command; };

// value = 4

Листинг 4-9. Структура данных Leave Domain-Request и Response 4.10.6.4. Обновление ключа (Update Key) С помощью Update Key можно прибавить некоторую величину (инкремент) к Encrypt Key (ключу кодирования) таблицы домена. Тем самым можно изменить Encrypt Key, без передачи явного текста по сети. Request Message состоит из индекса таблицы домена (0 или 1) и поля Encrypt_Key, в котором выделен инкремент Encrypt Keys (Листинг 4-10).

128 struct update_key_request { unsigned command; unsigned domain_index; unsigned encrypt_key[6]; };

// value = 5 // 0 or 1 //Increment

struct update_key_response { unsigned command; };

// value = 5

Листинг 4-10. Структура данных Update Key-Request и Response NMM обрабатывается таким образом, даже когда узлы защищены от записи/чтения.

4.10.7. Обработка таблиц адреса Адресные таблицы могут обрабатываться поддерживаемыми сообщениями сетевого менеджмента Update Address и Query Address.

LonTalk

4.10.7.1. Обновление адреса (Update Address) Update Address переписывает запись в таблице адреса и обновляет контрольную сумму конфигурации. Записи таблиц конфигурации используются LonTalk для явной адресации сетевых переменных (NV) и явных сообщений (Explicit Messages). Для различных видов адресации LonTalk применяются различные структуры данных адресных таблиц. Request Message (Листинг 4-11) содержит индексы таблицы адресов (от 0 до 14), следующие за записью таблицы адресов. struct group_s { unsigned

fieldl;

unsigned

field2;

unsigned

field3;

unsigned

field4;

unsigned

group;

// // // // // // // // //

b7; 1, b0-b6: размер группы, 0 для huge b7 : ссылка на домен b0-b6: значение модели памяти, 0 для huge b4-b7: таймер unackd_rpt b0bЗ: счетчик повторений b4-b7: получить индекс таймера b0-bЗ: передать индекс таймера идентификационная группа

}; struct snode_s { unsigned unsigned

unsigned

type; field2;

field3;

// 1 // b7: ссылка на домен, устанавливается на //объект // b0-b6: номер узла // b4-b7: таймер unackd_rpt

129

unsigned unsigned

field4; subnet;

// b0-bЗ: счетчик повторений // b0-bЗ: передать индекс таймера // подсеть

}; struct bdcst_s { unsigned unsigned unsigned unsigned unsigned }; struct ta_s { unsigned unsigned unsigned

unsigned

type; // field2; // b7: // field3; // // field4; // subnet; //

type; ta; field3;

3 ссылка на домен, устанавливается на объект b0-b5: backlog; 0==unknown b4-b7: таймер unackd_rpt b0-bЗ: счетчик повторений b0-bЗ: передать индекс таймера подсеть

// turnaround entry // 0 // 1

field4;

// b4-b7: таймер unackd_rpt // b0-ЬЗ: счетчик повторений // b0-bЗ: передать индекс таймера

type; empty;

// 0 // 0

}; struct empty_s { unsigned unsigned };

struct update_addr_request { unsigned command; // value = 6 unsigned addr_index; // 0-14 union { struct group_s; struct snode_s; struct bdcst_s; struct ta_s; struct empty_s; } address; }; struct update_addr_response { unsigned command; // value = 6 };

Листинг 4-11. Структура данных Update Address Кодирование первого поля — union address: 0

unbound или turnaround

1

subnet_node 3 broadcast

130 >80 hex

group (размер группы с установленным MSB)

Update Address также обрабатывается, если узел защищен от чтения/записи. 4.10.7.2. Адрес запроса (Query Address) Только служба запрос/ответ Записи таблицы адресов считывает NNM Query Address. Request Message содержит указатель таблицы адресов. Response поставляет требуемую запись таблицы адреса (Листинг 4-12). usigned query_addr_request{ unsigned command; unsigned index; }; struct query_addr_response { unsigned command; union { struct group_s; struct snode_s; struct bdcst_s; struct ta_s; struct empty_s; } address; };

// value = 7 // 0-14

// value = 7

Листинг 4-12. Структура данных Query Address-Request и Response NMM обрабатывается, даже если узел защищен от чтения/записи.

4.10.8. Обработка таблиц сетевых переменных Приводим принципы обработки таблицы сетевых переменных с помощью сообщений сетевого менеджмента и считки значения переменной в сети. 4.10.8.1. Обновление конфигурации сетевых переменных (Update Net Variable Config) Это сообщение переписывает запись в таблице конфигурации сетевых переменных и обновляет контрольную сумму конфигурации. Предоставляемый селектор сетевых переменных определяет связь (Binding) с сетевой переменной другого узла, которая должна иметь тот же самый селектор. Request Message (Листинг 4-13) содержит индексй таблицы сетевых переменных (от 0 до 14), следующие за отображением записи таблицы. struct update_nv_cnfg_request {

131 unsigned command; unsigned nv_index; [unsigned long

unsigned priority unsigned unsigned unsigned unsigned unsigned unsigned

// value = 11 // 0-255 nv_indexl6; ] // optional field; 16 bit // index if nv_index == 255, // not for Neuron hosted nodes nv_priority : 1; // 1 priority, 0 no unsigned nv_direction : 1; // 1 output, 0 input NV nv_selector_hi : 6; nv_selector_lo : 8; nv_turnaround : 1; // 1 if turnaround nv_service : 2; // 0 ackd, 1 unackd_rpd, // 2 unackd nv_auth : 1; // 1 NV uses authentication nv_addr_index : 4; // 0-14

}; struct update_nv_cnfg_response { unsigned command; };

// value = 11

Листинг 4-13. Структура данных Update Network Variable Config-Request и Response Селекторы сетевых переменных могут предоставляться свободно. Однако предусмотрено, что сетевая переменная, логически не связанная с другой переменной, получает специальный селектор, для которого имеет силу: селектор = h’3FFF — Index10

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

4.10.8.2. Query Net Variable Config Только служба запрос/ответ Для считывания записи таблицы конфигурации сетевых переменных предусмотрено Query Net Variable Config. Request Message содержит индекс таблицы, Response Message — отображение записи (Листинг 4-14). struct query_nv_cnfg_request { unsigned command; // value = 8 unsigned nv_index; [ unsigned long nv indexl6; ] // optional field; 16 bit // index if nv_index == 255, // not for Neuron hosted nodes };

10

Iindex задает, в каком месте таблицы сетевых переменных находится NV.

132 struct query_nv_cnfg_response { unsigned command; unsigned nv_priority unsigned nv_direction unsigned nv_selector_hi unsigned nv_selector_lo unsigned nv_turnaround unsigned nv_service unsigned unsigned

nv_auth nv__addr_index

: : : : : :

1; 1; 6; 8; 1; 2;

: 1; : 4;

// value = 8 // 1 priority, 0 no priority // 1 output, 0 input NV

// // // // //

1 if turnaround 0 ackd, 1 unackd_rpd, 2 unackd 1 NV uses authentication 0-14

};

Листинг 4-14. Структура данных Query Net Variable Config-Request и Response Запись должна существовать в таблице сетевых переменных! Отсутствие записи приводит к ошибке.

4.10.8.3. Запрос SNVT (Query SNVT) Query SNVT служит для считывания всех тех данных, которые обозначены как Self-Identification или Self-Documentation Data [Lonw 96]. Это сообщение сетевого менеджмента поддерживается, однако, только тем узлом, прикладной процессор которого ориентирован не на Neuron Chip (Microprocessor Hosted Nodes). Привязку микропроцессора можно осуществить с помощью Microprocessor Interface Program (MIP). Чтобы считать данные SNVT узлом без MIP (Neuron Hosted Node), нужно считать область памяти узла, который нужно обработать. Для этого LonTalk предлагает сообщение сетевого менеджмента Read Memory. struct query_SNVT_request { unsigned command; unsigned offset; unsigned count; };

// value = 18 // 16 bit offset into 'P SNVT table // number of bytes to return (up to 16)

struct query_SNVT_response { unsigned command; unsigned data[count]; };

// value = 18 // return data

Листинг 4-15. Структура данных Query SNVT-Request и Response Для чтения SNVT-таблицы клиенту не нужны физические адреса данных, он задает адрес неявно с использованием Offset. Таким образом, только сервер должен знать, где находятся данные локально — начало SNVT-данных определяет: Offset = 0. Количество данных, которые следует прочитать за один раз, чтобы обработать и узлы с

133 небольшим сетевым буфером, не должно превышать 16. 4.10.8.4. Network Variable Fetch С помощью Network Variable Fetch можно считывать величину сетевой переменной по сети. Request Message содержит индекс таблицы сетевых переменных, Response Message возвращает индекс величины сетевой переменной (Листинг 4-16). struct nv_fetch_request { unsigned command; // value = 19 unsigned nv_index; // [ unsigned long nv_indexl6; ] // optional field; // 16 bit index if nv_index ==255, // not for Neuron hosted nodes }; struct nv_fetch_response { unsigned command; };

// value = 19

Листинг 4-16. Структура данных Network Variable Fetch-Request и Response Для того чтобы знать, где в таблице сетевых переменных находится необходимая сетевая переменная, недостаточно знать ее имя. Имя сетевой переменной несущественно для работы узлов LonWorks, поскольку она распознается только по селектору.

4.10.9. Обработка памяти узлов сети LonTalk поддерживает оба сообщения сетевого менеджмента — Read Memory или Write Memory — для прямого доступа к памяти. Если в память узла произведена запись с помощью Write Memory, следует обновить контрольную сумму той или иной области памяти с помощью NMM Checksum Recalculate. Чтобы избежать потерь данных EEPROMS, Memory Refresh предоставляет возможность записать их заново.

4.10.9.1. Чтение памяти (Read Memory) Только служба запрос/ответ С помощью этого сообщения сетевого менеджмента считываются данные из памяти узла, адресацию которых осуществляют тремя различными способами: — абсолютная адресация; — адресация относительно таблицы read-only; — адресация относительно таблицы конфигурации. Количество байтов, которое можно считать за один раз, задается только

134 величиной сетевого буфера узла сети. Если делается попытка считать слишком много данных за один раз, то получают сообщение об ошибке. Если узел защищен от чтения/записи, то из памяти узла нельзя считать ничего, кроме структуры Read-Only, таблицы SNVT и структуры конфигурации. Request Message состоит из одного байта, определяющего метод адресации, двух байтов, задающих смещение адреса, и одного байта, определяющего количество считываемых байтов (Листинг 4-17). Ответное сообщение содержит считанные системой данные. typedef enum { /* 0 */ /* 1 */ /* 2 */ } nm_mode ;

SOLUTE, AD_ONLY_RELATIVE, NFIG_RELATIVE,

struct read_memory_request { unsigned command; nm_mode mode; unsigned longoffset; unsigned count; }; struct read_memory_response { unsigned command; unsigned data [count]; };

// value = 13

// value = 13

Листинг 4-17. Структура данных Read Memory-Request и Response

Подход к чтению таблиц SNVT в Neuron Chip Hosted Nodes Используя сообщение сетевого менеджмента Query SNVT, считать таблицу SNVT в Neuron Hosted Node нельзя. Но ее можно считать с помощью Read Memory. Для этого сначала нужно узнать адрес таблицы SNVT, который можно найти в структуре Read-Only (Листинг 4-18). typedef struct { unsigned unsigned unsigned unsigned const unsigned unsigned unsigned const unsigned unsigned

neuron_id [NEURON_ID_LEN]; // 0xF000 // NEURON_ID_LEN is defined in model_num; //0xF006 : 4; //0xF007 minor__model_num : 4; nv_fixed_struct *nv_fixed; //0xF008 read_write_protect : 1; //0xF00A : 1; nv_count : 6; snvt_struct *snvt; //0xF00B id_string[ID_STR_LEN]; : 1;

135 unsigned unsigned unsigned

two_domains address_count

: 1; : 0; : 4; о о о

} read_only_data_struct;

Листинг 4-18. Часть структуры Read-Only По адресу 0xF00B хранится указатель таблицы SNVT. Так как тут же находится подключенная напрямую к структуре SNVT таблица дескриптора SNVT, значит, известен адрес и этой таблицы (длина структуры SNVT 5 байтов).

4.10.9.2. Запись в память (Write Memory) Write Memory позволяет производить запись непосредственно в память узла. Для адресации и количества знаков, которые можно передать за один раз, действуют те же правила, что и для Read Memory. Если запись делают в области EEPROM, то контрольную сумму таблицы конфигурации и/или прикладной задачи необходимо обновить. В некоторых случаях желательно, чтобы узел, после того как он получит новые данные, произвел переустановку, которую предусматривает поле mode (Листинг 4-19). При записи в EEPROM узла надо помнить, что запись байта требуется 10-20 мс. Чтобы избежать переустановки узла по таймеру Watchdog, необходимо подогнать максимальное количество записываемых за один раз данных к тактовой частоте узла. typedef enum { /* 0 */ /* 1 */ /* 4 */ /* 8 */ /* 9 */ /* 12 */ } nm_form;

NO_ACTION BOTH_CS_RECALC CNFG_CS_RECALC ONLY_RESET BOTH_CS_RECALC_RESET CNFG_CS_RECALC_RESET

= = = = = =

0, 1, 4, 8, 9, 0xC,

struct write_memory_request { unsigned command; // value = 14 nm_mode mode; unsigned long offset; unsigned count; nm_form form; //0: no reset, no checksum //1: recalculate both checksums //4: recalc just config checksum //8: reset //9: reset, recalc both checksums //12:reset, recalc cnfg checksums

136 unsigned

data[count];

}; struct write_memory_response { // only for non-reset writes unsigned command; // value = 14 };

Листинг 4-19. Структура данных Write Memory-Request и Response Если узел защищен от чтения/записи, то ничего, кроме таблицы конфигурации содержимого памяти узла, изменить нельзя. Request Message состоит из одного байта, определяющего Address Mode, двух байтов, смещающих адреса, одного байта, определяющего количество записываемых за один раз байт, и одного байта, который определяет действия узла после окончания записи.

Пример: обработка структуры конфигурации Конфигурационную структуру (Configuration Table) можно обработать с помощью Write Memory или Read Memory в address_mode = 2, длина этой структуры данных 25 байт. Если необходимо прочитать/записать структуру за один раз, может возникнуть проблема с сетевыми буферами узлов LonWorks, объем которых окажется недостаточным.

4.10.9.3. Перерасчет контрольной суммы Прикладные и конфигурационные данные Neuron Chip защищены только контрольной суммой. Обе структуры перепроверяются независимо друг от друга при переустановке и во время работы посредством выполняющейся в фоновом режиме программы. Если контрольная сумма неверна, то узел переустанавливается в состояние Applicationless. В том случае, если контрольная сумма конфигурации неверна, узел переходит в состояние Unconfigured. С помощью Checksum Recalculate возможно обновление контрольной суммы, причем обновляется либо только контрольная сумма конфигурации, либо последняя контрольная сумма приложения (Листинг 4-20). struct checksum_request { unsigned command; unsigned which;

// value = 15 // 1: do application and configuration // 4: do configuration only

}; struct checksum_response { unsigned command; };

// value = 15

Листинг 4-20. Структура данных Checksum Recalculate-Request и Response

137

4.10.9.4. Обновление памяти EEPROM не обладает долговременной стабильностью в отношении защиты данных, как EPROM. Естественно, такова же эффективность защиты данных чипов Neuron. Поэтому время от времени следует обновлять данные EEPROM, считывая их, чтобы сразу же снова записать на прежнее место. То же самое происходит при использовании Memory Refresh. За один раз одним вызовом службы можно обновить до 8 байт, если узел находится в режиме online. Если узел находится в состоянии offline, то можно обновить до 38 байт. При этом для Neuron Chip все равно, идет ли речь об On— или Off-Chip Memory. Если пытаются обновить область памяти, лежащую вне EEPROM, то получают Failed Response. Request Message состоит из двух байт, которые определяют сдвиг адресуемой памяти (сначала MSB), одного байта, задающего количество данных, которые нужно обновить, и одного байта, который определяет, идет ли речь об On- или Off-Chip Memory (Листинг 4-21). typedef enum { /* 0 */ /* 1 */ } nm_which;

ON_CHIP, OFF_CHIP,

struct memory_refresh_request { unsigned command; unsigned long offset; unsigned count; nm_which which; }; struct memory_refresh_response { unsigned command; };

// value = 17

// 1 => off chip, 0 => on chip

// value = 17

Листинг 4-21. Структура данных Memory Refresh-Request и Response

4.10.10. Сообщения сетевого менеджмента (NNM) для выполнения особых задач 4.10.10.1. Установить режим узла (Set Node Mode) С помощью Set Node Mode (Листинг 4-22) можно поставить узел в состояние onили offline (в чипе Neuron включается диспетчер по установке состояния) или вызвать переустановку. Дополнительно можно изменить статус узла. Если узел LonWorks находится в состоянии offline, опрос сетевых переменных отрицает возможность пересылки каких-либо данных, однако обновление сетевых

138 переменных проводится. При NV-Update, когда прикладная задача в состоянии offline, a узел снова устанавливается в состояние online, при реализации LonTalk в Neuron Chip Диспетчер начнет задачу с события nv_update_occurs (если предусмотрено). struct set_node_mode_request ( unsigned command; nm_node_mode mode; nm_node_state node_state;

// value = 12 //Optional field if mode = // CHANGE_STATE

}; struct set_node_mode_response { unsigned command; };

// value = 12

Листинг 4-22. Структура данных Set Node-Mode Request и Response Если статус узла изменяется, то можно применить службу запрос/ответ, в то время как при переустановке узла — только службы без подтверждения (unacknowledged Service). 4.10.10.2. Установление (Install)11 Не служба запрос/ответ В некоторых случаях требуется распознать узел, например визуально или акустически. Таким образом, при инсталляции сети можно отказаться от нажатия сервисных кнопок для упорядочения узла. Если узел обладает такой возможностью (Neuron Hosted Node поддерживает условие when (wink), то можно начать Install12 через сеть по команде. Для Neuron Hosted Nodes Install упорядочение состоит лишь в сообщении вызова (Листинг 4-23). struct install_msg { unsigned command; };

// value = 16

Листинг 4-23. Структура данных install_msg для Neuron Hosted Nodes Для Microprocessor Hosted Nodes возможен вариант Install с дополнительной подкомандой (Листинг 4-24). struct install_msg { unsigned command; unsigned subcommand;

11 12

// value =16 // 'P-Nodes only ->send service // pin data

В спецификации Neuron Chip в [lonW 95] или в [lonW 96] Install обозначается как Wink. Эта задача также выполняется в Neuron Hosted Nodes, если узел не сконфигурирован.

139 Unsigned subdata; // 'P-Nodes only — reserverd }; struct install_msg_response { unsigned command; // value = 16 union { struct service_pin_data; // if subcommand == 0 }; };

Листинг 4-24. Структура данных installjnsg для Microprocessor Hosted Nodes Примечание. В Neuron Hosted Nodes сообщение сетевого менеджмента Install применяется без помощи службы запрос/ответ. В Microprocessor Hosted Nodes такое ограничение недействительно!

4.10.10.3. Network Management Escape Code Network Management Escape Code не является сообщением сетевого менеджмента в обычном смысле, однако готовится к расширению. Для Escape Code зарезервирована величина h‘7D, применяемая вместо поля Command в типичной декларации структуры данных. Если узел принимает Escape Code, то это означает, что следующие два байта APDU являются для него расширенной командой. Этот механизм поддерживается, например, SLTA13 и PCLTA14, чтобы загружать и опрашивать специфические для продукта данные конфигурации. struct product_query_request{ unsigned command; unsigned data[2];

// code = 0x7D // Product query subcode = 0x01 // Product query command = 0x01

}; struct product_query_short_response { unsigned command; // success = 0x3D, failure = 0xlD unsigned product_ID; // product identifier }; struct product_query_complete_response { unsigned response; // success = 0x3D, failure = 0xlD unsigned product_ID; // product identifier unsigned model[2]; // model number unsigned version; // version number unsigned config; // current config or mode of device unsigned xcvr_ID // transceiver type };

Листинг 4-25. Структура данных Product Query 13 14

Serial LonTalk Adapter фирмы Echelon. Personal Computer LonTalk Adapter фирмы Echelon.

140

Если узел поддерживает расширение сообщения сетевого менеджмента, он должен обладать способностью генерировать соответствующий ответ на команду Product Query (Листинг 4-25). Все другие расширенные команды могут быть реализованы в зависимости от специфики устройства. Различают краткую (Short Response) и длинную (Complete Response) формы генерированного ответа. Листинг 4-25 представляет значения отдельных полей.

4.10.11. Сообщения сетевого менеджмента для маршрутизатора Маршрутизатор LonTalk — это обычный 2-Tor-Router15 [LonR 95] (Рис. 4-34). Как и у сообщения сетевого менеджмента Custom Nodes, сообщение сетевого менеджмента маршрутизатора (RNMM) базируется на узлах Neuron Chip.

Рис. 4-34. 2-Tor-Router Обычные маршрутизаторы построены на двух Neuron Chip16, связанных между собой портами ввода/вывода. Использование сообщения сетевого менеджмента маршрутизатора Маршрутизатор LON функционирует как обычный узел LonWorks. Он может принимать все состояния узла. Маршрутизатор полностью функционален, когда он находится в состоянии Application-Online/Configured. Все команды, которые влияют на 15 16

См. главу 7. См. главу 7.

141 таблицу маршрутизатора, принимаются только одной половиной маршрутизатора, лиш& команды Set Node Mode с OFFLINE, ONLINE и RESTART действительны для обеих половин. Если маршрутизатор находится в состоянии ONLINE, это означает, что он работает, как описано в [LonR 95]. В рабочем состоянии OFFLINE все пакеты, которые адресованы маршрутизатору не напрямую, отбрасываются. Если маршрутизатором принята команда Set Node Mode как Broadcast Message, то он не реагирует на нее, поэтому маршрутизаторы должны адресоваться отдельно. Маршрутизатор может предоставить в распоряжение клиента сервисную кнопку, при нажатии которой с каждой его половины будет послано собственное сообщение с идентификационным номером длиной 48 бит.

4.10.11.1. Режим маршрутизатора С помощью Router Mode (Листинг 4-26) устанавливается рабочее состояние маршрутизатора: — Normal Operation — нормальное функционирование. Маршрутизатор работает, используя таблицы маршрутизации; — All Flood — все NPDUs внутри домена направляются дальше. В рабочем режиме таблицы маршрутизации находятся обычно в RAM. Они дополнительно защищены энергонезависимой памятью (в Neuron Chip, например, EEPROM). С помощью команды router_mode_request.mode = resume защищенные данные копируются в области RAM. struct router_mode_request { unsigned command; unsigned mode;

// value = 20 // 0: resume, l:init subnet table, // 2: mode flood

}; struct router_mode_response { unsigned command; };

// value = 20

Листинг 4-26. Структура данных Router Mode-Request и Response

4.10.11.2. Router Clear Group or Subnet Table Если необходимо стереть все записи защищенных таблиц маршрутизации (у Neuron Chip — в EEPROM) для групп и подсетей, используется сообщение сетевого менеджмента маршрутизатора. За один раз можно стереть максимум 8 записей. Структура данных для этой операции представлена в Листинге 4-27. struct router_table_clear_request {

142 unsigned unsigned

command; fieldl;

// // // //

value = 21 b7: l=group, 0=subnet b6: domain reference b0-3: index * 8

}; struct router_table_clear_response { unsigned command; };

// value = 21

Листинг 4-27. Структура данных Router Table Clear-Request и Response 4.10.11.3. Router Group or Subnet Table Download С помощью этого сообщения сетевого менеджмента маршрутизатора можно загрузить таблицы маршрутизации в энергонезависимую память RAM. Как и у сообщения сетевого менеджмента Router Clear Group or Subnet Table, число записываемых за один раз байтов ограничено восемью. Field 1 задает таблицу маршрутизации, a index — байт таблицы маршрутизации для записи данных поля table (Листинг 4-28). struct groupsubnet_table_download_request { unsigned command; // unsigned fieldl; // // // };

value = 22 b7: l=group, 0=subnet b6: domain reference b0-3: index * 8

struct groupsubnet_table_download_response { unsigned command; // value = 22 };

Листинг 4-28. Структура данных GroupSubnet Table Download-Request и Response Контрольная сумма конфигурации автоматически рассчитывается заново. 4.10.11.4. Router Group Forward Router Group Forward устанавливает Forward Flag для заданной группы специфицированного домена в таблице маршрутизации (Листинг 4-29). Контрольная сумма конфигурации автоматически рассчитывается заново. struct group_forward_request { unsigned command; unsigned fieldl; unsigned };

group;

// // // //

value = 23 b7: 1=RAM + EEPROM, 0=RAM only b6: domain reference 0-255

143 struct group_forward_response { unsigned command; };

// value = 23

Листинг 4-29. Структура данных Group Forward-Request и Response 4.10.11.5. Router Subnet Forward Router Subnet Forward позволяет установить Forward Flag для заданной подсети специфицированного домена в таблице маршрутизации (Листинг 4-30). Контрольная сумма конфигурации автоматически рассчитывается заново. struct group_forward_request { unsigned command; unsigned fieldl; unsigned

subnet;

}; struct group_forward_response { unsigned command; };

// // // //

value = 24 b7: 1=RAM + EEPROM, 0=RAM only b6: domain reference 0-255

// value = 24

Листинг 4-30. Структура данных Subnet Forward-Request и Response

4.10.11.6. Router Do Not Forward Group Router Do Not Forward Group стирает Forward Flag для заданной группы специфицированного домена в таблице маршрутизации (Листинг 4-31). Контрольная сумма конфигурации автоматически рассчитывается заново. struct group_noforward_request { unsigned command; unsigned fieldl; unsigned subnet; }; struct group_noforward_response { unsigned command; };

// // // //

value = 25 b7: 1=RAM + EEPROM, 0=RAM only b6: domain reference 0-255

// value = 25

Листинг 4-31. Структура данных Group No Forward-Request и Response

4.10.11.7. Router Do Not Forward Subnet Router Do Not Forward Subnet стирает Forward Flag для заданной подсети специфицированного домена в таблице маршрутизации (Листинг 4-32). Контрольная сумма конфигурации автоматически рассчитывается заново.

144 struct subnet_noforward_request { unsigned command; unsigned filedl; unsigned

subnet;

struct subnet_noforward_response { unsigned command; };

// // // //

value = 26 b7: 1=RAM + EEPROM, 0=RAM only b6: domain reference 0-255

// value = 26

Листинг 4-32. Структура данных Subnet No Forward-Request и Response 4.10.11.8. Router Group or Subnet Table Report Этим сообщением сетевого менеджмента маршрутизатора пользуются для чтения текущей записи таблицы маршрутизации. Request Message (Листинг 4-33) подсказывает, какую таблицу и с какого индекса нужно считать, после чего Response Message посылает необходимые данные. struct groupsubnet_table_report_request { unsigned command; // value = 27 unsigned filedl; // b7: l=group, 0=subnet // b6: domain reference unsigned subnet; // b0-3: index * 8 }; struct groupsubnet_table_report_response { unsigned command; // value = 27 };

Листинг 4-33. Структура данных GroupSubnet Table Report-Request и Response Из запрашиваемой таблицы будет послано 8 байт, включая заданный индекс. 4.10.11.9. Состояние маршрутизатора (Router Status) Маршрутизатор находится в различных рабочих и конфигурационных состояниях. Возможны следующие конфигурационные состояния маршрутизатора: — CONFIGURED — работает как конфигурированный маршрутизатор; — LEARNING — работает как обучающийся маршрутизатор; — BRIDGE — работает как мост; — BREDGE_REPEATER — работает как повторитель. Структура данных состояний маршрутизатора представлена в Листинге 4-34. struct router_status_request { unsigned command; }; struct router_status_response { unsigned command; unsigned router_cnfg;

// value = 28

// value = 28 // 0=configured,

145

unsigned

mode;

// // // //

l=unconfigured 2=bridge 3=bridge_repeater 0=normal, 2=flood

};

Листинг 4-34. Состояния маршрутизатора

4.10.11.10. Router Half Escape Code Если сообщение сетевого менеджмента или сетевой диагностики нужно передать на другую сторону маршрутизатора для обработки, то пользуются Router Half Escape Code. Имеется в виду не сообщение сетевого менеджмента в прямом смысле, а лишь байт кода (Листинг 4-35), который расположен в начале APDU. unsigned

command;

// value = 30

Листинг 4-35. Router Half Escape Code Все вызванные таким образом ответы обычно передаются клиенту.

4.10.12. Сообщения сетевой диагностики (NDM) 4.10.12.1. Запрос статуса (Query Status) С помощью Query Status текущее рабочее состояние узла LonWorks можно передать в форме статуса узла. Отосланные данные содержат статистику ошибок, информацию о переустановке, статус узла, версию имиджа системы и тип Neuron Chip. Поля error statistic, reset cause и error log можно стереть с помощью NDM Clear Status. Точное описание полей query _status_response (Листинг 4-36) находится в [Lonw 96], [LonT 96] и [Neurc 95]. struct query_status_request { unsigned command; // value = 1 }; struct query_status_response { unsigned command; // value = 1 unsigned long status_xmit_errors; unsigned long status_transaction_timeouts; unsigned long status_rcv_transaction_full; unsigned long status_lost_msgs; unsigned long status_missed_msgs; unsigned status_reset_cause; unsigned status_node_state; unsigned status_version_number; unsigned status_error_log; unsigned status_model_number; };

Листинг 4-36. Структура данных Query Status-Request и Response Query Status

146 обрабатывается независимо от установленного идентификатора.

4.10.12.2. Статус прокси (Proxy Status) Proxy Status позволяет одному узлу обратиться к другому (Рис. 4-35). Спрашивающий Узел (Client) посылает узлу (Agent Node), через который он хочет обратиться к другому узлу, NDM Proxy Command, сообщая адрес узла или узлов, которым предназначалось сообщение. Узел (Server), к которому обратились через Agent Node, отвечает промежуточному узлу Agent Node, последний затем передает ответ клиенту. Однако Proxy Command может применяться только для Status Request и Query ID (Unconfigured). Листинг 4-37 показывает структуру данных для Proxy Status.

Рис. 4-35. Обращение к узлу через Agent Node struct proxy_command { // for request message unsigned command; // value = 2 unsigned sub_command; // 0 => query id (unconfigured), // 1 => status // 2 => trnsceiver status request union { struct group_s; struct snode_s; struct bdcst_s; struct nid_s; } address; >; struct proxy_response { unsigned command; // value = 2 unsigned resp_data; // data and length are functions // of sub_command };

Листинг 4-37. Структура данных Proxy Status-Command и Response Детальное описание Proxy Status находится в [LonT 96], [Lon W95] и в [Lon W96].

147 4.10.12.3. Очистка статуса (Clear Status) Clear Status (Листинг 4-38) позволяет стереть подмножество тех данных (error statistic, reset cause and error log), которые узел посылает как ответ на NDM Query Status. Тем самым посредством этого поля можно наблюдать поведение узла в определенный момент. struct clear_status_command { unsigned command; };

// value = 3

struct clear_status_response { unsigned command; };

// value = 3

Листинг 4-38. Структура данных Clear Status-Command и Response

4.10.12.4. Query Transceiver Status Благодаря этому NDM считывается содержимое регистров статуса трансивера. Если подключенный трансивер не поддерживает регистр статуса, то вернется сообщение ошибке Failed-Response. struct query_xcvr_status_command { unsigned command; };

// value = 4

struct query_xcvr_status_response { unsigned command; unsigned data[7]; };

// value = 4 // register values

Листинг 4-39. Структура данных Query Transceiver Status-Command и Response Независимо от того, сколько регистров статуса имеет трансивер (по край один), в ответе будет пересылаться всегда 7 байтов.

4.11. Формат кадра LonTalk Обзор форматов различных кадров LonTalk представлен на рис. 4-36.

148

Рис. 4-36. Формат кадра LonTalk Число поверх поля задает длину поля. Величина под полем специфицирует содержимое поля. При отсылке начинают с самого значащего бита (бит 7). Точно так же сначала будет отослан байт. Информацию о различных PDU можно прочитать в соответствующих разделах этой главы. Все TPDUs приведены на рис. 4-21, SPDUs — на рис. 4-26, AuthPDU — на рис. 4-24 и APDU — на рис. 4-28 и поясняются сопровождающим текстом.

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

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

5.1.1. Архитектура трех процессоров Центральное процессорное устройство (CPU) Neuron Chip состоит из трех связанных, работающих по стековому принципу одноадресных машин с общим арифметико-логическим устройством (ALU), общей памятью, но с разделенным набором регистров. Краткое введение в микропроцессорную архитектуру Neuron Chip представлено в [Lonw96] (Рис. 5-1). Три процессора имеют 8-битные регистры и называются в соответствии с выполняемыми ими задачами: процессор управления Доступом к среде (Media Access Control, MAC), сетевой процессор и процессор прикладных задач. На рис. 5-1 показаны компоненты процессоров, а также доступ по квантам времени к таким системным элементам, как ALU и совместные ресурсы1 (RAM, ROM, EEPROM, FLASH). Длина кванта времени составляет два периода такта ввода, тем самым цикл команды CPU (Minor Cycle) требует 3 µcycle, что равняется 6 1

Общие ресурсы могут быть как внутренними (RAM, ROM, EEPROM), так и внешними.

150 тактам ввода (Таблица 5-1). За исключением команд ввода/вывода, все команды процессора требуют от одного до семи минорных циклов. Подробное описание команды см. в таблице 5-3. Таблица 5-1. Различные тактовые сигналы Neuron Chip Тактовый сигнал Количество периодов генератора Такт ввода

1

µcycle

2

Минорный цикл

3*2 = 6

Три процессора образуют канал (Таблица 5-2 и Рис. 5-1). На фазе 1 в ueycle 1 находится процессор MAC, следовательно, ALU-в его распоряжении. В то же время сетевой процессор находится в Fcycle 2 и имеет доступ к памяти и элементам ввода/вывода. Процессор прикладных задач находится в Fcycle 3 и сохраняет результаты в своих регистрах. После двух периодов такта ввода, согласно таблице, начинается фаза 2, затем фаза 3, затем снова фаза 1 и т.д.

Таблица 5-2. Временное квантование трех CPU Фаза 1 Фаза 2 ФазаЗ MAC CPU

Fcycle 1

Fcycle 2

Fcycle 3

Сетевой CPU

Fcycle 3

Fcycle 1

Fcycle 2

Прикладной CPU

Fcycle 2

Fcycle 3

Fcycle 1

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

151

Рис. 5-1. Архитектура CPU Neuron Chip с активными элементами на фазе 1 Neuron Chip использует минимальный набор аппаратных компонент (только ALU и общую память), что заметно уменьшает его размеры. При этом допускается поддержка параллельной одновременной работы в многозадачном режиме без переключения между контекстами, вызывающего излишние временные затраты. Механизм обработки прерываний в этом случае не поддерживается, что делает протокол LonTalk детерминированным2 и позволяет с помощью программных циклов точно определять время и выдерживать его. Этот механизм наиболее полно используется в MAC CPU при определении формата кадра.

5.1.2. Обзор регистров CPU CPU Neuron Chip содержит две группы регистров: регистры, используемые всеми тремя процессорами, и регистры одного из трех процессоров. Адресное пространство Neuron Chip охватывает 16-битные адреса при размере слова данных в 8 бит. Все регистры, кроме регистра Base Page (базисная страница, ВР) и Instruction Pointer (указатель на инструкцию, IP), имеют длину 8 бит. Регистр Base Page (ВР) имеет длину 16 бит и определяет начало базисной страницы (см. Раздел 5.1.3). Регистр Return Stack Pointer (указатель на стек возврата, RSP) является смещением в Base Page (ВР + RSP) и указывает на конец стека данных. В регистре Top Of Stack (вершина стека, TOS) сохраняется последняя величина стека данных. Хотя содержание TOS представляет собой текущий элемент стека данных, TOS выполнен как отдельный Регистр CPU. Регистр Instruction Pointer (IP) имеет длину 16 бит и указывает на следующую команду, находящуюся в памяти. Регистр флагов содержит флаг, определяющий область значения команд IN и OUT, а также два бита 2

Детерминирована только обработка 3-6 уровней протокола внутри узла, но не коммуникация между узлом отправления и узлом назначения.

152 идентификации CPU.

Рис. 5-2. Регистры CPU в Neuron Chip Совместно используемые регистры-это 8-битный регистр Signature Analysis Register (регистр анализа подписи, SAR), используемый для генерации случайных чисел, два регистра Test And Set Register (регистры тестирования и установки TAS1, TAS2), предназначенные для поддержки системы семафоров доступа к общим ресурсам, а также регистр STOP Register (регистр остановки) для частичного выключения CPU (перевода его в «спящий» режим).

5.1.3. Модель базисной страницы В Neuron Chip три различных процессора могут параллельно работать над тремя I различными задачами. Каждому из них соответствует своя локальная область памяти, называемая базисной страницей. В ней размещены четыре указателя, 16 локальных переменных, стек данных и стек возврата. Адрес базисной страницы находится в регистре Base Page (BP) и может быть расположен в области RAM Neuron Chip. Длина базисной страницы ограничена 256 байтами. Внутренняя адресация выполняется с помощью регистра ВР, к которому добавляется смещение. Начиная со смещения 0, располагаются 4 регистра косвенной адресации. Затем следуют 16 локальных переменных, которые копируются посредством команды PUSH в TOS и могут быть изъяты из TOS по команде POP. Стек данных начинается со смещения 24 и далее идет по возрастанию адреса. Наивысший элемент стека данных называется TOS и является регистром CPU. Элемент, находящийся ниже, обозначается как NEXT, и его адрес задается как ВР + DSP. В регистре указателя на стек возврата

153 помещаются адреса возврата после вызова подпрограмм, а также промежуточные данные; он растет от верхнего конца базисной страницы в направлении стека данных. Адрес Return-Stack задается как ВР + RSP. При программировании необходимо обращать внимание на то, чтобы область стека данных и область стека возврата увеличивались незначительно. Максимальная глубина стека возврата может оцениваться глубиной вложенности вызова подпрограмм (CALL, CALLR, CALLF). При этом следует избегать рекурсивных вызовов подпрограмм с неподдающейся оценке глубиной вложенности.

Рис. 5-3. Построение базисной страницы CPU ALU работает с величиной в регистре Top of Stack (TOS), а также с первым элементом стека данных, который обозначен как NEXT (Рис. 5-1).

5.1.4. Набор команд Neuron Chip Таблица 5-3 содержит упорядоченные по трем категориям команды Neuron Chip (команды управления, команды обработки обращений к памяти и команды ALU). Следует отметить, что перед записью в стек данных (PUSH) указатель Data-StackPointer (указатель на стек данных, DSP) инкрементируется, а после чтения по команде POP декрементируется. Количество необходимых циклов процессора задано минорными циклами.

154 Таблица 5-3. Обзор команд Neuron Chip Обозначение

Циклы

Функции Команды процессора

BR

2

Область с относительным смещением 16 бит

BRC

2

Область, если Carry = 1, с относительным смещением 16 бит

BRF

4

Удаленная область, абсолютное

BRNC

2

Область, если Carry = 0, с относительным смещением 16 бит

BRNEQ

4/6

BRNZ

4

BRZ

4

CALL

6

Область, если TOS байту данных (разветвленный/неразветвленный), с относительным смещением 16 бит, берет величину из стека при неразветвленном Область, если TOS о 0, с относительным смещением 16 бит, берет величину из стека данных Область, если TOS = 0, с относительным смещением 16 бит, берет величину из стека данных Вызов подпрограммы (с абсолютным 8-битным адресом)

CALLF

7

CALLR

5

DBRNZ

5

NOP RET

1 4

Дальний вызов подпрограммы (с абсолютным 16-битным адресом) Относительный вызов подпрограммы, вызов подпрограммы с 8-битным смещением Декрементировать указатель на стеке возврата, разветвить с относительным 16-битным смещением, если указатель о 0, в противном случае взять счетчик из Return-стека (например, счетчик цикла) Нет операции Возврат из подпрограммы

SBR

1

Короткая ветвь с относительным 8-битным смещением

SBRNZ

3

SBRZ

3

Короткая ветвь, если TOS 0, с относительным 8-битным смещением Короткая ветвь, если TOS = 0, с относительным 8-битным смещением Команды обработки памяти

ALLOC #literal 3

Резервировать #literal байты в стеке данных

DEALLOC_R #literal

Удалять #literal байты из стека данных и вернуться из подпрограммы

6

155 DROP [RSP]

2

Удалить верхний элемент стека возврата

DROP NEXT DROP TOS

2 3

IN

7+4n

LDBP addr

5

OUT

7+4n

POP !D

4

POP [DSP][D]

5

Удалить второй элемент (NEXT) стека данных Удалить верхний элемент (TOS) стека данных (NEXT => TOS) Передать заданное в TOS количество байтов п из 10 в память Загрузить в регистр Base Pointer Register 16-битную константой addr Передать заданное в TOS количество байтов Bytes п из памяти в IO Передать TOS в локальную переменную D базисной страницы TOS => [BP+DSP+D], [BP+DSP] => TOS

POP [PTR][D]

7

TOS => [Base-Page-указатель + D]

POP [PTR][TOS] POP absolute

6

NEXT => [Base-Page-указатель + TOS]

7

TOS по абсолютному адресу

POP cpureg

4

TOS => cpureg, [BP+DSP] => TOS

POPD [PTR]

6

POPPUSH

5

Загрузить 16-битный указатель (PTR = 0-3) 16-битной величиной из стека данных Pop из стека данных, Push на стек возврата

PUSH !D

4

Копировать локальную переменную D после TOS

PUSH !TOS

4

[BP+TOS] =* [BP+DSP]

PUSH #literal

4

TOS => [BP+DSP], байт данных #literal=» TOS

PUSH [DSP][D] 5

TOS => [BP+DSP], [BP+DSP+D] => TOS

PUSH [PTR][D] 7

[Base-Page-указатель + D] => TOS

PUSH [PTR][TOS] PUSH [RSP]

6

[Base-Page-указатель + TOS] => NEXT

4

TOS => [BP+DSP], [BP+RSP+1] => TOS

PUSH absolute

7

Push содержимое абсолютного адреса после TOS

PUSH cpureg

4

TOS => [BP+DSP], cpureg => TOS

PUSH TOS

3

TOS => [BP+DSP]

PUSHD literal

6

PUSHD [PTR]

6

Занести 16-битную константу в стек данных, TOS = Low Byte, NEXT = High Byte Копировать 16-битный указатель (PTR = 0-3) в стек данных

156 PUSHPOP PUSHS

5 4

Pop из Return-стека, Push на стек данных TOS => [BP+DSP], байт данных => TOS

XCH

4

TOS NEXT Команды ALU

ADC

4

Сложить TOS + NEXT + Carry => TOS, удалить NEXT

ADD

4

Сложить TOS + NEXT => TOS, удалить NEXT

ADD #literal ADD_R

3 7

AND

4

Прибавить константу #literal к TOS Сложить TOS + NEXT => TOS, удалить NEXT, вернуться из подпрограммы TOS + NEXT => TOS, удалить NEXT

AND #literal

3

Связь И константы #literal с TOS, результат в TOS

AND_R

7

DEC INC

2 2

TOS + NEXT => TOS, удалить NEXT, вернуться из подпрограммы Уменьшить TOS на 1 Увеличить TOS на 1

INC [PTR]

6

Увеличить Base-Page-указатель (0-3)

NOT

2

Получить TOS

OR

4

TOS v NEXT => TOS, удалить NEXT

OR literal

3

Отношение ИЛИ константы #literal с TOS, результат в TOS

OR_R

7

ROLC RORC

2 2

TOS v NEXT => TOS, удалить NEXT, вернуться из подпрограммы Сдвигать TOS налево по Carry Flag Сдвигать TOS направо по Carry Flag

SBC

4

Вычесть NEXT — TOS — Carry => TOS, удалить NEXT

SHL SHLA SHR SHRA

2 2 2 2

Логический сдвиг TOS налево Арифметический сдвиг TOS налево Логический сдвиг TOS направо Арифметический сдвиг TOS направо

SUB

4

XOR

4

а) вычесть NEXT — TOS => TOS, удалить NEXT б) вычесть TOS — NEXT => TOS, удалить NEXT TOS ⊕ NEXT =» TOS, удалить NEXT

157 XOR #literal

3

XOR_R

7

Исключающее ИЛИ константы #literal с TOS, результат в TOS TOS ⊕ NEXT => TOS, удалить NEXT, вернуться из подпрограммы

5.1.5. Интерфейс анализатора логики эмулятора Neuron Chip Эмулятор LonBuilder (см. главу 13) предоставляет возможность подключения анализатора логики для детального анализа выполнения программы в Neuron Chip [Lbhg95]. Расположение портов Р4 и Р5 показывает Таблица 5-4. В анализаторе логики имеются общие шины адресов и данных, а также сигнал на чтение/запись. Сигнал CLOCK соответствует половине частоты генератора, и на эмуляторе уровня 3-й модели ISO/OSI сигнал CLOCK идентичен сигналу ENABLE Neuron Chip (~E)3. IFETCH указывает на фазу FETCH команды, а оба сигнала-ID0 и IDl-при использовании кодирования (Таблица 5-5) указывают на активный в настоящее время CPU. ID0 и IDl — выходы счетчика с тремя состояниями, такты которого отсчитываются по CLOCK.

3

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

158

Таблица 5-4. Расположение POD4 логических анализаторов на эмуляторе Neuron Chip Номер сервисного Р4 сигнал P5 сигнал вывода

4 5

1

N.C.

N.C.

2

N.C.

N.C.

3

CLOCK

CLOCK

4

А15

IDl

5

А14

ID0

6

А13

N.C.

7

А12

R/~W

8 9

All А10

IGET5 N.C.

10

А9

N.C.

11 12

А8 А7

CLOCK D7

13

А6

D6

14 15

А5 А4

D5 D4

16 17

A3 А2

D3 D2

18 19

Al А0

Dl D0

20

GND

GND

POD здесь означает вход логического анализатора с 16 каналами. IGET указывает, что загружается инструкция.

159 Таблица 5-5. Счетчик с тремя состояниями указывает на активный в данный момент CPU Эмулятор LonBuilder IDl

IDO

CPU

0

0

MAC

0

1

Сетевой

1

0

Прикладной

Анализаторы логики фирмы Hewlett-Packard легко можно подключить на оба штекера эмулятора Р4 и Р5. С помощью одного из терминаторов, который входит в состав комплектующих Hewlett-Packard, подключаются логические анализаторы. Соответствие сигналов эмулятора каналам анализатора логики показано на рис. 5-4.

Рис. 5-4. Терминальный адаптер HP

160 С помощью анализатора логики можно быстрее решить возникающие проблемы и ответить на сложные вопросы функционирования Neuron Chip, при этом необходимо принимать во внимание следующие факторы: — доступ к памяти: установкой слова «триггер» на определенный адрес памяти можно распознавать желаемые и нежелаемые операции с памятью; — зависимость: с помощью условного запуска на нескольких уровнях можно целенаправленно перепроверить определенную последовательность команд при доступе к памяти; — измерение временных интервалов: если установлены два или более слов триггера, то можно определить временной интервал между событиями триггера. Если дополнительно к шине адреса и данных на анализатор логики подключить линию данных коммуникационного порта Neuron Chip, то можно измерить время, которое протекает, например, от доступа к сетевой переменной до отправки в сеть ее преамбулы.

5.2. Инсталляция микропрограммного обеспечения После запуска все три CPU Neuron Chip начинают обрабатывать команды, начиная с адреса 0x0001. Адрес 0x0000 никогда не используется, так как содержит номер версии микропрограммного обеспечения. CPU-0 (процессор управления доступом к среде, MAC CPU) начинает выполнение программы, затем следуют два других процессора. После некоторой совместно выполненной команды три CPU разветвляются и начинают инициализацию согласно флаговому регистру. Прежде чем три CPU выйдут на свои основные циклы, сетевой CPU управляет ходом начальной загрузки, MAC CPU инициализирует коммуникационный порт, а прикладной CPU — элементы ввода/вывода. Всем трем CPU выделена внутренняя, а также внешняя RAM. Механизм коммуникации внутренних CPU управляет ходом инициализации. Инициализация Neuron Chip представляет собой сложный процесс, который требует определенного времени после подключения питания до тех пор, пока микросхема не станет полностью способной к выполнению своих функций.

5.2.1. Разделение задач трех CPU Области задач трех CPU различаются как при инициализации, так и в ходе работы Neuron Chip (Рис. 5-5). Представленный анализ микропрограммного обеспечения Neuron Chip соответствует четвертой версии 3150, более поздние версии могут слегка отличаться от изложенной здесь концепции. Все три CPU стартуют с адреса 0x001 и затем разветвляются по нескольким совместно выполняемым командам. После этого производится тест внутренней RAM-

161 При этом каждому CPU ставится в соответствие определенная область памяти, которую можно протестировать. MAC CPU перепроверяет 1 и 2 таймеры/счетчики аппаратного обеспечения, а сетевой процессор производит, если нужно, процесс начальной загрузки. Затем совместно тестируется доступная внешняя память. Как только MAC CPU заканчивает инициализацию коммуникационного порта, он приступает к выполнению своего основного цикла. Так же ведет себя и сетевой процессор. После инициализации коммуникационного буфера (см. раздел 5.4.1) он переходит на главный сетевой цикл. Процессор прикладных задач инициализирует элементы ввода/вывода и переходит на главный цикл. Все CPU выполняют свои циклы задач до отключения'энергообеспечения или до следующей перезагрузки.

Рис. 5-5. Фазы инициализации трех CPU

162

5.2.2. Тестирование и инициализация RAM

Рис. 5-6. Тест внутренней RAM и инициализация базовых страниц Во время фазы запуска сетевого, прикладного и MAC CPU тестируется внутренняя область RAM. Точные адреса блоков приведены на рис. 5-5. Если при тестировании не обнаружено ошибок, то организуются три базовые страницы, при неудачном тестировании активизируется сервисный индикатор. Стартовые адреса базисных страниц, а также смещение указателя стека данных (DSP) и указателя RSP приведены на рис. 5-7.

5.2.3. Старт MAC CPU По окончании фазы инициализации (Рис. 5-6) MAC CPU вступает в фазу системного запуска, как это изображено на рис. 5-7. В это время часть коммуникационных параметров считывается из структуры config_data_struct, находящейся в области EEPROM, и запоминается в RAM.

163

Рис. 5-7. Фаза системного старта MAC CPU При наличии внешней RAM (только для типа 3150), тестируется и она. Во второй части инициализации коммуникационного порта (CommPort) определяются частота генератора и желаемая частота такта сдвигающего регистра, которые загружаются как коммуникационные параметры в порт. При выборе специального режима загружаются соответствующие регистры и выбирается режим определения коллизий (CD). Для обмена данными между памятью и коммуникационным портом используются быстрые команды ввода/вывода (IN и OUT) MAC CPU. Переменные, например Backlog или счетчик коллизий, сначала инициализируются, а затем происходит ожидание, пока сетевой CPU не установит и не освободит сетевой буфер (см. раздел 5.4.1). Первые три указателя базисной страницы используются для ссылок соответственно на буферы сетевого вывода-для кадров без приоритета, Network Priority Output-для кадров с приоритетом и буфер сетевого ввода (Network Input), для чего служит стартовый адрес того или иного буфера. Тем самым завершается фаза системного запуска MAC CPU и выполняется переход на главный цикл MAC.

164

5.2.4. Старт сетевого CPU После того как была создана базисная страница сетевого CPU, начинается собственно инициализация системных ресурсов (Рис. 5-8). В стеке данных резервируются пять байт для расчета контрольной суммы. Если сохраненная и вновь вычисленная контрольные суммы не совпадают, то можно заключить, что ячейка EEPROM повреждена и Neuron Chip переходит в одно из особых состояний. После тестирования защищенной области EEPROM контрольная сумма всегда рассчитывается заново и должна запоминаться.

Рис. 5-8. Фаза системного старта сетевого CPU Если Neuron Chip запускается в первый раз или изменился его загрузочный идентификатор (ID) в ROM (3150), то выполняется начальная загрузка. Изменение загрузочного ID определяется посредством сравнения 16-битного загрузочного ГО в ROM и загрузочного ID в EEPROM по адресам 0xFlFE и 0xF1FF. Первый запуск схемы в работу можно определить с помощью чтения ячейки по адресу 0xF02D, так как при изготовлении чипа производитель определяет это значение как 0x00 или устанавливает OxFF. Адрес 0xF02D соответствует параметру COM TYPE в конфигурационной таблице и определяет тип работы коммуникационного порта. Только величина, не равная 0x00 и 0xFF, является допустимой записью для функционирующего коммуникационного порта. Можно инициировать процесс начальной загрузки целенаправленным изменением адреса 0xF02D с 0x00 с помощью команды сетевого менеджмента Write Memory и последующей переустановкой микросхемы, что позволяет моделировать состояние Neuron Chip, в котором он находится после изготовления. Сам процесс начальной загрузки у 3120 и 3150 (с внешней ROM) различен. У 3120 стандартная величина коммуникационных параметров, и таблица состояний копируется из ROM в EEPROM. Поэтому после первой подачи напряжения коммуникационный порт устанавливается на различные режимы работы со скоростью

165 передачи данных 1.25 Мбит/с. Процесс начальной загрузки 3150 копирует биты данных из внешней EPROM во внутреннюю EEPROM. Сколько и какие байты передаются, зависит от рабочего состояния чипа после выполнения начальной фазы. Если загружается микросхема без загрузки приложения, то процесс протекает так же, как и у 3120; в неконфигурированном или конфигурированном рабочем состоянии в EEPROM дополнительно копируются конфигурационная таблица или возможные программные области. Об успешном процессе начальной загрузки сообщается MAC CPU посредством коммуникационного механизма Inter-CPU. Если существует внешняя RAM, то MAC CPU тестирует относящийся к нему сегмент памяти и ожидает, пока другие CPU не закончат тест памяти. Сетевой CPU инициализирует свой указатель базисной страницы, создает коммуникационный буфер, в котором находятся все секундные таймеры. Он также сообщает о завершении своей фазы системного запуска как MAC CPU, так и прикладному CPU и переходит на главный сетевой цикл.

5.2.5. Старт прикладного CPU Аналогично MAC и сетевому CPU, процессор прикладных задач начинает системный запуск после установки своей базисной страницы, как это показано на рис. 5-9. Вначале процессор прикладных задач находится в цикле ожидания, длина которого определена 6 байтами Neuron ID. Этот процесс должен гарантировать, что не все узлы после отключения питания будут одновременно работать с полной нагрузкой и, кроме того, что регистры аппаратного обеспечения для определения случайных чисел при арбитраже шины функционируют несинхронно. Если сетевым CPU сообщается о наличии внешней памяти, то тестируется ее соответствующий сегмент. Прикладной CPU снова переводится в цикл ожидания, который прекращается только тогда, когда сетевой CPU сообщит об успешном системном запуске.

166

Рис. 5-9. Системный старт прикладного CPU Затем все три CPU заканчивают свое самотестирование и помещают его результаты по первому адресу RAM (0xE800 для 3150) (Таблица 5-6). В случае ошибки включается сервисный индикатор, код ошибки заносится в таблицу статуса узла, и узел переводится в режим Offline. С помощью сообщения сетевой диагностики Query Status можно определить статус узла. Таблица 5-6. Коды ошибок при самотестировании с их описанием Код ошибки Описание ошибки 0

Без ошибки

1

Ошибка RAM

2

Ошибка таймера/счетчика

3

Ошибка счетчика

Если в узел уже загружено приложение, то с помощью APINIT (инициализация приложения) инициализируется прикладная оболочка. Если приложение производит последовательное переключение светодиодов (flash.nc, Листинг 5-1), соответствующий сегмент кода для инициализации выглядит так, как представляют на Листинг 5-2. В

167 прикладной задаче управление миганием всех 11 светодиодов производится с помощью таймера (flashtime), вспомогательная переменная (flash) перезадает текущие состояния вводов/выводов. Нужно отметить, что переменным при их объявлении задается значение, а это требует дополнительного места в программе (Листинг 5-2). // демонстрационная программа на Neuron С // переключение 11 светодиодов, подключенных к IO0 — IO10 // flash.nc #define ON 1 #define OFF 0 #define ALL_ON 0XFF // --------------------— Декларирование ----------------------// назначение проводников ввода/вывода IO_0 output byte io_byte = OFF; // все подключены IO_8 output bit io_led_8 = OFF; IO_9 output bit io_led_9 = OFF; IO_10 output bit io_led_10 = OFF; /* переменная RAM */ boolean flash = ON; // ON: включены все LED /* Объявление таймера */ mtimer repeating flashtime; // мс счетчик повтора для переключения /* сетевые переменные */ network input unsigned int flashrate = 250; // скорость мигания в мс //---------------------Приложение------------------------when (reset) { flash = ON; flashtime = flashrate; // запуск Repeat-Timer } when (timer_expires (flashtime) ) // таймер истек { if (flash == ON) { // LED включены flash = OFF; // LED выключены io_out(io_byte, OFF); // выключены io_out(io_led_8, OFF); // выключены io_out(io_led_9, OFF); // выключены io_out(io_led_10, OFF); // выключены } // выключены else { // LEDS выключены flash = ON; // LED включены io_out(io_byte, ALL_ON); // включены io_out(io_led_8, ON); // включен io_out(io_led_9, ON); // включен io_out(io_led_10, ON); // включен } // включены }

Листинг 5-1. Программа управления светодиодами На фазе системного старта прикладным CPU вызывается подпрограмма APINIT которая в случае с flash.nc ответвляется сразу же после _FLASH_INIT и назначает

168 обеим переменным flash и flashrate их начальные величины. Листинг 5-2 показывает положение переменных в RAM, а именно их декларирования в коде Neuron С, отсортированные по порядку. После окончания инициализации прикладной CPU возвращается на фазу системного запуска (Рис. 5-9). ;Это сегмент кодов инициализирует приложение flash.nc ;(переменные, константы, объекты ввода/вывода, ...) APINIT 402f 75 40 4а brf _FLASH_INIT ;-----------------------------------------------------------------;инициализация обеих переменных RAM: flash, NV flashrate _FLASH_INIT 404a 81 push 0x01 404b d9 ff pop [1][0xff] ;[0xefff] = Variable flash = ON 404d b4 fa push 0xfa 404f d9 fe pop [1][0xfe] ;[0xeffe] = NV flashrate = 250 4051 31 ret

Листинг 5-2. Инициализация приложения flash.nc На следующих шагах фазы системного запуска определяются направления ввода/вывода и записываются данные в соответствующие порты, далее выполняется условие when(reset). Пример flash.nc кода на ассемблере содержит Листинг 5-3, где переменной flash назначена величина ON (0x01). Для запуска таймера в стек данных необходимо поместить три байта (два байта временной информации + 1 байт вида работы таймера), прежде чем сможет выполняться подпрограмма _timer_mset_repeat. ;сегмент кода условия when(reset) из flash.nc RESET ;when (reset) ;{ flash = ON; // ON = 0x01 ; flashtime = flashrate; ;} 4032 81 pushs #0x01 4033 d9 ff pop [1][Oxff] ;[efff] = flash = 0x01 4035 80 pushs #0x00 ;слово запуска таймера (High Byte) 4036 99 fe push [l][h’fe] ;Low Byte = [effe] = 250 4038 80 pushs #h’0 4039 03 fl call _timer_mset_repeat ;Starte Timer ;инициализация требует около 1.007 мс 403b 31 ret

Листинг 5-3. When( reset) из flash.nc В заключение формируется еще один указатель базисной страницы на таблицу сооь Event (раздел 5.3.3), который используется в главном цикле. При завершении прои инициализации все три CPU возвращаются в свое нормальное рабочее состояние.

169

5.3. Микропрограммное обеспечение. Режим нормальной работы После инициализации и фазы системного запуска все три CPU переходят в «нормальное состояние». MAC CPU находится в главном цикле MAC, считывая при этом поступающие по сети кадры данных и отправляя их со своей стороны. Все службы второго уровня ISO/OSI обрабатываются MAC CPU. Параллельно этому сетевой CPU находится в главном сетевом цикле и распаковывает полученные кадры данных, а также упаковывает пакеты данных, которые нужно отослать на 3-й и 6-й уровни ISO/OSI. В прикладном CPU планировщик обрабатывает события, поступающие на ввод/вывод или из сети.

5.3.1. Основной цикл MAC CPU После отработки фазы системного запуска MAC CPU переходит на точку входа (Рис. 5-10) в основной цикл MAC и пребывает там до следующей переустановки CPU. Для экономии энергии приложение по сигналу от прикладного CPU на MAC CPU может перевести чип в «спящий» режим (Sleep-Mode). При поступлении сигнала Sleep MAC CPU останавливает тактовый генератор и все три CPU. Если тактовый генератор запускается вновь (см. функцию Neuron C-Sleep), то MAC CPU деактивирует «спящий» режим. Благодаря регулярной установке таймера MAC-Watchdog предотвращается переполнение и тем самым многократная переинициализация чипа. Следующая операция определяет, можно ли отправить кадр. Если ничего отправлять не требуется, то основной цикл сокращается и, при установлении сетевой активности, принятый кадр считывается в буфер Network Input. Если отправка необходима, то выполняется проверка на активность сети. Для этого происходит переключение на прием кадра, и кадр считывается в буфер Network Input Buffer. В противном случае производится арбитраж среды. Если буфер Priority Network Output занят, то начинают с отсылки кадра с приоритетом. Для всех случаев нужно заново рассчитывать Backlog.

170

Рис. 5-10. Основной цикл MAC CPU Проход цикла в прямом режиме коммуникационного порта без какой-либо активности шины требует 58,2 Fc при частоте тактового генератора 10 МГц. Для передачи байта данных между памятью и коммуникационным портом используются команды CPU IN и OUT. Так как обе эти команды ограничены длиной передачи (максимум 255 байт), то принимать или отправлять кадры большей длины становится невозможно.

5.3.2. Основной цикл сетевого CPU Сетевой CPU по окончании фазы системного запуска также переходит на основной сетевой цикл (точка входа показана на Рис. 5-11) и пребывает в нем до следующей переустановки системы.

Рис 5-11. Основной цикл сетевого CPU Операции записи в EEPROM Neuron Chip основываются на концепции семафора: как сетевой CPU, так и прикладной CPU могут производить запись в EEPROM; запись байта требует 20 мс, и в это время ни один из CPU не может получить доступа к шине ни на чтение, ни на запись. Во избежание конфликтов производится управление доступом согласно рис. 5-12. В этом примере в качестве семафора используется область памяти 0xE8FF. Если CPUx хочет записать что-либо в EEPROM, он проверяет семафор. Значение «0» означает, что ресурс доступен; величина, не равная 0, указывает на занятость ресурса. В том случае, если запись в EEPROM не

171 производится, то CPUx устанавливает семафор равным 2 и ждет до тех пор, пока его значение не изменится на «1». CPUy (которому в данный момент времени не требуется запись в память) проверяет семафор один раз за проход основного цикла. Если его значение равно 1, то он возвращается в основной цикл. В противном случае он декрементирует семафор (2 => 1) и тем самым дает CPUx разрешение на запись в EEPROM. CPUy ждет, пока семафор примет значение 0 (с помощью CPUx) и после этого возвращается в основной цикл. В то время как CPUy ждет, CPUx может писать в EEPROM, и по окончании процесса записи CPUx освобождает CPUy посредством декрементирования семафора. Следует обратить внимание, что как CPUx, так и CPUy заблокированы как минимум на 20 мс. В качестве следующего шага в основном сетевом цикле рассчитывается новая величина для 16-битного таймера Software Tick Timer. Расчет основывается на аппаратном цикле с длительностью периода от 812.9 Fc при такте системы в 10 МГц. С помощью функции конвертирования аппаратным обеспечением перерассчитывается длительность периода 812,9 Fс при частоте 10 МГц на целые миллисекунды. Заново рассчитываются все активные таймеры программного обеспечения (Application-Timer, 1-s-Timer, Receive Transaction Timer, Transmit Timer), и заново заводятся постоянно работающие счетчики.

Рис. 5-12. Координация операции записи EEPROM с семафором [0xE8FF] Основной задачей сетевого CPU является обработка 3-6 уровней модели ISO/OSI при получении пакета данных согласно протоколу LonTalk (см. главу 4). Полученный MAC CPU кадр считывается из буфера Network Input (входной сетевой буфер) и анализируется. С уровня 3 на уровень 4 передаются только те пакеты, которые

172 адресованы узлу. В зависимости от типа используемой службы генерируется и отсылается подтверждение. Сетевой CPU обрабатывает сообщения сетевого менеджмента и сетевой диагностики: вновь поступившие сетевые переменные и явные сообщения помещаются в прикладной буфер, после чего передаются прикладному CPU. Если необходимо выполнить отправку, то сетевой CPU сначала проверяет буфер Application Priority Output (выходной буфер прикладной задачи с приоритетом), а затем Application Output (сообщения без приоритета). В обоих случаях, согласно протоколу LonTalk, 6-3 уровни модели ISO/OSI добавляют информацию к сообщению и помещают кадры в буфер Network Priority Output или в буфер Network Output Buffer для отправки посредством MAC CPU. Сетевой CPU на каждом проходе рассчитывает, исходя из информации Backlog MAC CPU, вероятность p доступа Predictive p-persistent CSMA. Далее на каждом проходе к контрольной сумме добавляется байт защищенной области EEPROM и запрашивается сервисный вывод. Работа сетевого CPU в его основном цикле составляет 256,2 Fс при частоте системного генератора 10 МГц.

5.3.3. Основной цикл прикладного CPU Вход прикладного CPU в основной цикл диспетчера задач, а также его основные функции представлены на рис. 5-13, более детальная информация приведена на рис. 5-14. В начале основного цикла вызывается функция post_events, которая завершает так называемую критическую секцию, выполняющую следующие задачи: — отсылаются выходные сетевые переменные; — принимаются входные сетевые переменные, формируется сообщение о событии; — входящие сообщения подвергаются предварительной обработке; — перепроверяется таймер программного обеспечения на переполнение; — переустанавливается таймер Watchdog прикладного CPU.

173

Рис. 5-13. Основной цикл прикладного CPU На следующем шаге перепроверяется wink-условие. Если чип получает сообщение сетевого менеджмента «wink» («моргнуть»), то это условие считается истинным и генерируется соответственный прикладной код. Если в чип поступает сообщение сетевого менеджмента Offline, выполняется Offline-условие. Если узел находится в режиме Offline, то when-условие приложения проверяется согласно рис. 513 до тех пор, пока он снова не перейдет в режим Online. Сначала перепроверяются и обрабатываются все when-условия с приоритетом. В том случае, если условие ложно, производится непосредственный переход на следующее when-условие. Если условие было истинным и была выполнена относящаяся к нему прикладная задача, то происходит разветвление основного цикла диспетчера задач. За один проход цикла после проверки всех when-условий с приоритетом можно обработать одно условие без приоритета. Независимо от того, было условие ложным или истинным, основной цикл обрабатывается начиная с условия when (wink).

174

Рис. 5-14. Обработка when-условия с приоритетом и без него Для координации различного рода событий6 диспетчер задач пользуется таблицей событий (TEVT), построение которой поясняет Таблица 5-7. Два первых байта образуют базисный адрес (BASE), и все следующие вызовы функций (Routine) выполняются относительно этого адреса. Байты 2, 3, ... являются смещением, которое должно быть прибавлено к базисному адресу для нахождения начала соответствующего места кода. Код приложения, например, для wink-условия начинается с адреса BASE + байт 2. Байт 6 задает количество when-условий с приоритетом, байт 7 — количество условий без приоритета. Блок 1 характеризует вид событий для первого when-условия. Он содержит информацию о типе события, адрес проверочного условия when, а также указатель на выводимый код. Блок 2 предоставляет подобную информацию для следующего when-условия и т.д. Для примера flash.nc из раздела 5.2.5 (Листинг 5-1) на рис. 5-15 представлена таблица событий с численными величинами. На основании базисного адреса 0x4032, находящегося в области адресов приложения, путем прибавления смещения рассчитываются все адреса. Так, например, выводимый код для when (reset) начинается с адреса 0x402D + 0x04 + 0x01 = 0x4032. Если условия (wink, offline, online) в приложении не применяются, то соответствующие им смещения устанавливаются в 0. Количество when-условий с приоритетом равно 0, без приоритета — 1.

6

Перечисление возможных событий приводится в главе 6.

175

Таблица 5-7. Построение таблицы событий планировщика (TEVT) TEVT

Событие

Байт 0,1

Базисный адрес для вызова подпрограмм (BASE)

Байт 2

Смещение для процедуры WINK

БайтЗ

Смещение для процедуры RESET

Байт 4 Байт 5

Смещение для процедуры OFFLINE Смещение для процедуры ONLINE

Байт 6

Количество when-условий с приоритетом

Байт 7

Количество when-условий без приоритета

Блок 1

1. when-условие с приоритетом

Блок 2

2. when-условие без приоритета

…

3....

Блок n

1. when-условие без приоритета

Блок n+1

2. when-условие без приоритета

…

3. ...

176

Рис. 5-15. Таблица событий для примера flash.nc Первое и единственное when-условие в flash.nc называется when (timer_expires) с соответствующей позицией кода на адресе 0x4001 + 0x01 = 0x4002. Событие timer_expires закодировано в таблице событий с адреса 0x08. Обзор всех возможных кодов событий показан в таблице 5-8, код ресурсов события для when-условия — в листинге 5-4. ; when (timer_expires) ; 1. when-условие в flashinc WHEN1 ; if-условие из flash.nc, if (flash == ON) 4002 99 ff push [l][h'ff] ; переменная flash 4004 3f dec 4005 72 14 brnz h'401b ;if (flash) == ON ;первая часть if-условия (flash == ON) 4007 80 pushs #h'0 4008 d9 ff pop [l][h'ff] ;flash = OFF: 400a 80 pushs #h'0 400b 1a 23 call _byte_output ;IO0-IO7 выключены 400d 80 pushs #h'0 400e 81 pushs #h'1 400f 1a 0f call _bit_output_hi ; IO8 выключены 4011 80 pushs #h'0 4012 82 pushs #h'2 ;IO9 выключены 4013 1a 0f call _bit_output_hi 4015 80 pushs #h'0 4016 84 pushs #h'4 4017 1a 0f call _bit_output_hi ;IO10 выключены 4019 71 13 br h'402e ;конец if-условия

177 ; вторая часть if-условия 401b 81 pushs #h'l 401c d9 ff pop [l][h'ff] 401e b4 ff push #h'ff 4020 1a 23 call _byte_output 4022 81 pushs #h'1 4023 a4 push TOS 4024 1a 0f call _bit_output_hi 4026 81 pushs #h'l 4027 82 pushs #h'2 4028 1a Of call _bit_output_hi 402a 81 pushs #h'l 402b 84 pushs #h'4 402c 1a 0f call _bit_output_hi 402e 31 ret

;flash = ON ;IO0-IO7 включен

;IO8 включен

;IO9 включен

;IO10 включен

Листинг 5-4. Ассемблерная программа первого when-условия в flash.nc Набор возможных событий диспетчера задач с соответствующими кодами событий и параметрами вызова содержит таблица 5—8. Зависимость длины блока от кода события показана на рис. 5-15. Как следует из этого рисунка, одни события не требуют параметров, другие требуют от одного до трех параметров, которые также должны содержаться в таблице событий.

Таблица 5-8. Коды событий для таблицы событий планировщика Событие

Параметр 1

Код события

Параметр 2

Параметр 3

flush_completes

00

/

/

/

logical expression

01

Смещение подготовительной процедуры

/

/

io_in_ready(..)

01

Смещение подготовительной процедуры

/

/

io_out_ready(..)

01

Смещение подготовительной процедуры

/

/

msg_arrives

02

/

/

/

msg_arrives (code)

03

msg_code

/

/

timer_expires

04

/

/

/

timer_expires(timer#)

05

timer#

/

/

178 nv_update_completes

06

#NV + no MSB (#NV=h'3F вce)

/

/

nv_update_succeeds

06

#NV + MSB (#NV=h'3F вce)

/

/

io_update_occurs

07

Смещение подготовительной процедуры

/

/

timer_expires(timer# )

08 lower 3 bit: timer #

/

/

/

io_changes(..)

lx low nibble indicates I/O-object

Смещение подготовительной процедуры

/

/

io_changes(..) by

2x. Низкий уровень означает I/O-объект

Верхний байт адресуемого значения

Нижний байт адресуемого значения

Смещение подготовитель ной процедуры

io_changes(..) to

Зх. Низкий уровень означает I/О-объект

Верхний байт адресуемого значения

Нижний байт адресуемого значения

Смещение подготовитель ной процедуры

msg_completes(..)

4х. Низкий уровень означает msg_tag (h'0F все)

/

/

/

resp_arrives(..)

5x. Низкий уровень означает msg_tag (h'0F все) 6x. Низкий уровень означает msg_tag (h'0F все) 7x. Низкий уровень означает msg_tag (h'0Fвсе) 8х. x(6bit) означает #NV (#NV=h'3FBce) Сх. x(6bit) означает #NV (#NV=h'3F вce)

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

msg_succeeds(..)

msg_fails(..)

nv_update_fails(..)

nv_update_occurs(..)

179 Изменение времени реакции между линией ввода/вывода и выходом соответствующего when-условия when (io_changes), при одном единственном whenусловии в приложении, показано на рис. 5-16.

Рис. 5-16. Временная диаграмма обработки события на порте ввода/вывода

180

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

Таблица 5-9. Таймеры программного обеспечения Neuron Chip Количество Таймер Таймер активен Максимум 16 Прикладной (мс или с) Когда запускается прикладной задачей 1

1 с таймер

Максимум 16 Receive Transaction Timer (таймер транзакций приема) 2 Transmit Timeout Timer (таймер тайм аута передачи, 1 с приоритетом, 1 без приоритета)

Постоянно Когда пакет принимается Service Type ACKD или повторяется При отсылке ACKD или повторении пакетов с приоритетом и без него

Все таймеры программного обеспечения обслуживаются сетевым CPU. Обслуживание заключается в периодическом опросе на переполнение в главном сетевом цикле, установке флагов таймера при переполнении, перезапуске счетчика повторений и остановке, если таймер больше не нужен. Запуск же прикладного таймера осуществляется прикладным CPU, и вся информация, необходимая для управления таймером, помещается в область RAM. Типичная выдержка из содержимого памяти приводится на рис. 5-17. Предположим, что информация таймера начинается с адреса 0хЕА70 (RAM). В первых двух байтах находятся 16 флагов времени, которые устанавливаются при работе соответствующих таймеров. Затем следуют 16 флагов различия секундных и миллисекундных таймеров. Один установленный флаг обозначает один миллисекундный таймер, один сброшенный флаг означает один секундный таймер. Далее следуют 16 бит таймера Transmit Timeout для отосланных пакетов с приоритетом. В зависимости от числа одновременно возможных активных транзакций приема (receive_trans_count) следует от 1 до 16 таймеров приема. Один секундный таймер запускается на фазе системного запуска сетевого CPU и работает без прерываний, от него отводятся секундные таймеры, и в завершении следуют ряд блоков

181 прикладных 4-битных таймеров. Каждый блок состоит из 16-битной величины повторений у одного периодически работающего таймера, а также текущего содержимого таймера. Если таймер проработал один раз, то величина повторений устанавливается в 0.

Рис. 5-17. Раскладка RAM при работе таймера В ходе основного сетевого цикла из текущего содержимого таймера вычитается квант времени до тех пор, пока время не истечет и таймер не будет помечен как истекший. Величина 0 в текущем содержимом таймера производит его остановку. У таймера повторения, по его истечению, загружается величина повторения, и процесс начинается сначала. В [Lonw96] для таймеров протокола LonTalk (Repeat, Transmit, Receive, Preemption) заданы таблицы перерасчета 4-битной величины (VALUE) во время. Для перерасчета также можно использовать следующие отношения.

В зависимости от вида таймера должны применяться константы (Таблица 5-10) для параметра А. Если 4-битная величина (VALUE), которую необходимо конвертировать, четная (VALUE=even), то используется верхнее отношение; если нечетная (VALUE=odd) — то нижнее. Так, например, если 4-битная величина VALUE = 4, то из верхнего уравнения выдается временная величина для таймера Transmit 0x10 * 22 = 64 мс.

182 Таблица 5-10. Параметр А для определения времени ожидания Вид таймера Параметр А A + A/2 Repeat Timer / Transmit Timer

0x10

0x18

Preemption Timer

0x02

0x03

Receive Timer

0x80

0xC0

5.4. Коммуникация Коммуникационные процессы протокола LonTalk довольно сложны, поэтому в данном разделе рассмотрены лишь некоторые основные задачи коммуникации.

5.4.1. Коммуникационный буфер Буфер является связующим звеном обмена данными между тремя CPU (Рис. 518). Поступающие в коммуникационный порт кадры записываются MAC CPU в буфер Network Input. С этого момента, если свободный сетевой буфер свободен и его величина достаточна для приема поступающих кадров, то есть все предпосылки для успешного приема кадра. Сетевой CPU считывает принятый кадр из буфера Network Input, обрабатывает 3-6-й уровни протокола LonTalk и вновь освобождает буфер Network Input. Если данные должны передаваться на прикладной CPU, то сетевой CPU использует буфер Application Input, который, как и буфер Network Input, должен быть доступным и достаточно большим. Оба этих параметра Buffersize (размер буфера) и Buffercount (количество буферов) нужно тщательно продумать при проектировании системы и программировании чипа.

Рис. 5-18. Буфер образует согласующее звено между CPU Отправка пакета данных выполняется, как это показано на рис. 5-18, в обратном порядке. Прикладной CPU передает свои данные сетевому CPU в буфер Application Output. При этом различаются пакеты с приоритетом и пакеты без приоритета, так \&,

183 как два типа выходных буферов — с приоритетом и без него. Здесь должны соблюдаться те же правила: буфер всегда должен быть доступным и достаточно большим. Сетевой CPU дополняет уходящий пакет информацией 3-6-го уровня, передает его MAC CPU для отправки в буфер Network Output с приоритетом или без него и освобождает буфер Application Output. После отправки кадра через MAC CPU сетевой CPU снова освобождает буфер Network Output.

5.4.2. Величина буфера и количество буферов Для обеспечения процесса коммуникации на достаточно высоком уровне решающим является определение правильных размеров коммуникационных буферов и их количества (Buffer count). Эти параметры можно установить в Neuron С с помощью следующих pragma-директив: — #pragma app_buf_out_size п: определяет длину прикладного буфера п в байтах для отправляемых пакетов с приоритетом и без него. — #pragma app_buf_out_count n: определяет количество доступных буферов Application Output для пакетов без приоритета. — #pragma app_buf_out_j)riority_count n: определяет количество доступных буферов Application Output для пакетов с приоритетом. — #pragma net_buf_out_size n: определяет размер п в байтах сетевого буфера для отправляемых пакетов с приоритетом и без него. Для обеспечения правильных ответов на команды сетевого менеджмента его размер должен быть не меньше чем 42 байта. — #pragma net_buf_out_count n: определяет количество доступных буферов Network Output для кадров без приоритета. — #pragma net_buf_out_priority_count n: определяет количество доступных буферов Network Output для кадров с приоритетом. — #pragma net_bufjn_size n: определяет размер п в байтах сетевого буфера для поступающих кадров. Для обеспечения правильного приема команд сетевого менеджмента его размер должен быть не меньше чем 50 байт. — #pragma net_buf_in_count n: определяет количество доступных буферов Network Input. — #pragma app_bufjn_size n: определяет длину п в байтах прикладного буфера для поступающих пакетов данных. Для обеспечения правильного приема команд сетевого менеджмента его размер должен быть не меньше чем 50 байт. — #pragma app_buf_in_count n: определяет количество доступных буферов Application Input. В принципе размер и количество буферов является задачей оптимизации доступной памяти RAM. В Neuron Chip 3120 RAM довольно ограниченна, поэтому для

184 данного типа величину и размер необходимо тщательно выбирать. В качестве эмпирического правила для расчета размера прикладного буфера справедлива следующая формула: Размер прикладного буфера (байт) = (длина сообщения +5) + [11],

причем 5 байт являются системными издержками. В случае использования явной адресации необходимо добавить еще один байт. Длина сообщения сетевой переменной — это длина сетевой переменной + 2. В качестве эмпирического правила для расчета размера сетевого буфера справедлива следующая формула: 6 байт системных издержек + 20 байт издержек протокола: Размер сетевого буфера (байт) = длина сообщения + 6 + 20.

Количество буферов зависит от различных факторов, но в качестве основы следует использовать по 2 буфера каждого типа. В большинстве случаев такой подход должен приводить к удовлетворительным результатам. В том случае, если приходится считаться с перегрузками сети или требуется пересылать большие объемы данных, количество буферов Application Output можно увеличить, для того чтобы прикладная задача всегда имела в распоряжении один свободный прикладной буфер. Для определения количества сетевых буферов необходимо знать используемые типы служб (с подтверждением, повторением, аутентификацией, запрос/ответ и т. д.) и типы адресации (unicast — одному, multicast — всем). Если используется аутентификация, необходимо увеличить число буферов Network Input, так как в этом случае происходит удвоение сетевой нагрузки. При групповой адресации с подтверждением необходимо в течение короткого времени обрабатывать большое количество поступающих кадров подтверждения. Если доступен достаточный объем RAM, то следует выбрать количество буферов Network Input по крайней мере равным размеру группы. Точное количество необходимых буферов является функцией от скорости передачи данных по сети и тактовой частоты Neuron Chip. Минимальное количество буферов определяется экспериментальным путем. Если объема RAM недостаточно и не производится отправка пакетов данных с приоритетом, то во всех случаях требуется установить равным нулю количество буферов Output с приоритетом, используя директивы языка Neuron С «#pragma app_buf_out_priority_count 0» и «#pragma net_buf_out_priority_count 0». В этом случае дополнительно определяется только буфер Transmit Transaction, и сохраняются 28 байт. Размер коммуникационного буфера описывается одним 4-битным числом. Перерасчет 4-битного кода можно выполнить либо по таблицам, приведенным в [Lonw96], либо по любой из приведенных ниже формул. Первая из них рассчитывает размер буфера в байтах по 4-битному значению поля (Field-Value, fv), вторая — количество буферов.

185

Все коммуникационные буферы размещаются в RAM. Их настройка выполняется во время фазы системного запуска сетевого CPU. Возможная организация RAM изображена на рис. 5-19. Как это описано в разделе 0, в приведенном примере таймер программного обеспечения располагается в RAM, начиная с адреса 0хЕА70. За таймером программного обеспечения следуют буферы Application Input, Application Output, Application Output Priority, Network Input, буфер Network Output Buffer, а также буфер Network Output Priority. Основная структура различных областей буферов также показана на рис. 5-19. Два первых адреса одной группы указывают на те или иные буферы того же типа. Последний указатель в этой цепочке всегда ссылается на ее начало. Обычно буферы заполняются снизу вверх. Исключение составляют буферы Network Output и Network Output Priority. Поскольку при компоновке отсылаемого кадра, согласно модели ISO/OSI, данные сначала передаются на нижние уровни, а затем дополняются там адресной информацией, то оба буфера заполняются сверху вниз. Тем самым гарантируется, что даже для адресной информации переменной длины в LonWorks всегда предусмотрено достаточное место в буфере адресной части.

186

5.4.3. Коммуникационный таймер Коммуникационный таймер управляет работой службами сообщений с подтверждениями, запрос/ответ, а также службой сообщений без подтверждений, с повторением. Для этого в распоряжении имеются следующие таймеры и счетчики: — Transmit Timer определяет временной интервал между повторениями передачи для службы с подтверждениями (ACKD) и для службы запрос/ответ (REQUEST). Если должно появиться сообщение подтверждения (ACKD) или не пришел ответ, то исходное сообщение повторяется так часто, как это задано счетчиком повторений. — Repeat Timer определяет временной интервал отсылки кадра для службы сообщений без подтверждений с повторениями (UNACKD_RPT). — Receive Timer запускается при получении нового TPDU, SPDU или AuthPDU. Если во время активности таймера Receive принимается следующий кадр с таким же адресом источника и тем же номером транзакции, то этот кадр распознается как дубликат и отбрасывается. Для распознавания дубликатов в узле-получателе комплекс приема сообщений руководствуется данными принятого кадра (адрес источника, домен, номер транзакции и т. д.). Если таймер Receive истек, то соответствующая область приема удаляется. — Счетчик повторений определяет количество повторений отправки для служб с подтверждением (ACKD), запрос/ответ (REQUEST), а также для службы сообщений без подтверждений с повторением (UNACKD_RPT). Максимальное количество отосланных сообщений = счетчик повторений + 1. Правильная установка приведенных выше счетчиков и таймеров является необходимым условием для обеспечения надежной передачи сообщений. Для счетчика повторений оказалось практичным использовать значения от 2 до 5. В принципе справедливо, что чем больше узлов назначения (например, при групповой адресации) нужно достичь, тем большая величина счетчика повторений должна выбираться. Программирование таймера Transmit зависит в основном от топологии сети. Если все узлы находятся на одном канале, то в качестве эмпирического правила справедливо [Lont96, стр. 53]: таймер Transmit > (3 * цикл пакета) + время обработки.

Цикл пакета-это то время, в течение которого он находится в канале, то есть начиная с времени β1 через арбитраж шины до нарушения кода в конце кадра. Сомножитель 3 выводится из следующих соображений: одна станция на канале должна ожидать 2 цикла пакета до тех пор, пока канал не освободится. Длина цикла пакета является функцией тактовой частоты Neuron Chip. Если речь идет не об изолированном канале и сообщение проходит через один или несколько маршрутизаторов, то нужно добавить время задержки маршрутизатора. Оно прежде всего зависит от количества буферов Network Input и Network Output на

187 обоих портах маршрутизатора, а также от используемой тактовой частоты обоих маршрутизаторов — нейронных чипов. Эмпирические измерения на маршрутизаторах LonWorks с тактовой частотой 10 МГц и стандартной установкой буферов показали время задержки около 4 мс между обоими портами А и Б. Установка таймера Receive выполняется согласно [Lont96, стр.53]: Receive таймер > Transmit таймер * (счетчик повторений + 2).

При установке обоих таймеров (Transmit и Receive) необходимо принимать во внимание то, что при использовании службы запрос/ответ, в зависимости от обстоятельств, ответное сообщение для отправителя может поступить только через относительно долгий промежуток времени. Это тот случай, когда для генерации запроса в приемнике нужно провести сложное вычисление или записать данные в EPROM (запись одного байга требует 20 мс). Все установки таймеров и счетчиков можно программировать индивидуально для каждой записи таблицы адресов. Так, у тех узлов, которые находятся на одном и том же канале, можно запрограммировать более короткое время, а у узлов, которые, с точки зрения топологии, находятся на большем расстоянии друг от друга, учесть соответствующую задержку маршрутизатора. У коммуникационных связей, которые не имеют соответствующей записи в таблице адресов (например, поступающий пакет с unicast адресацией), таймер Receive загружается величиной таймера Non-Group из конфигурационной структуры. При Multicast (групповой) адресации существует запись в таблице адресов также и для поступающих сообщений, и тем самым таймер Receive можно программировать для каждой группы. В целом, желательно переложить расчет и программирование величин таймеров на инструментарий конфигурации и инсталляции. Для небольших сетей эту задачу может взять на себя, например, LonBuilder.

188

6. Модель программирования В данной главе речь идет о важнейших элементах модели программирования, так как программа, написанная на С для Neuron СЫр, отличается от обычной программы на С.

6.1. Neuron С Язык программирования приложения для Neuron Chip (CPU-3) основывается на ANSI-C, является ответвлением языка программирования С и называется Neuron С. Он был создан для Neuron Chip и не может применяться для других процессоров. Дополнительные элементы языка предназначены специально для Neuron Chip.

Рис. 6-1. Процессоры Neuron Chip

6.1.1. Отличия от ANSI-C Neuron С не является реализацией стандарта С. В противоположность к ANSI-C, Neuron С не обладает стандартной библиотекой ввода/вывода или поддержкой «плавающей точки». Этой цели в Neuron С служат специальные библиотеки и дополнительные элементы языка, которые предназначены для функций Neuron Chip. Это особые интеллектуальные функции контроля, программные таймеры, сетевые переменные и многозадачный планировщик. Ниже перечислены важнейшие различия между Neuron С и ANSI-C. — Единственные библиотечные функции ANSI-C, которые предоставляются в распоряжение Neuron С, это тетсру() и memset(). — Neuron С не поддерживает арифметики с числами с плавающей точкой, но

190 предлагает дополнительную библиотеку для простых операций с плавающей точкой. — Neuron С содержит следующие три ANSI include файла: STDDEF.H, STDLIB.H и LIMITS.H. — Neuron С требует больше зарезервированных слов, чем ANSI-C. — Neuron С поддерживает, наряду с восьмеричными, шестнадцатеричные, а также двоичные константы. —

Neuron С требует для распознавания последовательность знаков, что и C++ (//).

комментария

такую

же

—

В Neuron С не существует функции main(). Многозадачное функционирование Neuron С достигается директивой when().

— Neuron С не поддерживает компиляцию нескольких исходных файлов, но предлагает директиву #include. — Neuron С требует использования директивы — прототипа, если функция используется прежде, чем она определяется. — Длина имени сетевой переменной Neuron С и ярлыка сообщения ограничена 16 знаками. — Единственные директивы процессора ANSI-C, которые поддерживаются Neuron С, — это: #define, #include и #ipragma. — Neuron С не поддерживает применение структур и вариантов как параметров функций или как выходного значения функции. — Neuron С не позволяет применение операторов адреса для автоматических переменных и формальных параметров функции. — Neuron С не поддерживает поля как автоматические переменные. — Невозможны: указатель на сетевые переменные, таймер, переменные EEPROM, Message Tag и объекты ввода/вывода. — Оба языка также отличаются по длине основных типов данных, что показано в следующем разделе.

6.1.2. Описание языка Neuron С предоставляет в распоряжение следующие базисные типы: [unsigned] char 8 бит signed unsigned [signed] unsigned [signed]

[short] [short] long long

char int int int int

8 бит 8 бит 8 бит 16 бит 16 бит

191 Тип перечисления уже определен. typedef

enum (FALSE, TRUE) boolean;

Другие заранее определенные типы предоставляются в распоряжение для объектов ввода/вывода и стандартных типов сетевых переменных. Основные определения function

для определения функций

int ampel (int a, int b);

для определения типов данных

typedef

typedef unsigned

long UWORD;

для перечисляемых типов

enum

enum farbe { ROT, GELB, GRUEN };

array для задания массивов int feld [4];

pointer для определения указателя char *p;

struct для создания структур (записей) struct zeit { unsigned int stunde; unsigned int minute; };

union чтобы сделать возможными варианты union feld { long int feld_a; int feld_b; };

Дополнительные декларации Объекты ввода/вывода Объекты, которые самостоятельно обрабатывают определенные функции ввода/вывода. Примечание/ Эти объекты так многочисленны, что более подробно речь о них пойдет в главе 9. IO_0 output oneshot ampel_trigger;

192 Таймер: Функции, миллисекундах.

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

временные

интервалы

в

секундах

или

stimer ampel_rot_Timer;

Сетевые переменные: Переменные, которые находятся в распоряжении всей сети. network output SNVT_temp_p Aussen_Temperatur.

Основные классы памяти: auto — локальные переменные; const — неизменяемые величины; extern — внешне определенная величина или функция; static — локальная величина или функция. Дополнительные классы памяти: Config — этот класс памяти может применяться только для сетевых переменных. Величина, определенная таким образом, находится в EEPROM и может изменяться из другого устройства только через сеть. Используется для конфигурации прикладной задачи. Network — определяет сетевые переменные. System — дает доступ к библиотеке функций микропрограммного обеспечения Neuron Chip. В прикладной программе это ключевое слово не используется. Eeprom — переменная или функция помещается в EEPROM. eeprom int Aussen_Temperatur; // Переменная eeprom int fn() {........} // Функция

Far — переменная помещается во внешнюю память. eeprom

far int Aussen_Temperatur; far int Aussen_Temperatur;

// RAM // EEPROM

Ram — функция помещается во внешнюю RAM (вне чипа). ram int fn() {........}

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

193 параметры некоторых портов ввода/вывода Neuron Chip. Необходимость конкретных pragma-директив определяется исключительно прикладными задачами и их требованиями к Neuron Chip. Полное перечисление и описание различных директив можно найти в руководстве по программированию на Neuron С от Echelon. Далее, в качестве примера указываются только директивы для определения различных параметров буфера, так как они оказывают особое влияние на поведение узла. #pragma #pragma #pragma #pragma #pragma #pragma #pragma fpragma #pragma #pragma #pragma

app_buf_in_count app_buf_in_size app_buf_out_count app_buf_out_priority_count app_buf_out_size net_buf_in_count net_buf_in_size net_buf_out_count net_buf_out_priority_count net_buf_out_size receive_trans_count

2 66 2 2 66 2 66 2 2 66 16

// // // // // // // // // // //

количество буферов размер буфера количество буферов количество буферов размер буфера количество буферов размер буфера количество буферов количество буферов размер буфера транзакции

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

Рис. 6-2. Все коммуникационные буферы расположены в RAM Далее было определено количество транзакций (16), что также потребовало дополнительно 16x13=208 байт памяти. Транзакция — это принятое сообщение и результирующий ответ. Количество транзакций задает, сколько входящих сообщений и ответов может одновременно корректно обрабатываться сетевым процессором. Системное поведение узла также определяется количеством буферов и количеством возможных транзакций. При определении этого параметра нужно принимать во внимание поведение узла при коммуникации с другими узлами при условиях worst-case (худший случай). Из вышеприведенного примера следует, что нужно правильно понимать последствия использования директив компилятора и их параметры. В худшем случае последствия неправильной установки приведут к неправильному поведению узла в

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

6.1.3. Библиотека В распоряжении прикладной программы находится несколько библиотечных функций. Каждая из этих функций может соответствовать одному из ниже описанных типов. — Тип 1: функции, встроенные в компилятор Neuron С. — Тип 2: функции, встроенные в системную область Neuron Chip 3120, 3120Е2, 3150. — Тип 3: функции, встроенные в системную область Neuron Chip 3150, или функции, отредактированные для прикладной области Neuron Chip-3120, 3120E2. — Тип 4: функции, отредактированные для прикладной области всех Neuron Chip. — Тип 5: функции, встроенные в системную область Neuron Chip 3150, или функции, отредактированные для прикладной области Neuron Chip 3120E2. Эти функции недоступны для области Neuron Chip 3120. — Тип 6: функции, встроенные в системную область Neuron Chip 3120, 3150, или функции, отредактированные для прикладной области Neuron Chip 3120Е2. Библиотечные применения:

функции

можно

подразделить

на

следующие

области

— контроль вывода; — контроль сетевого менеджмента; — обработка ошибок; — режим «сна» (минимального потребления энергии); — математика с целым числами; — математика с числами с плавающей точкой; — обработка знаков; — функции помощи; — функции ввода/вывода. Обзор библиотечных функций можно найти в различных справочниках [Mot 96] [Ech 95].

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

Рис. 6-3. Библиотечные функции

6.2. Планировщик Планировщик Neuron Chip-это функциональная часть, которая предоставляет прикладной программе возможность многозадачного функционирования. Многозадачные функции Neuron Chip ограничены в своих возможностях обрабатывать отдельные части программы, называемые задачами. Задача всегда обрабатывается до конца, прежде чем сможет запуститься другая задача. Планировщиком может обрабатываться до 80 задач. Обычно они активируются по методу Round-Robin.

6.2.1. Задача Neuron С Задачи в Neuron С определяются директивой when. Эта директива имеет следующий синтаксис: [priority] when (выражение)

Опцией priority можно задать задаче приоритет. Для запуска задачи могут применяться: выражение Neuron С, определенное событие, присвоение сетевой переменной нового значения, изменение ввода аппаратного обеспечения, ход таймера или комбинация таких событий. Приведем некоторые простые примеры для директивы when: when (x == 3) { } when (msg_arrives(10)) { } when (online) { }

Задача запустится только когда, когда выражение истинно. Также можно связывать друг с другом переменные и события, например: when ((х == 3) && (nv_update_occurs(а))) { } when ((msg_arrives(10)) && (у == 3)) { }

196 when ((timer_expires(m)) && (nv_update_occurs(a))) { }

В этом примере необходимо обратить внимание на то, что события после проверки устанавливаются в исходное состояние и их можно потерять для обработки. Рассмотрим более подробно один из ранее приведенных примеров: when ((x==3) && (nv_update_occurs(state))) { }

Здесь должно наступить событие, и переменная х должна иметь значение 3, прежде чем начнет выполняться соответствующая задача. Если событие наступит прежде, чем переменная х примет значение 3 и выполнится директива when, произойдет следующее: событие проверится и установится в исходное состояние и задача не запустится, так как х не равен 3. Если при следующем выполнении директивы when x примет значение 3, то условие окажется переустановленным в исходное состояние и задача снова не запустится. Событие будет потеряно для обработки. Поэтому необходимо внимательно проанализировать связь, которая должна запустить задачу.

Если выражение директивы when истинно, то задача обрабатывается до конца; если ложно, то она пропускается.

6.2.2. Принцип функционирования планировщика После включения рабочего напряжения или нового запуска прикладной задачи предпринимаются все необходимые предварительные установки. Если существует задача установки, то планировщик начинает свою работу с ее обработки. В этой задаче можно произвести все установки, специфичные для прикладной задачи. Затем обрабатываются задачи с приоритетом и задачи специфические для системы. Если выражение одной из этих задач истинно, то она обрабатывается, и планировщик начинает все сначала. Только в том случае, если больше нет ни одного истинного выражения в этих задачах, во внимание принимаются задачи без приоритета, которые обрабатываются по методу Round-Robin. Задачи без приоритета снова и снова перемежаются с задачами с приоритетом и специфичными для системы задачами независимо от того, обработалась задача без приоритета или ее пропустили. Все задачи без приоритета обрабатываются в той последовательности, в которой они были определены в прикладной программе. Если в последовательности последняя задача была без приоритета, то планировщик начинает снова с первой задачи. Системно-специфическими задачами являются offline, online и wink, и с ними

197 обращаются так же, как с задачами с приоритетом. Первой задачей с приоритетом всегда является offline, если она была определена. when (offline) { } when (online) { } when (wink) { }

В этом специальном случае дополнение «priority» может отсутствовать.

Рис. 6-4. Принцип функционирования планировщика Вышеописанный способ функционирования планировщика может меняться. Директивой #pragma scheduler_reset можно повлиять на метод Round-Robin планировщика, который снова начинает с первой задачи без приоритета, если наступает одно из следующих событий: — становится доступной новая сетевая переменная; — было принято новое сообщение; — истек таймер.

198

Рис. 6-5. Переустановка планировщика после выполнения задачи 2 Планировщик перемещается в стартовую позицию. Следующая задача без приоритета, которая обрабатывается, — это задача 1. Еще одна возможность изменить способ функционирования планировщика, — это не специальная директива, а техника программирования bypass-Mode. В этом случае определяется только одна задача, выражение которой всегда истинно и из которой никогда не выходят. Данная техника применяется только тогда, когда необходим собственный алгоритм для выполнения задачи. При этом за обработку событий ответственна лишь прикладная программа. when (TRUE) { while (TRUE) { post_events (); if (offline) {..........} if (.......) {..........} if (msg_arrives) {..........} } }

6.2.3. Управление функциями Для управления задачей Neuron С дает в распоряжение последовательность событий, которые подразделяются на различные классы. Ниже приведены отдельные события в соответствии с их классом. Системные события reset

событие выполняется при каждой переустановке Neuron Chip,

offline

узел был изъят из работы;

online

узел был снова запущен в работу;

flush_completes

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

199 wink узел

должен сделать себя заметным.

События ввода/вывода io_changes

изменилось значение объекта ввода/вывода;

io_update_occurs

объект ввода получил новое значение;

io_in_ready

параллельный интерфейс имеет новые данные;

io_out_ready

можно посылать новые данные к параллельному интерфейсу.

События таймера timer_expires

время таймера истекло.

События сообщений и сетевых переменных nv_update_occurs

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

nv_update_fails

посылка или запрос значения сетевой переменной были ошибочны;

nv_update_succeeds успешны;

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

nv_update_completes

посылка или запрос значения сетевой переменной были завершены;

msg_arrives

было принято явное сообщение;

msg_completes

отсылка явного сообщения была завершена;

msg_succeeds

отсылка явного сообщения была успешной;

msg_fails

отсылка явного сообщения была ошибочной.

События, специфические для пользователя — Специфическое для пользователя выражение с результатом «истинно» или «ложно».

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

200 требуемого времени можно применять величину 1 мс. Это время требуется планировщику, чтобы определить, является ли выражение истинным или нет. Для прикладной задачи: — задача wink; — две задачи с приоритетом; — 8 нормальных задач. Планировщику для одного прохода всех задач, если все вьфажения не истинны, требуется 8 * 3 + 8 = 32 мс.

Задача wink и задачи с приоритетом при этом опрашиваются 8 раз, задачи без приоритета — по одному разу. Если истинные выражения задачи с приоритетом следуют друг за другом слишком быстро, то может случиться, что больше не обработается ни одна задача без приоритета.

Рис. 6-6. Критерии запуска для задачи с приоритетом слишком быстро следуют друг за другом Может установиться похожее рабочее состояние, если используется #pragma scheduler_reset, и события, которые устанавливает планировщик в начальную позицию, выполняются слишком быстро.

Рис. 6-7. Переустановка планировщика производится всегда до того, как смогут обрабатываться задачи 3 и 4

201

6.2.5. Обработка ошибок Neuron Chip имеет собственный таймер Watchdog. В системе с частотой 10 МГц время составляет 0,84 секунды, при 5 МГц оно равно 1,68 секунд. Этот таймер всегда устанавливается планировщиком. Конечно, если активна длинная прикладная задача, то программист должен сам позаботиться о том, чтобы во избежание переустановки узла таймер Watchdog не срабатывал.

Рис. 6-8. Слишком большое время задачи (10 МГц) Планировщик автоматически устанавливает таймер Watchdog в конце обработки каждого оператора When. Таймер можно установить заново внутри оператора также с помощью функции watchdog_update() или функций: — post_events(); — msg_receive(); — resp_receive(); — pulsecount.

Рис. 6-9. Watchdog Update (10 МГц) При обнаружении ошибочного состояния самой прикладной программы возможны следующие варианты: — функцией node_reset() все узлы устанавливаются в исходное состояние. Все три CPU начинают работу заново, и вся информация, которая не была сохранена в EEPROM, теряется; — функция application_reset() устанавливает в исходное состояние только прикладное CPU. Оба других процессора продолжают работать без прерываний.

202

Рис. 6-10. Функции переустановки прикладной задачи С помощью функции error_log() можно записать собственный номер ошибки в область с 1-127 в EEPROM. Другой узел может потом считать эту запись и сделать выводы из кода ошибки прикладной задачи. Программные и сетевые ошибки автоматически запоминаются при их поступлении. Для всех видов ошибок в распоряжении находится только одна ячейка для хранения ее кода. Таким образом, можно обнаружить только последнюю ошибку. Примером для автоматически сгенерированных номеров ошибок являются: —EEPROM_WRTTE_FAIL

= 132

—DIVIDE_BY_ZERO

= 148

— WRITE_PAST_END_OF_APPL_BUFFER

= 156

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

6.3. Объекты коммуникации Коммуникация между узлами выполняется двумя способами. Предпочтительный вид обмена данными осуществляется посредством сетевых переменных и называется Implicit Message, так как отсылка и прием выполняются автоматически. Второй вид называется Explicit Message, когда процесс коммуникации обрабатывается программой. Сообщение должно быть сформировано, отослано, и должен быть принят ответ. Explicit Message требует меньше места памяти EEPROM, чем Implicit Messages, однако требует больше места в памяти программы. У обоих способов передачи есть преимущества и недостатки. В любом случае необходимо проверить, какой способ более подходит для той или иной постановки задачи, при этом следует помнить, что с помощью Explicit Message взаимодействие (см. гл. 10) узлов от различных производителей не достигается.

203

6.3.1. Сетевые переменные Сетевые переменные (СП) — это переменные, которые определены в прикладной программе классом памяти network. network output network input

SNVT_temp_p SNVT_temp_p

Room_Temperature; Outside_Temperature.

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

Связь между сетевыми переменными можно осуществить различными способами, поскольку тип этой связи зависит от системы, в которой установлены узлы. Она может выполняться как часть процесса изготовления, если применяемые узлы установлены в жесткую, очерченную систему (например, фотокопирующее устройство). В гомогенной структуре применяются стратегии, обеспечивающие связь сетевых переменных в зависимости от входов аппаратного обеспечения и определенных прикладных параметров. В сложных системах, где разные узлы должны обмениваться информацией друг с другом, связь выполняется с помощью системы инсталляции. В одном узле можно определить до 62 сетевых переменных длиной до 31 байта. Одна сетевая переменная output может быть связана с неограниченным количеством сетевых переменных input и наоборот; при этом можно также обеспечить связи в одном узле (turnaround). Если Neuron Chip используется как процессор коммуникации, а вторая система процессоров берет на себя обработку прикладной задачи, то можно реализовать до 4096 сетевых переменных. Переход значения сетевой переменной выполняется четырьмя различными службами. ACKD Отправка с подтверждением приема и повторением. UNACKD

Отправка без подтверждения приема.

UNACKD_RPT

Отправка без подтверждения приема с повторениями.

Следуя этому, можно выбрать следующие службы: Authenticated

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

Polled

сетевая переменная input должна сама выбрать значение в сетевой переменной output.

204 Priority

отправление приоритет.

значения

сетевой

переменной

получает

Synchronous

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

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

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

nv_update_fails

не выполнилась отправка значения для сетевой переменной output,

nv_update_succeeds

отправка значения успешной,

nv_update_completes

закончена отправка значения для сетевой переменной output.

сетевой

переменной

output

была

При отправке подтверждения приема необходим ответ всех приемников, при отправке без подтверждения приема сообщение должно попасть в сеть. Для отправки и приема сетевых переменных требуются две специальные внутренние таблицы — это таблица адресов и таблица сетевых переменных. Обе они находятся в EEPROM Neuron Chip. Таблица адресов включает до 15 записей; в ней содержатся адреса узлов, по которым посылаются сетевые переменные output и на которые могут посылаться неявно адресованные сообщения. При использовании директивы poll() для соответствующих сетевых переменных input также выделяется Address Table Entry (запись таблицы адресов). Адреса имеют следующий вид: Turnaround адресован собственный узел, Neuron_id узел

адресован с помощью его ID,

Subnet_node

адресован определенный узел,

Group

адресована группа узлов,

Broadcast

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

Каждая запись таблицы адресов может быть использована многократно. Таблица сетевых переменных в Neuron Chip может иметь до 62 записей, содержащих параметры обработки и используемые индексы таблицы адресов. Параметрами обработки являются: Priority

посылается переменная с приоритетом,

Direction

переменные ввода/вывода,

205 Selector

метка переменных,

Turnaround

связь с одной переменной в собственном узле,

Service

определение выбранного способа передачи,

Authenticated

передача защищена.

Индекс таблицы адресов у сетевой переменной output указывает, на какой или на какие узлы посылается сетевая переменная. Метка переменной определяет, в какую сетевую переменную input попадет значение. Связанные сетевые переменные имеют одинаковые метки.

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

Рис. 6-12. Структура явного сообщения для сетевой переменной Update

206

6.3.2. Явные сообщения В некоторых случаях — когда передаются данные длиной более 31 байта, когда имеющиеся типы сетевых переменных не подходят или требуется передача данных с ответим на них — применения сетевых переменных недостаточно. Дополнительно явное сообщение поддерживает механизм запросов/ответов, позволяющий прикладной задаче одного узла выполнять определенные действия в прикладной задаче другого узла. В результате на свое сообщение (запрос) узел-отправитель получает ответ. С помощью явного сообщения можно передавать данные длиной до 259 байтов. Но прежде чем определить максимальную длину сообщения, необходимо сверить данные со справочником «Interoperability Guidelines» ассоциации «LonMark Interoperability Association» [Lonm 96]. Так, если хотят установить узел, который совместим и обладает знаком LonMark, то вышеуказанное максимальное значение применять нельзя. В сетевых переменных можно использовать следующие службы: ACKD

отправка с подтверждением приема и повторениями.

UNACKD

отправка без подтверждения приема.

UNACKD_RPT

отправка без подтверждения приема с повторениями.

REQUEST

отправка с ответным сообщением.

Authenticated

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

Priority

отправке явного сообщения придается приоритет.

Адресация сообщения выполняется внесением адресной информации по каждому виду адресации: Neuron_id

узел адресуется своим ID.

Subnet_node

адресуется определенный узел.

Group

адресуется группа узлов.

Broadcast

адресуются все узлы подсети.

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

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

telegramm_a telegramm_b

//связанный ярлык сообщения //свободный ярлык сообщения

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

Следующая when-директива истинна только тогда, сообщение с соответствующим кодом, в данном случае — 10.

когда

принимается

when (msg_arrives (10)) { }

Задание кодов сообщений несвободно (Таблица 6-1, см. также главу 4). Таблица 6-1. Коды сообщений Тип сообщения

Код сообщения

Пользовательское сообщение Внешний фрейм Запрос

00 — 62

Сетевая диагностика

80 — 95

Сетевой менеджмент

96 — 127

Сетевая переменная

128-255

64 — 78 63 + 79

Прикладная задача свободно использует коды для различных сообщений из области 00-62. Затем на основании кода она решает, какой обработке должно подвергнуться сообщение перед анализом его содержания. В противоположность сетевым переменным, явное сообщение само управляет всей передачей данных. Далее кратко показано функциональное протекание передачи. Управление буфером необязательно, поскольку обычно его берет на себя планировщик. Соответствующие выходные буферы резервируются, если они записываются в объекте msg_out или resp_out. Если ни один из буферов не свободен, то

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

6.4. Режимы работы узлов 6.4.1. Способность узла к работе в реальном времени Обработка событий в реальном времени означает, что прикладная программа может обрабатывать их по мере поступления, тем самым значения ввода/вывода предоставляются в распоряжение в соответствующее произошедшему событию время. Для определения требования реального времени необходим анализ желаемого поведения узла. Измерения времени в прикладной программе помогают контролировать способность к работе в реальном времени, так как минимальное и максимальное время реакции должно быть предсказуемо.

6.4.2. Работа распределенного приложения в реальном времени Так как LonTalk не является детерминистической системой, то время доступа к шине задается только с высокой вероятностью, но не абсолютно. Поэтому о распределенном приложении как о системе, способной работать в реальном времени, можно говорить только с определенными допущениями (см. раздел 1.3.3). Если прикладная задача в отдельном узле и коммуникационные связи между узлами распределенного приложения соответствуют реальному времени, то о LonWorks также можно говорить как о системе реального времени. В этом случае важнейшим критерием способности работы в реальном времени является предсказуемость поведения во времени, которая может гарантироваться с высокой вероятностью.

Рис. 6-13. Пример распределенного приложения

209 Действие

Функция Neuron С

Тип

Выставление сообщения

msg_out

Объект

Отправка сообщения

msg_send()

Функция

msg_cancel()

Функция

msg_arrives

Событие

msg_receive()

Функция

msg_in

Объект

msg_completes

Событие

msg_succeeds

Событие

msg_fails

Событие

resp_out

Объект

resp_send()

Функция

resp_cancel()

Функция

resp_arrives

Событие

resp_receive()

Функция

resp_in

Объект

msg_alloc()

Функция

Прием сообщения

После отправки с ACKD

Отправка обратного ответа

Прием обратного ответа

Управление буфером

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

210 msg_alloc_priority()

Функция

msg_free()

Функция

resp_alloc()

Функция

resp_free()

Функция

Эта функция резервирует буфер для отправки с приоритетом С помощью этой функции освобождается буфер для отправки Эта функция резервирует буфер для ответа С помощью этой функции освобождается буфер для ответа

6.4.3. Поведение узла в распределенной системе Важным условием для узла, который встроен в распределенную систему, является то, что поведение системы должно быть предсказуемым. Цель LonWorks — сделать возможным распределенное приложение с устройствами от различных производителей. Для безошибочной работы всей системы необходимо, чтобы было предсказуемым поведение отдельного узла. Это относится и к прикладной задаче, и к методам коммуникации узла. Для прикладной задачи важно, чтобы все события могли обрабатываться вовремя, входное значение обрабатывалось в желаемом интервале времени и устанавливались выходные значения. Далее, не теряя промежуточного значения, должны обрабатываться все поступающие сетевые переменные и явные сообщения. Здесь мы видим, что прикладная задача зависит от поведения распределенной системы при коммуникации. Без анализа поведения при коммуникации нельзя оптимально изложить прикладную задачу. В связи с этим подробнее рассмотрим некоторые параметры. Количество сетевых переменных, как правило, задается постановкой задачи, в то время как определение сетевых и прикладных буферов требует особого внимания. При условии достаточной ширины пропускания передающей среды количество буферов вывода зависит только от скорости отдельной прикладной задачи. В этом случае для установки выходных переменных до их передачи в сетевой буфер и в сеть также необходимо некоторое количество буферов. У входных сетевых переменных количество буферов зависит от многих факторов. Важнейшим из них является частота отсылки отдельных сетевых переменных, которые устанавливаются у узла-отправителя параметром minimum_update_time, чтобы поведение во времени было предсказуемым. С помощью этого параметра можно рассчитать максимальное количество назначений сетевой переменной в единицу времени. Таким образом, определяется количество прикладных

211 буферов, а также максимальное время, которое может требовать система, чтобы обработать переменную. Если количества прикладных буферов не хватает, так как задействовано очень много величин или прикладная программа слишком медленна, то необходимо учесть и параметры коммуникации, т.е. попытаться вычислить поведение во времени с помощью повторений, превышения лимита времени при отправке и времени реакции прикладной задачи. Определение понятий: — превышение лимита времени при отправке — время, которое ожидается при отправке службой ACKD, пока сообщение не повторится; — количество повторений — процесс отправки повторяется х раз, если не будет принято АСК; — время реакции прикладной задачи — максимальное время, которое необходимо прикладной задаче, чтобы обработать изменение сетевой переменной; — время цикла прикладной задачи: максимальное время, которое необходимо прикладной задаче, чтобы выполнить все директивы when. Рассмотрим простой пример. Узел, обладающий 5 входными сетевыми переменными, которые получают новые значения максимум каждые 2 секунды. Кроме того, узел обладает х входными сетевыми переменными, используемыми для параметризации, переключения режимов работы и обслуживания. В этом случае микросхемы ввода/вывода должны обрабатываться, по меньшей мере, по 500 мс каждая. Результат работы алгоритма прикладной задачи записывается в сетевую переменную, величина которой изменяется максимум один раз в секунду. Сначала рассмотрим входной буфер. Самый неблагоприятный случай при приеме сообщения — когда все возможные сообщения поступают псевдоодновременно. Под этим подразумевается, что они передаются по Lon непосредственно друг за другом. Для узла, описанного ранее, это означает, что установлено 6 сетевых переменных, из которых пять можно ожидать циклически и одну, которая заменяет остальные. Это обусловлено тем, что остальные сетевые переменные ожидаются эпизодически. В этом случае возникает предположение, что прикладная задача не обрабатывает входы, пока не вошли все изменения. С помощью этого допущения можно установить количество буферов входа. Чтобы сообщения могли приниматься непосредственно друг за другом, целесообразно иметь два сетевых буфера ввода. Количество прикладных буферов ввода устанавливается равным 6, чтобы была возможность принимать все поступающие сообщения до того, как прикладная задача успеет их обработать. Прикладная задача имела бы в этом случае только 2 с времени на обработку входящих значений. Для определения времени реакции прикладной задачи нужно исходить из другого допущения — что значения отделены друг от друга 2 секундами. Алгоритм прикладной задачи каждую секунду должен предоставлять текущее выходное значение, причем значение ввода/вывода не должно быть старше 500 мс. Следовательно, используемые сетевые переменные ввода также не должны быть старше. Поэтому для

212 прикладной задачи самое большее время реакции составляет 500 мс. Прикладная задача может потом удостовериться, что рассчитанная величина для сетевой переменной вывода устанавливается не чаще чем раз в секунду. В качестве буфера вывода в этом простом устройстве хватает одного прикладного буфера вывода и двух сетевых буферов вывода. Количество последних обусловлено тем, что при приеме значения сетевой переменной с подтверждением приема она отсылается с помощью сетевого буфера вывода. Если вышеописанные параметры для этого узла установлены, то можно говорить об узле, способном работать в режиме реального времени. Хотя это и не единственное решение. Если, например, памяти для организации прикладного буфера недостаточно, то можно предупредить потерю данных правильным выбором параметров коммуникации (Retry, TX-Timeout) сетевых переменных ввода из узла отправителя, если они отосланы с Ask-Service. При этом время реакции должно быть настолько малым, чтобы могли быть обработаны все изменения, прежде чем произойдет повторение. Время реакции для обработки изменения сетевой переменной не должно быть равным времени цикла прикладной задачи. Обработку изменений можно выполнять в нескольких местах, тем самым сокращая время. Какое решение для той или иной прикладной задачи является наилучшим, определяется только точным анализом. Таким образом, для оптимальной обработки задачи решающим является не быстрота узла, а предсказуемость его поведения. Именно в распределенном приложении поведение во времени должно быть предсказуемым для его безошибочной работы. Выводы: Если в прикладной задаче применяются связанные ярлыки, то при связывании с помощью инсталляционной системы нужно обращать внимание на то, чтобы система учитывала эти ярлыки. При определении количества требуемых буферов нужно точно рассчитать, какое количество сообщений может одновременно или в течение времени обработки поступать в определенный узел, так как возможно, что при определенных обстоятельствах некоторые сообщения никогда не смогут быть принятыми. При установке параметров повторения сообщения (retry) и времени передачи (tx_timer) следует точно вычислить время обработки узла-приемника и обратить внимание на то, что это время может варьироваться в зависимости от сложности прикладной программы. Если в сетевой CPU Neuron Chip приходят повторение и ответ на повторяемое сообщение, то ответ будет отброшен, а повторение обработается снова. Необходимо обращать внимание на то, что каждая директива when, даже если она не была истинна, требует примерно 1 мс на обработку.

213 Использование приоритетных задач может привести к тому, что нормальные задачи выполняться не будут. При использовании «scheduler_preset» необходим точный анализ системы, чтобы установить, гарантируется ли ее желаемое поведение. События, которые устанавливает планировщик в начальное состояние, могут привести к тому, что важные части программы вообще не будут обрабатываться, будут обрабатываться слишком часто или слишком редко.

214

7. Сетевые структуры и переходы между сетями Протокол LonTalk поддерживает различные сетевые структуры и связи между сетями, что обеспечивается наличием разнообразных типов трансиверов. Цель данной главы — назвать и пояснить возможные сетевые структуры. Здесь будут рассмотрены такие понятия, как повторитель, мост, маршрутизатор, шлюз согласно номенклатуре LAN, а также возможности применения различных сетевых структур в LonTalk. В заключение приводятся примеры взаимодействия с другими сетями.

7.1. Характеристики структур шин и открытых сред У систем Fieldbus на уровне 2 в большинстве случаев применяется структура шины типа «линия» (Рис. 7-1)1. Узлы при этом подключены к шине как можно более короткой линией межсистемной связи, чтобы избежать отражения. Примером тому являются CAN, P-NET и PROFIBUS.

Рис. 7-1. Структура шины типа «линия» Самое известное исключение — Interbus S (см. главу 1).

1

Самое известное исключение — Interbus S (см. главу 1).

216 Однако в автоматизации жилых зданий и помещений такой вид шин малопрактичен, поэтому для обеспечения низкого уровня затрат преимущественно применяется линейная шина с проводниками межсистемной связи длиной до нескольких метров (Рис. 7-2).

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

Рис. 7-3. Передача с отраженным импульсом Для систем шин, которые используют в качестве метода доступа к шине CSMA, актуально еще одно предположение относительно времени протекания и длины импульса. Например, если два узла, А и Б, подключены к сегменту шины на расстоянии х друг от друга, то tпротекания — это время протекания импульса от одного узла к другому. Если узел А получает доступ к шине, то первый импульс поступает на шину

217 (Рис. 7-4, ti). К моменту времени t2 шину начинает занимать также узел Б, поскольку он еще не распознал, что узел А ее уже занял. Тогда к моменту времени t3 наступает конфликт обоих пакетов, который затем распознается узлом Б в момент времени t4. В нашем примере он сразу же отстраняется от шины и ждет ее следующего незанятого состояния. Только в момент t6 узел А наконец замечает коллизию и также отстраняется от шины. Если необходимо гарантировать, чтобы отправитель заметил коллизию еще в течение того времени, пока он посылает импульс на шину, должно выполняться: tдлины_импульса ≥ 2tпротекания Это отношение применяется, например, в CAN [CAN94].

Рис. 7-4. Конфликт двух пакетов данных Приведем пример, дающий представление о связи времени протекания и длины поступившего на шину импульса. Дан проводник длиной 300 м, полное отражение (коэффициент отражения = 1). Если выполняется условие tпротекания = tдлины

импульса,

то для проводника типа «витая пара» риблизительно подходит следующая оценка длины импульса:

218

Как видим, уже при относительно небольшой длине проводника (в вышеприведенном примере 300 м) длина импульса может попасть в область времени длительности сигнала. Если затем возникают неоднородности в волновом сопротивлении проводника передающей среды, то в этом месте происходит неоднородное отражение идущего сигнала (в нашем случае импульса), которое может накладываться на сигнал отправителя как конструктивно, так и деструктивно. Уже на основании этого выводится связь между максимальной длиной шины и максимально возможной скоростью передачи данных в зависимости от возникающих на проводнике отражений. Еще один нежелательный эффект — дисперсия на проводнике, приводящая к расширению импульса на основании частотной зависимости параметров проводника. Этот эффект можно минимизировать применением импульсов Нейквиста [Lee94, Trond87]. В дополнение к классическим структурам шин, LonWorks поддерживает в качестве передающей среды линии электропередачи и радио (радиочастота — RF). Для того чтобы детально рассмотреть поведение LonTalk в таких передающих средах, необходимо сначала определить понятие «открытая среда». Под открытой средой понимается такая передающая среда, в которой на узел можно выйти различными «бесконечно многими» физическими путями передачи. В общем случае это приемлемо при распределенной топологии сети и в частном случаенапример, при передаче по радиочастоте — с использованием изотропно излучающей антенны. В некоторых случаях под открытой средой можно понимать силовые линии. В идеальном случае открытую среду можно представить как сверхпроводниковую БИС, с которой узлы сети контактируют в произвольном порядке (Рис. 7-5).

219

Рис. 7-5. Открытая среда Особенности открытой среды по отношению к маршрутизатору Lon Works подробно обсуждаются в разделе 7.4.6.

7.2. Повторители, мосты, маршрутизаторы и шлюзы Далее описываются функции повторителей, мостов, маршрутизаторов и шлюзов согласно номенклатуре LAN.

7.2.1. Повторитель Повторитель работает на уровне 1 и физически разделяет сеть на несколько частей (Рис. 7-6). Он необходим в тех случаях, когда нагрузка на проводнике шины становится слишком высокой либо для большого количества подключенных узлов недостаточно выходной мощности (Fan Out) драйвера шины. Повторитель также подключается для того, чтобы разделить сегменты сети с различными видами битового кодирования.

Рис. 7-6. Повторитель Как показано на Рис. 7-6, повторитель не проверяет пакеты на их достоверность,

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

7.2.2. Мост Мост работает на уровне 2 (Рис. 7-7) и служит для объединения различных частей сети в целях: — разделения нагрузки; — ограничения ошибок; — соблюдения аспектов надежности. С помощью мостов можно соединять сегменты сети с различными протоколами уровня 2 способа доступа (MAC). Кроме того, они выполняют такую функцию повторителей, как физическое разделение частей сети.

Рис. 7-7. Мост с МАС-адресами (уровень 2) Каждый узел сети имеет однозначный (уникальный) адрес, зависящий от аппаратного обеспечения (МАС-адрес). МАС-адреса не структурированы: они распределены в сети случайным образом. В ходе передачи мостов применяют таблицы адресов MAC. Размер этих таблиц прямо пропорционален количеству всех имеющихся в логической сети участников, поскольку мост должен быть известен каждому узлу, имеющему адрес на любой из сторон моста (Рис. 7-8).

221

Рис. 7-8. Передача кадра мостом На Рис. 7-8 в качестве примера приведена передача кадра от узла А к узлу G, отделенному от первого двумя мостами. Узел А адресует пакет на узел G МАС-адресом (MDA). Как и все другие узлы в сети 1, мост 1 определяет, что пакет предназначен узлу G в сети 2, и находит в таблице передачи (таблица моста 1) запись для МАС-адреса узла G, указывающую, что этот узел находится на другой стороне моста 1. Таким образом, мост 1 направляет пакет в сеть 3. Там мост 2 получает пакет, адресованный узлу G, и на основании записи в таблице передачи отправляет его в сеть 2, где он принимается узлом G Ни узел А, ни узел G не замечают никаких действий моста. Из этого следует, что, начиная с уровня 2а, поведение мостов прозрачно для всех вышележащих протоколов передач (LLC и выше) [Hals95].

7.2.3. Маршрутизатор Маршрутизатор работает с адресами и протоколами уровня 3 и выполняет дальнейшую передачу пакета (Рис. 7-9). Адреса уровня 3 — это логические адреса; в отличие от МАС-адресов, они являются аппаратно-независимыми. Они делают возможным структурное разделение сети на подсети и позволяют установить однозначное соответствие между подсетью и ее участниками. Логический адрес располагается «поверх» МАС-адреса.

222

Рис. 7-9. Маршрутизатор Маршрутизатор связывает две соседние подсети и обладает информацией о кратчайшем пути к другим подсетям. В отличие от моста, маршрутизатор оперирует только адресами подсетей, которые хранит в таблице маршрутизации. Размер этой таблицы прямо пропорционален количеству подсетей и не превышает числа участников (как и у моста). Пакет данных адресуется конечным узлом напрямую маршрутизатору по его МАС-адресу. Маршрутизатор обрабатывает только эти пакеты. Из таблиц маршрутизации он узнает, что необходимо делать с пакетами, приходящими на его МАС-адрес. Как показывает рис. 7-10, при передаче пакета через маршрутизатор адреса уровня 3 не меняются. Отдельный маршрутизатор и узел сети всегда запрашиваются по их МАС-адресам. Таким образом, каждый маршрутизатор должен обладать следующей информацией: — МАС-адреса всех узлов, находящихся в одной сети с портом маршрутизатора; — через какие маршрутизаторы доступна та или иная подсеть. Для того чтобы маршрутизатор успешно работал, должны выполняться следующие условия: — передающая система должна иметь стандартные функции уровня 3 (логические адреса уровня 3, маршрутизируемый протокол и т. д.) от одной конечной системы через маршрутизатор к другой конечной системе; — конечная система должна быть информирована приведенного ей в соответствие маршрутизатора;

о

расположении

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

223

Рис. 7-10. Передача кадра маршрутизатором

7.2.4. Шлюз Шлюз (Рис. 7-11) работает на 7-м уровне протокола и служит для связи различных систем коммуникации. Если эти системы предоставляют аналогичные службы, затраты на прикладную задачу в шлюзе могут быть довольно-таки невелики. Однако если необходимо связать друг с другом системы коммуникации, интерфейс пользовательского уровня которых сильно отличается, это ведет к большим затратам на прикладной шлюз (см. Раздел 7.6).

Рис. 7-11. Шлюз

224 В разделе 5.6 «Связь между сетями» рассматриваются шлюзы между LonTalk и PROFIBUS, а также между LonTalk и HTTP.

7.3. Маршрутизация в сети LonWorks 7.3.1. Адресация в LonTalk Протокол LonTalk определяет иерархическую форму адресации с использованием адресов доменов, подсетей и узлов. Внутри домена узлы могут образовывать группы и затем адресоваться по групповому принципу. Дополнительно каждый Neuron Chip имеет 48-битный идентификатор (Neuron ID), уникальный для каждого конкретного чипа. Таблица 7-1 содержит перечень всех возможных видов адресации. Таблица 7-1. Типы адресации в LonTalk Broadcast

На все узлы внутри домена

Group

На все узлы внутри группы

Subnet/Group Member Subnet

К одному члену группы в определенной подсети На все узлы внутри подсети

Subnet/Node Neuron ID

На определенный узел внутри подсети На узел с соответствующим Neuron ID

7.3.2. Адресация уровней 2 и 3 Как уже упоминалось, в LonTalk применяется иерархическая адресация узлов сети и ко всем узлам можно обратиться по их Neuron ID. Из этого можно было бы сделать следующее (ложное) заключение: Neuron ID

адрес уровня 2 (MAC)

Иерархические адреса

адреса уровня 3

В смысле адресации, согласно оговоренной в разделе 7.2 номенклатуре LAN2, это заключение было бы верным. Но LonTalk, в противоположность к LAN, передает в своих PDU не оба адреса: передача МАС-адреса в LonTalk не производится. Если необходимо запросить узел по его Neuron ID, то он передается в NPDU как адрес 2

См. также IEEE 802.2.

225 уровня 33. Таким образом, Neuron ID обрабатывается в узле как иерархический адрес. Если Neuron Chip принимает PPDU, то он копирует все NPDU в сетевой буфер и только затем решает, должен ли пакет (на основании адреса) обрабатываться узлом дальше. Из этого обязательно следует, что каждый узел должен считывать каждый пакет из канала, чтобы не происходило потерь пакетов.

7.4. Маршрутизатор LonWorks Lon Works-маршрутизаторами называются маршрутизаторы, производимые фирмой Echelon. Подобное обозначение является результатом политики присваивания наименований производственного отдела фирмы Echelon.

7.4.1. Характеристики Маршрутизатор LonWorks является 2-портовым маршрутизатором. Каждый его порт реализован на Neuron Chip (Рис. 7-12) и со стороны сети может рассматриваться как обычный узел LonWorks. Таким образом, в сетевой иерархии необходимо выделить каждый порт маршрутизатора LonWorks. Это выполняется записью таблицы домена в Neuron Chip, причем каждому Neuron Chip соответствуют две такие записи.

Рис. 7-12. Схема связи блоков маршрутизатора LonWorks Основное правило применения маршрутизаторов LonWorks состоит в том, что маршрутизатор не может связывать две части подсети внутри одного и того же домена (Рис. 7-13) [Rout95]. Маршрутизаторы подразделяют на обучающиеся и конфигурируемые. Оба типа маршрутизаторов имеют таблицы передачи (Forwarding-Tables, FWT), в которых определяется, какое сообщение передается со стороны маршрутизатора 1 LonWorks на сторону маршрутизатора 2 (или наоборот). Для каждой стороны маршрутизатора или домена используется собственная FWT. Каждая FWT содержит флаг передачи (FWF) для каждой из 255 подсетей и 255 групп на домен.

3

См. LONTALK Protocol Data Unit Summary в главе 4.

226

Рис. 7-13. Запрещенный случай работы маршрутизатора LonWorks

7.4.2. Таблицы передачи Маршрутизатор LonWorks обладает двумя парами таблиц для каждой из своих сторон: таблицей с флагами передачи для групп и таблицей с флагами передачи для подсетей. Обе таблицы помещены как в EEPROM, так и в RAM. Флаги передачи можно адресовать группами по 8 байт, что сокращает время записи при загрузке всей таблицы. Таблицы с флагами передачи могут быть считаны и записаны по сети специальными сообщениями сетевого менеджмента (ССМ) (см. 4.10.11 «Сообщения сетевого менеджмента для маршрутизатора»). Таблицей передачи для той или иной стороны маршрутизатора управляет соответствующий Neuron Chip. Для задания параметров маршрутизации не обязательно подключать каждый из портов маршрутизатора. Существует возможность конфигурировать Neuron Chip, отвечающий за порт Б, из порта А. Для этого LonTalk поддерживает код Far Side Escape Code, который отправляет сообщение сетевого менеджмента для Neuron Chip на другую сторону (far side) маршрутизатора.

7.4.3. Обучающийся маршрутизатор LonWorks Обучающийся маршрутизатор LonWorks в процессе работы изучает топологию сети, а также составляет список узлов, находящихся на каждой из его сторон. Это достигается за счет разбора адресов источников подсети в NPDU. Известно, что одна подсеть никогда не может располагаться с обеих сторон маршрутизатора. После каждой установки (или включения питания) обучающийся маршрутизатор LonWorks действует как мост LonWorks, то есть в нем установлены все флаги передачи. Затем каждый раз, когда принимается новый идентификационный номер подсети в поле адреса источника NPDU, обучающийся маршрутизатор стирает соответствующий флаг передачи. После этого перепроверяется адрес назначения с целью решить, игнорировать пакет или передать дальше [Rout95].

227

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

7.4.5. Простая топология зацикливания (петля) Под простой топологией зацикливания понимают сетевую топологию, допускающую зацикливание сообщения. Цикл-это путь через два или более маршрутизатора, согласно которому в результате сообщение попадает в исходную сеть (Рис. 7-14). Пакеты с заданным маршрутом вращаются по кругу, и сеть при этом становится нестабильной. Так, в схеме, изображенной на рис. 7-14, может, например, произойти следующее: сообщение от сети Б передается через маршрутизатор 1 на сеть А, а маршрутизатором 2 все сообщения от сети А передаются в сеть Б. Сообщение с заданным маршрутом вращается по кругу (бесконечный цикл). Точно такая же проблема возникает при применении обучающегося маршрутизатора LonWorks. Поэтому обучающиеся маршрутизаторы LonWorks не применимы для топологий, аналогичных изображенной на рис. 7-14.

Рис. 7-14. Простая топология петли Конфигурируемый маршрутизатор позволяет разрешить проблему «петли» без расширения таблицы передачи, с помощью специальных приемов [Rout95]. Как уже упоминалось, одна и та же подсеть никогда не может находиться по обе стороны маршрутизатора (Рис. 7-13). Если сообщение передается на маршрутизатор, то номер подсети адреса источника не совпадает с номером подсети адреса назначения. Если у конфигурируемого маршрутизатора в таблице установлен флаг передачи подсети-источника, то это сообщение не передается. Тем самым можно избежать простой топологии зацикливания (как на рис. 7-4).

228

7.4.6. Конфигурируемый маршрутизатор LonWorks в открытой среде При использовании открытой сети передачи, тема зацикливания пакета приобретает совершенно иной масштаб. Здесь установка маршрутизатора имеет смысл только тогда, когда применяется сверхпроводящая поверхность (Рис. 7-15), подобная изображенной на рис. 7-5. В качестве аналога этому можно представить передачу радиоволн посредством изотропного излучения, при котором сила поля уменьшается по мере удаления от исходной точки. В таком взаимном положении маршрутизаторы должны производить передачу пакетов от узла-источника к узлу назначения.

Рис. 7-15. Открытая среда с постоянной затухания Рассмотрим для примера взаимное положение узлов согласно рис. 7-16: необходимо передать сообщение от узла 1 к узлу 10, в качестве передающей среды используется радиочастота, все узлы снабжены изотропно излучающей антенной. Желаемый путь должен задаваться конфигурацией маршрутизаторов и проходить через маршрутизаторы 1,2,4. Если применяются конфигурируемые маршрутизаторы LonWorks, то передача происходит по следующему сценарию. Узел 1 (подсеть 1) посылает сообщение на узел 10 (подсеть 100). Следовательно, маршрутизатор должен передать пакет к подсети 100, то есть флаг передачи для подсети 100 установлен. Маршрутизаторы 2 и 3 принимают этот пакет (все еще с адресом назначения «подсеть 100» и источника — «подсеть 1»). Маршрутизатор 3 может затем не передать пакет на основании заданного пути, и в его таблице передачи, таким образом, установлены флаги передачи 100 и 1. Пакет достигает маршрутизатора 2, который снова передает пакет в подсеть 100. Таким образом, маршрутизатор 1 получает отосланный им ранее пакет. Для того чтобы избежать зацикливания, маршрутизатор 1 должен был бы установить в своей таблице флаги передач для подсетей 1 и 100. Но это невозможно, так как в данном случае пакет вообще не сможет быть передан. Итак, становится ясно, что возможности применения маршрутизаторов LonWorks в открытой сети ограничены.

229

Рис. 7-16. Проблемы маршрутизации у конфигурируемого маршрутизатора Вывод: для открытой среды маршрутизаторы LonWorks не применимы, поскольку LonTalk не различает адреса MAC и адреса уровня 3.

7.4.7. Защита данных точка-точка Рассмотрим, каким образом осуществляется защита данных при соединении точка-точка через маршрутизатор. В целом защита данных при соединении точка-точка является задачей уровня 4 (транспортного уровня). Это справедливо и для LonTalk. Защита данных, таким образом, никогда не может быть перенесена на третий уровень. Также ясно, что маршрутизатор не имеет никаких механизмов для защиты данных, так как за нее отвечают узлы-отправители и узлы-получатели (Рис. 7-17).

230

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

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

7.5.1. Физические каналы передачи С помощью конфигурируемого маршрутизатора LonWorks в общем случае допустимы все физические топологии шин при условии, что для соединения между отдельными сегментами шины применяется только этот маршрутизатор (Рис. 7-18).

231

Рис. 7-18. Запрещенные и разрешенные связи сегментов для предотвращения зацикливания

7.5.2. Физические каналы и линии электропередач Физические каналы различаются по следующим критериям: доступны ли узлы в рамках данной среды по отдельности, как, например, это происходит в радиорелейной системе; или узлы связаны открытой средой, как это показано на рис. 7-15. Примечание. Передача данных по линиям электропередач в большинстве случаев происходит так же, как и передача через открытую среду. Однако при этом сигнал подвергается сильным затуханиям, в связи с чем вопрос о топологии зацикливания теряет свою актуальность. Дополнение 1. Речь идет о связи, при которой узлы последовательно соединены друг с другом. В этом случае устанавливать маршрутизатор нецелесообразно. Дополнение 2. Если все узлы доступны через одну и ту оке среду, то маршрутизатор целесообразно устанавливать при необходимости выравнивания затухания и искажения сигнала. Однако для этого должны быть точно известны характеристики применяемых сред, чтобы исключить поведение системы согласно описанному в разделе 7.4.6.

7.5.3. Буферизация сообщений маршрутизатором LonWorks Со стороны приемника маршрутизатор LonWorks имеет в распоряжении 2 входных буфера и переменное количество буферов отправки. Количество буферов с приоритетом равно 2. Количество буферов отправки без приоритета можно изменять, но оно ограничено объемом свободной RAM (максимум 1254 байта).

232 Пригодность данных Для промышленной обработки информации типичной является особенность, состоящая в том, что данные после относительно короткого времени теряют свою актуальность, поэтому они должны не только безошибочно передаваться, но и обрабатываться в течение определенного интервала времени. Это непосредственно приводит к определению реального масштаба времени (Real-time) [Herr91]: Определение. Система называется системой Real-time, если корректность ее работы зависит не только от выходного значения, которое она производит, но и от времени, в течение которого предоставляется это выходное значение. В качестве типичных характеристик способности работы в Real-time часто ошибочно рассматривают быстроту и эффективность. Естественно, обе эти характеристики имеют значение для Real-time систем, но не большее, чем для любых других. Основная характеристика Real-time системы — это предсказуемость поведения во времени. LonWorks изначально не разрабатывалась как Real-time система. Можно лишь теоретически рассчитать вероятность времени реакции, но и в этом случае есть основания говорить, что у LonWorks имеются Real-time характеристики.

7.5.3.1. Функции пригодности График зависимости пригодности данных от времени (функция пригодности) представлен на рис. 7-19. Из него видно, что данные имеют практическую ценность только в течение определенного интервала времени. Значение функции пригодности для маршрутизатора Как показывает функция пригодности, данные должны передаваться в распоряжение узла-приемника в течение определенного интервала времени. В связи с этим особое внимание необходимо обращать на задержку, вносимую LonWorksмаршрутизатором. Задержки в основном происходят тогда, когда скорости портов маршрутизатора значительно различаются. При этом интересен случай, когда данные поступают с высокой скоростью, а отправить их необходимо с низкой скоростью. В этой ситуации для конкретной прикладной задачи очень важно правильно подобрать размер буфера.

233

Рис. 7-19. Функция пригодности для времени завершения процесса по [Herr 91]

7.5.3.2. Правильный выбор размера буфера Для оценки следующий случай:

целесообразного

размера

буффа

необходимо

рассмотреть

Скорость передачи данных порта А :1,25 Мбит/c   ≅ коэффициент130 Скорость передачи данных порта Б : 9,6 Кбит/с  Работающий с частотой 10 МГц MAC CPU Neuron Chip способен обрабатывать около 500 пакетов в секунду. Поскольку пакет может потеряться, то, независимо от скорости передачи данных на шине, максимальная целесообразная пропускная способность также ограничивается 500 пакетами в секунду [Motb94]. Публикации фирмы Echelon по данной теме содержат очень похожие значения [Lont93]. При невысокой скорости передачи данных и длинных пакетах верхняя граница, естественно, снижается: 9,766 Кбит/с в зависимости от величины размера пакета (Таблица 7-2) [Lont93]. Таблица 7-2. Пропускная способность пакетов в секунду в зависимости от объема пользовательских данных 12 байт пользовательских данных

64 байта пользовательских данных

Пропускная способность пакетов Максимально

45

13

В среднем

35

10

Значение для максимальной пропускной способности пакетов можно проверить исходя из следующих предположений. Если в основе лежит PPDU, согласно [Lont96], и предполагают равное распределение β2-слотов (8 слотов), то выдается следующая длина пакета: длина пакета = преамбула + (12 + n)*8*1/(скорость данных) + 8*β2

234 Для канала со скоростью 9,766 Кбит/с можно определить следующие параметры: Raw Data(экран каналов LonBuilder): 0f 0f 10 0e 14

Из этого можно рассчитать, согласно [Lonw95], необходимые для преамбулы и р2-слотов параметры: 1/(скорость данных)

102 Fc

Преамбула

504 Fc

β2

220 Fc

Таким образом: Длина пакета [!c] = 504 !c + (12 + n)*8*1/(скорость данных) + 8*220 !c,

что соответствует максимальной пропускной способности 45 или 15 пакетов в секунду. Если знать оценку среднего значения достигаемой пропускной способности канала при длине пакета с 12 байтами пользовательских данных, то можно подавать на «быструю» сторону маршрутизатора до 500 пакетов в секунду, в то время как на «медленную» — только 35 пакетов в секунду. Поступающие пакеты должны время от времени запоминаться (Рис. 7-20).

Рис. 7-20. Схема буфера для маршрутизатора Функция пригодности предполагает, что данные должны поступить в узелприемник за определенный интервал времени. Это предположение оказывает непосредственное влияние на размер буфера. Имеет смысл запоминать промежуточные пакеты данных до тех пор, пока они не смогут быть отосланы, не принимая во внимание максимально допустимое время задержки. Для этого применяется следующая оценка. Предположение: время задержки маршрутизатора — 0,5 с.

Для целесообразного объема памяти получается: объем памяти = допустимое время задержки * пакетов/с объем памяти = 0,5 с * 45 пакетов/с = 22 буфера.

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

235 маршрутизатора. В большинстве случаев не имеет смысла выбирать количество буферов слишком большим.

7.6. Связь между сетями

7.6.1. Общая постановка вопроса Под «связью между сетями» понимается коммуникационная связь между двумя различными сетями с различными протоколами. ISO/OSI для такого случая предусматривает соединение посредством служб, предлагаемых седьмым уровнем модели — интерфейсом прикладного уровня (ИПУ) (Рис. 7-11). Затраты на реализацию шлюза зависят от того, насколько различны службы, предлагаемые протоколами, которые необходимо связать. В области Fieldbus разница между ИПУ очень велика. Лишь немногие протоколы обладают похожими спецификациями служб уровня 7. В качестве примера здесь можно привести INTERBUS S и PROFIBUS. Обе системы определяют службы, которые предлагают для использования в MAP (Manufacturing Automation Protocol, протоколе производственных сообщений), MMS (Manufacturing Message Service, сервис производственных сообщений). Седьмой уровень в PROFIBUS определяется как подмножество MMS FMS (Field Message Specification, спецификация сообщений filedbus). INTERBUS S используется на уровне датчиков / исполнительных механизмов и определяется на уровне 7 PMS (Peripheral Message Specification, спецификация сообщений периферии) как подмножество MMS и FMS. Поэтому соединение этих систем можно осуществить посредством шлюза с небольшими прикладными затратами. Если необходимо реализовать соединение протоколов, не обладающих вышеприведенными особенностями, необходимо использовать шлюз с большими затратами на приложение (Рис. 7-21). Усложнение прикладной задачи обязательно приводит к увеличению времени реакции. Для достижения меньшего времени реакции нужно существенно увеличивать затраты на аппаратное обеспечение (необходим высокопроизводительный прикладной CPU для обработки протокола коммуникации).

236

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

7.6.2. Связь между LonTalk и PROFIBUS-FMS В данном разделе представлена концепция прикладного шлюза между PROFIBUS-FMS и LON, называемого ProfiLon [Aster93]. Его основная цель — реализовать прозрачный обмен данными между узлами LonWorks и узлами PROFIBUSFMS. Общая схема такого шлюза представлена на Рис. 7-22.

Рис. 7-22. Соединение между LonWorks и PROFIBUS-FMS посредством прикладного шлюза

237 7.6.2.1. PROFIBUS-FMS Стандартизованный DIN 19 245 [Prof91, Pro292] протокол PROFIBUS-FMS предоставляет прикладному процессу ряд мощных служб доступа к переменным, механизм защиты этого доступа, а также позволяет проводить загрузку отлаженных программ с другой станции. Разрешение на отправку в PROFIBUS-FMS регулируется алгоритмом передачи маркера: отправлять данные может только тот узел, который обладает маркером или ожидает ответа на посланный запрос (Рис. 7-23). Станции в логическом кольце называются Master-станциями. Таким образом, не все станции должны реализовывать сложный алгоритм управления маркером: предусматривается наличие простых Slave-станций, способных лишь отвечать на явный запрос Master, не входя в кольцо передачи маркера. PROFIBUS-FMS — это MultiMaster-система, содержащая ряд Slave-устройств. Применяемый метод доступа к шине называется «гибридным».

Рис. 7-23. Доступ к шине PROFIBUS-FMS Определив время, в течение которого должен проходить маркер, можно гарантировать максимальное время реакции. В одном сегменте, который соответствует закрытому кольцу передачи маркера, можно адресовать до 127 узлов, причем в протоколе PROFIBUS-FMS предусмотрены поля для коммуникации с другими сегментами посредством так называемых мостов (см. главу 1, а также [TAN89]). Устанавливаются пять уровней скорости передачи данных: от 9,6 Кбит/с до 500 бит/с. На уровне 2 данные могут передаваться как с подтверждением, так и без него, причем узел назначения может отправить назад, вместе с подтверждением, свои собственные данные. Особый интерес в PROFIBUS-FMS вызывает служба «CSRD» (Cyclic Send and Request Data, Циклическая посылка и запрос данных). При этом на уровне 2 Master хранит список опроса тех станций, которые должны периодически опрашиваться. Затем на заданную станцию Циклически посылаются запросы данных без участия прикладной программы. Протокол прикладного уровня (уровень 7), «Fieldbus Message Specification» (FMS), осуществляет генерацию Protocol Data Units (PDU) и управляет обменом PDU между различным устройствами. Уровень 7 допускает объектно-ориентированный доступ к переменным и берет на себя все детали организации связи, логическую адресацию узлов и физическую адресацию областей памяти.

238 7.6.2.2. Шина ProfiLon Основное назначение ProfiLon — поддержка быстрого обмена простыми значениями переменных (например, положение переключателя или значение их аналогово-цифрового преобразователя) между системами LonWorks и PROFIBUS-FMS. Так как LonWorks и PROFIBUS-FMS применяют различные методы передачи и доступа к шине, а также имеют различное представление пользовательских данных и обработку ошибок, то для соединения интеллектуальных узлов необходимо установить прикладной шлюз. Как будет показано далее, прикладной шлюз между Fieldbus-системами можно реализовать практически прозрачно, причем этот шлюз будет запрашиваться каждой станцией точно так же, как и любой другой узел в той или иной сети. По причине сильного различия между LON и PROFIBUS-FMS, прикладной шлюз должен осуществлять полную замену протокола на уровне переменных. Адрес назначения для каждой из переменных содержится во внешних таблицах и, в соответствии с этими таблицами, шлюз должен передавать модифицированный набор данных в противоположную сеть. Отработка функций сетевого менеджмента (отбор участников, изменение рабочих параметров узла на другой стороне и т. д.) шлюзом не предусматривается. В то время как данные датчиков и исполнительных механизмов относительно легко могут передаваться между двумя Fieldbus-системами, возникают вопросы о способности работы в режиме Realtime, о затратах при обмене данными и поведении системы в случае возникновения ошибок передачи. Представленная далее концепция позволяет проводить обмен данными в обоих направлениях с учетом вышеуказанных обстоятельств. Эту концепцию можно улучшить, если учесть нагрузку шины и время реакции при передаче данных между сетями. Также, ввиду необходимости обеспечения Real-time характеристик всей системы в целом, необходимо проводить целенаправленные исследования работающих в ней прикладных задач. Поскольку две указанные системы довольно-таки слабо связаны на уровне переменных, шлюз можно разделить на два самостоятельных узла сети (Рис. 7-24 и Рис. 7-25). Суммарное время передачи данных из LonWorks в PROFIBUS-FMS включает время передачи от LonWorks к LonWorks, время передачи от PROFIBUS-FMS к PROFIBUS-FMS, а также время обработки данных шлюзом (Рис. 7-25), которым можно пренебречь. 7.6.2.3. Структура ProfiLon В соответствии с выполняемыми задачами, шлюз между PROFIBUS-FMS и LonWorks (ProfiLon) должен быть связан как с PROFIBUS-FMS, так и с LonWorks. Для связи с LON применяется Neuron Chip. С точки зрения стоимости, большой интерес представляла бы реализация протокола PROFIBUS-FMS также на Neuron Chip, что, к сожалению, невозможно в связи со сложностью протокола PROFIBUS-FMS. В этом протоколе необходимо одновременно наблюдать за состоянием множества датчиков и с

239 помощью службы прерываний реагировать на различные события. На стороне PROFIBUS-FMS необходимо обеспечивать скорость передачи от 500 Кбит/с. Поэтому коммуникацию в сети PROFIBUS-FMS должен обеспечивать более мощный процессор, например SAB 80C166 фирмы Siemens. Этот мощный 16-битный CPU (Рис. 7-24) имеет обширную периферию, гибкий механизм обработки прерываний и быстрое переключение задач. Связь обоих процессоров выполняется через параллельный интерфейс Neuron Chip посредством 11 линий ввода/вывода.

Рис. 7-24. Структура ProfiLon Как показано на рис. 7-25, микроконтроллер 80С166, обладающий большим резервом мощности, наряду с коммуникацией с PROFIBUS-FMS, обеспечивает также обмен данными между протоколами LonTalk и PROFIBUS-FMS, Neuron Chip лишь осуществляет связь между LON и 80С166.

Рис. 7-25. Концепция программного обеспечения ProfiLon

240 7.6.2.4. Передача данных из PROFIBUS в LON Подчиненные (Slave) узлы PROFTBUS-FMS не могут самостоятельно передавать свои данные, а должны циклически опрашиваться Master-узлами. Для циклического опроса посредством ProfiLon, который в этом случае выполняет роль Master-узла на стороне PROFIBUS, предлагаются уже упомянутые службы CSRD. Тем самым организация и выполнение циклического опроса собственной программой связи перекладываются на уровень 2 коммуникации PROFIBUS-FMS. Для этого уровню 2 посредством служб CSRD просто передается список опроса с адресами всех соответствующих узлов, в котором также могут находиться и другие Master-станции. Чтобы снизить нагрузку на систему PROFIBUS-FMS, Master-станции не должны вноситься в список опроса, а должны отсылать релевантные данные от себя на ProfiLon. Так,например, изменение положения переключателя может быть зафиксировано Master-устройством благодаря единственному сообщению шлюзу, в то время как для распознавания того же самого события на Slave-узле шлюз должен выполнить цикл запросов/ответов. Чтобы не загружать без необходимости шину в системе LON, из PROFIBUSFMS передаются только те данные, которые изменились со времени последнего опроса. Однако изменение переменной с момента ее последнего опроса можно обработать лишь тогда, когда ProfiLon заполнит таблицу всех тех переменных, которые необходимо передать из PROFIBUS-FMS в LON (Рис. 7-26). В LON связь со шлюзом для узла назначения выглядит точно так же, как и связь с любым другим узлом. Она может программироваться стандартными способами — посредством сетевых переменных.

Рис. 7-26. Поток данных из сети PROFIBUS-FMS в LON

7.6.2.5. Передача данных из LON в PROFIBUS-FMS Присваивание значения сетевой переменной в LON автоматически приводит к рассылке соответствующего сообщения по сети. Поскольку со стороны

241 PROFIBUS-FMS переменные определены, то сообщение, на основании своей связи, оценивается Neuron Chip в шлюзе и передается 80С166. Далее новое значение переменной может перехватить Master в сети PROFIBUS-FMS, либо оно может быть распределено ProfiLon непосредственно на узлы назначения (Рис. 7-27). С точки зрения нагрузки на шину, самостоятельное распределение посредством ProfiLon более выгодно, так как шина становится активной только после изменения переменной на стороне PROFIBUS-FMS.

Рис. 7-27. Поток данных из сети PROFIBUS-FMS в систему LON Если узел назначения в PROFIBUS-FMS, для которого определено сообщение, одновременно является источником данных для системы LON, необходимо выполнить эти два шага раздельно. То есть сначала необходимо послать данные на узел назначения, а затем запросить данные у того же узла. Благодаря упомянутой службе CSRD, можно одновременно с запросом послать также полученные из LONпеременные. Программирование узла-источника LonWorks выполняется стандартным способом. После простого присвоения значений сетевым переменным в Neuron С эти переменные передаются через ProfiLon в PROFIBUS-FMS.

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

242 для прикладной программы. Кроме того, запрошенный узел помечается как «недееспособный» и в дальнейшем опрашивается только пробным методом без повторения отправки. В LON можно получить полное сообщение об ошибке благодаря службе сетевой диагностики.

Рис. 7-28. Ошибка при передаче данных Ситуация, когда данные были успешно отправлены на ProfiLon, но не были переданы от него к приемнику, выглядит сложнее: в этом случае отправитель полагает, что его данные уже успешно отправлены, так как он получил подтверждение (Ack) от ProfiLon (Рис. 7-28). В зависимости от прикладной задачи возможны несколько вариантов реакции на такую ошибку: — Сообщение об ошибке посылается от ProfiLon обратно к отправителю данных. Таким образом, все узлы, которые могут отсылать данные, должны обладать процедурой, принимающей эти сообщения и оценивающей их. Недостатком является увеличение затрат на каждый узел. — ProfiLon не информирует отправителя данных и пытается периодически посылать данные приемнику в другой сети. В этом режиме работы ProfiLon продолжает принимать поступающие данные и общается с каналами, не содержащими ошибки, как обычно. — Если произошла ошибка, ProfiLon посылает определенные сообщения на все узлы, к которым это имеет отношение, чтобы, например, вызвать аварийное выключение машины. Необходимое для этого сообщение определяется при инсталляции сети. — Все сообщения об ошибках протоколируются в ProfiLon. Список этих сообщений можно считывать через сеть по специальному запросу, чтобы проинформировать участника сети об ошибке.

243 7.6.2.7. Адресация пакетов данных Поскольку обе стороны взаимодействуют с ProfiLon как с собственным узлом, то поступающие пакеты данных не могут напрямую адресоваться на узел назначения другой сети, а должны адресоваться на ProfiLon. Таким образом, поступающие пакеты данных не содержат информации, для каких адресатов они предназначены. В ProfiLon для каждой переменной, которую необходимо передать, определяется, для какого узла сети она предназначена. В протоколе, помимо значения переменной, задается вопрос, о какой переменной идет речь. Дополнительные данные в PROFIBUS-FMS обозначаются именем (например, «NC_Status») или бинарным числом, индексом так называемого «обозначения объекта» [Pro291]. В протоколе LonTalk переменные характеризуются исключительно 14-битным двоичным числом, «селектором» в таблице конфигурации сети (см. главу 4, а также [Neurc95, Lonw95]). В дальнейшем мы будем использовать символьные имена переменных, а также символьные адреса отправителей и получателей. На Рис. 7-29 представлена схема адресации и преобразования адреса при передаче потока данных из LON в PROFIBUS-FMS: — В пакетах данных обеих сетей содержится адрес назначения, адрес отправителя, имя переменной и значение переменной. — Если пакет данных адресован на ProfiLon, то значение переменной с помощью добавленного в пакет имени переменной заносится в таблицу переменных. На рис. 7-29 пакет данных от узла LonWorks «L1» доходит до шлюза с LON-адресом «L7». С помощью имени переменной «f» (заданного здесь символически) значение переменной («136») заносится в таблицу переменных. — При отправке значения сетевой переменной далее, в другую сеть, используется определенный посредством таблицы адрес назначения «М4» вместе с новым именем переменной «v».

244

Рис. 7-29. Адресация пакета данных На рис. 7-29 показано направление потока данных от LON к PROFIBUS-FMS; адресация в обратном направлении осуществляется по аналогичной схеме. Благодаря содержащейся в ProfiLon таблице замещений, определяется однозначное соответствие между адресами узлов и именами переменных. Эта таблица замещений специфична для прикладной задачи и должна разрабатываться на этапе проектирования сети.

7.6.2.8. Фаза инициализации Особое внимание в данной концепции объединения сетей необходимо уделять фазе инициализации. На момент включения ProfiLon, в зависимости от обстоятельств, обе сети (LON и PROFIBUS-FMS) уже могут быть активны сколь угодно долгое время. Для ProfiLon это означает, что он должен вначале определить все значения сетевых переменных для той или иной сторон сети. Использование переменных на стороне PROFIBUS-FMS сложностей не представляет, так как ProfiLon запрашивает переменные при циклическом прохождении списка опроса. После первого полностью выполненного прохода списка опроса ProfiLon знает все переменные со стороны PROFIBUS-FMS. Путем установки специального флага необходимо позаботиться о том, чтобы все поступающие переменные при первом проходе списка опроса передавались на систему LON (в противном случае системе LON будет сообщено только об изменении переменных). Иначе выглядит ситуация на стороне LON: здесь все станции сообщают свои переменные только при изменении их значения (Event Driven). Поскольку это никак не связано с включением ProfiLon, необходимо сначала явно запросить у всех узлов их переменные. Для стороны LON также должен предоставляться список опроса, согласно которому будут опрашиваться узлы при включении ProfiLon.

245 По окончании фазы инициализации система переходит в нормальное рабочее состояние.

7.6.2.9. Резюме При соединении различных систем Fieldbus необходимо осуществлять полную замену одного протокола на другой, что возможно только на уровне переменных. Прикладные данные должны выделяться из пакетов одного протокола, а затем упаковываться в пакеты другого. ProfiLon требует наличия Master-устройства на стороне PROFIBUS-FMS, собирающего данные от подчиненных устройств и передающего их на сторону LON. Вновь поступающие из системы LON переменные самостоятельно распределяются Master-устройством в ProfiLon на соответствующие узлы. На стороне LON для обработки протокола LonTalk применяется только Neuron Chip. Таблицы адресации и сетевых переменных, поддерживаемые ProfiLon, позволяют шлюзу быть практически прозрачным для обеих сетей и служат для уменьшения нагрузки на шину. ProfiLon обладает всей относящейся к объединению информацией, и остальные узлы сети не нуждаются в специальном программном обеспечении.

7.6.3. Связь между LonTalk и HTTP

7.6.3.1. HTTP Протокол передачи гипертекста (Hypertext Transmission Protocol [Http96]) служит для обмена информацией между компьютерами в World Wide Web. Наиболее важной задачей этого протокола является обеспечение доступа Web-клиентов к данным и программам Web-сервера, в связи с чем HTTP называют протоколом клиент-сервер (Рис. 7-30).

Рис. 7-30. Функционирование протокола HTTP no принципу клиент-сервер Концепция HTTP такова, что сервер не запоминает состояния сеанса связи, что увеличивает его производительность. С помощью HTTP можно передавать бинарные 8-битные данные —

246 исполняемые программы, графические изображения, HTML-страницы и т. д. [Http96]. Согласно протоколу HTTP, передача выполняется в четыре этапа: 1. Клиент открывает связь с сервером, точно адресованным URL (Uniform Resource Locator). 2. Клиент посылает серверу запрос, который состоит из request header (заголовка запроса) и каких-либо данных (типичный request header вызывает такие методы, как GET или POST). 3. Сервер посылает клиенту ответ, который состоит из response header (тип посланных данных, сообщения об ошибках и т. п.), а также запрошенных клиентом данных. 4. Клиент завершает связь и, начиная с этого момента, сервер «забывает» о нем. Классический пример HTTP-связи — это работа с документами WWW. Например, домашняя страница содержит три картинки. Специальная программа browser, являющаяся в данной ситуации клиентом, должна открыть четыре HTTPсоединения: одно — для HTML-данных и три — для загрузки графических изображений.

7.6.3.2. Задачи LonHttp LonHttp полностью отличается от ProfiLon (см. предыдущий раздел). Речь идет уже не о двух системах Fieldbus, соединенных друг с другом, а о связи совершенно различных сетей: Global Area Network (Internet) и Field Area Network (LON). Поэтому в системе LonHttp не ставится задача обмена значениями переменных; вместо этого LonHttp осуществляет подготовку и передачу данных из World Wide Web в LON. Одновременно этот шлюз позволяет представлять данные LON в распоряжение любым Web-серверам, чтобы, например, можно было представить отчет о работе LON на Webстранице. В этой связи необходимо определить время реакции LonHttp, поскольку HTTP работает через TCP/IP и тем самым не может гарантировать быструю реакцию. Об этом всегда необходимо помнить при проектировании той или иной системы.

7.6.3.3. Структура LonHttp LonHttp необходимо подключать как к LON, так и к Internet. Эту задачу можно реализовать в виде LON-узла, функционирующего в Internet (микропроцессор, состоящий из внешней RAM и Neuron Chip для поддержки LonTalk, а также модем или контроллер Ethernet). Однако такая схема приводит к слишком большим затратам. Решение, которое, с одной стороны, можно реализовать с небольшими затратами и функциональность которого, с другой стороны, немного ограничивает область

247 применения LON, — это обычный персональный компьютер. Прежде всего, персональный компьютер позволяет считывать и записывать данные LON — назовем здесь только службы сети LonWorks (LNS, см. раздел 8.3) или LonManager DDE-Server. Значения переменных LON предоставляются разработчикам программ в удобном виде, и большинство сред разработки языков высокого уровня (С, C++, Basic, Pascal) поддерживают механизмы такого обмена данными. ПК также позволяет осуществлять простой доступ к Internet. В том случае, если разработка ведется под MS-Windows (а мы будем рассматривать LonHttp как прикладную задачу Windows), то имеется доступ к TCP/IP и UDP, так как механизм Winsockets является стандартным API для программирования Internet-приложений. На уровень 4 можно установить протокол Internet Suite, что еще более упрощает разработку прикладной программы для Internet (HTTP необходимо рассматривать как протокол уровня 7, поэтому программирование уровня 4 было бы связано со значительными затратами). Разработанная фирмой Microsoft® 32-битная платформа Windows (Windows 95) поддерживает наиболее часто используемые протоколы Internet (FTP, Gopher, HTTP) непосредственно на 7-м уровне. Эта поддержка является расширением функций Win32. Можно предположить, что набор Win32 Internet Functions будет развиваться и дальше [Wini96]. Таким образом, прикладная программа получает удобный доступ как к LON, так и к World Wide Web. Поскольку Win32 Internet Functions являются относительно новыми функциями, на сегодняшний день их можно использовать только в программах на языке С. Надо заметить, что в языке С существует удобный интерфейс к LON. На рис. 7-31 показано схематическое построение LonHttp.

Рис. 7-31. Построение LonHttp как 32-битной прикладной задачи Windows

7.6.3.4. Передача данных от HTTP к LON При организации передачи данных World Wide Web в LON необходимо рассматривать два случая. Во-первых, LON может запрашивать данные из WWW, то есть осуществлять чтение из WWW определенной сетевой переменной. Этот случай отрабатывается специальной процедурой программы шлюза (ПК), которая загружает желаемую Webстраницу, отфильтровывает соответствующие данные, форматирует их и записывает в сетевую переменную. Во-вторых, LON может принимать данные, не запрашивая их.

248 При этом возникает вопрос об отправителе: кто может или хочет пересылать данные из Internet в LON? Речь может идти о специально разработанной для этой цели программе, функционирующей на другом Internet-компьютере, о JAVA-приложении или просто о LON. Второй случай отличается от первого тем, что требуются дополнительные затраты на шлюз. Шлюз должен реагировать на поступающие запросы на запись и задавать новые значения соответствующим сетевым переменным. Эта задача весьма сложна и, поскольку речь идет об особой области Windows-программирования, ее реализация здесь не описывается. Упомянем лишь о возможности использования Windows Sockets API. Хорошее введение в программирование с Windows Sockets API содержится, например, в [Prog96].

Рис. 7-32. Доступ на чтение из LON в WWW посредством LonHttp Рассмотрим первый случай: узел LON хочет считать значение с определенной страницы Web. В начале процесса шлюзу необходимо сообщить, что требуется определенная величина (Рис. 7-32) (1). Ее фактическое значение сообщается LON-узлу позднее, после успешного считывания Web-страницы. Это означает, что, ожидая считывания какой-либо величины из WWW, сначала необходимо изменить соответствующую сетевую переменную (тем самым шлюз получает задание загрузить Web-страницу), а затем получить желаемые данные, используя when-директиву OnNetworkvariableUpdate_occurs (см. главу 6) (3). При этом существуют различные возможности выделить требуемые данные из полученных: шлюз может возвращать запрос (который принимает значение 1 и 0) в одном из битов считанной сетевой переменной либо может использовать двойные счетчики, хранящие число запросов и число принятых пакетов данных. 7.6.3.5. Передача данных от LON к HTTP Данное направление передачи информации используется, например, для сообщения состояния системы через Web-интерфейс или для запросов доступа на чтение. Необходимо упомянуть о том, что получателем таких данных должна быть специально разработанная программа. Можно использовать Common Gateway Interfaces (CGI), который представляет собой широко распространенный и относительно простой

249 метод Internet-коммуникации. Принцип CGI состоит в следующем: Web-окно просмотра получает от Web-сервера специальную форму, которую заполняет пользователь. Программа просмотра (browser) посылает серверу все содержимое этой формы, добавляя его к адресу сервера (URL); в качестве разделителя используется знак вопроса (?). В адресе назначения, согласно этому, содержится информация, которую необходимо передать. Создать CGI-приложение для LonHttp довольно просто: нужно действовать так же, как и в случае обычного CGI-программирования. Шлюз LonHttp должен распознать структуру передаваемых данных и соответствующим образом обработать их. Если узел LON присваивает некоторое значение сетевой переменной, принадлежащей WWW, то LonHttp запрашивает с соответствующего Web-сервера форму, заносит в нее величину, полученную из LON, и отправляет обратно на сервер. Существует и другая возможность принимать данные, посланные LON через Internet: в том случае, если необходимо обойтись без Web-сервера, можно использовать Windows Sockets API. Однако при этом необходимо учесть повышенные затраты на разработку (по сравнению с CGI). 7.6.3.6. Адресация Для считывания данных LON из World Wide Web шлюзу необходимо сначала выставить требование на чтение, после чего получить желаемое значение. Использовать для чтения данных прямой доступ к сетевой переменной нельзя. Шлюз LonHttp имеет внутреннюю таблицу, которая содержит соответствие переменных LON данным WWW. На рис. 7-33 показан пример такой таблицы: для каждой сетевой переменной, соответствующей WWW-данным (она должна быть определена во время разработки узла LON), выделяется Uniform Resource Identifier (URI) [Http96]. URI состоит из WWW-адреса, а также «имени» данных; эта информация предназначена для однозначной идентификации местоположения данных в Internet. Вместе с определением HTTP-протокола (заданного жестко) в качестве передающего механизма UPJ образует URL (Uniform Resource Locator) [Http96], который необходим для корректного определения адреса и передачи информации. Таким образом, URL содержит протокол, имя компьютера и указание на данные. Например, под «http://www.ict.tuwien.ac.at/index.html» подразумевают файл «index.html» на компьютере «www.ict.tuwien.ac.at», подлежащий передаче посредством протокола HTTP. Несмотря на то, что URL необходим, он недостаточен для полной спецификации местоположения отдельного значения. В таблице на рис. 7-33 справа, рядом с URI (WWW-адресами), находятся данные, которые необходимо интерпретировать. При этом интересна позиция значения внутри этих данных. Достаточно задать длину данных, которые необходимо прочитать, а также формат (целые числа, числа с плавающей точкой, ASCII-текст и т. п.), для чтения достаточно указать длину данных и формат. Следующей

возможностью

адресации

в

LonHttp

является

передача

250 вышеупомянутой таблицы в LON. Если LON-узел хочет считать данные из WWW, то он прежде всего должен занести в собственную определенную для этого переменную адрес назначения с позицией, длиной и форматом. Надо заметить, что это уже противоречит принципу «незаметного» шлюза, который не должен требовать от отдельного LON узла слишком больших затрат на обработку. При обратном направлении передачи (компьютер в WWW читает данные из LON) адресация происходит по схеме, аналогичной изображенной на рис. 7-33. В том случае, если CGI пытается получить значение из LON, LonHttp сравнивает адрес компьютера с адресом во внутренней таблице; если позиция, длина и формат HTMLэлемента [Http96] также совпадают, то можно выполнять передачу данных.

Рис. 7-33. Структура таблицы адресов LonHttp 7.6.3.7. Вопросы безопасности При передаче данных по сети особое внимание необходимо уделять вопросам безопасности. В данном случае безопасность имеет два аспекта. С одной стороны, речь идет о том, каковы будут последствия, если пакет данных не поступит к приемнику в течение заданного интервала времени. С другой стороны, существует проблема достоверности данных. Первый вопрос не относится к LonHttp. Временные интервалы должна отслеживать прикладная программа, применяющая LonHttp для передачи данных через Internet. Это особенно необходимо в связи с тем, что существующие Internet-протоколы едва ли удовлетворяют критериям Real-time. Вопрос о достоверности данных включает две стороны: защищенность данных и аутентификация (определение достоверности происхождения данных [Sec95]). Существует достаточно большое число алгоритмов [Cryp94], которыми могут пользоваться LonHttp и CGI (наиболее целесообразным выглядит применение метода IDEA ввиду простоты его реализации) [Sec95, Cryp94]. При этом таблица адресов LonHttp увеличивается на длину различных ключей, а соответствующие CGI-программы усложняются. Не стоит также забывать о будущих версиях протокола HTTP и возможности реализации механизма защиты в его рамках. Прежде чем тратить большие усилия на защиту данных в LonHttp, желательно дождаться результатов работы различных комитетов по стандартизации Internet и его программного обеспечения.

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

8.1. Аспекты сетевого менеджмента Главная цель сетевого менеджмента — предоставление определенных интерфейсов доступа к сети или интерфейса сетевого программирования. Полная концепция менеджмента охватывает широкий спектр функций и ресурсов, таких, например, как технические системы, инструментарий менеджмента программного обеспечения, персонал и программы менеджмента. Чтобы представить себе технический менеджмент, рассмотрим различные независимые друг от друга аспекты сетевого менеджмента [Heg 93]: Функциональный аспект Упорядочение задач сетевого менеджмента по функциональному аспекту приводит к выделению различных функциональных групп. Согласно ISO [IS07498-4], функции менеджмента разделяются на следующие группы: — задачей конфигурационного менеджмента является управление логическими связями между распределенными ресурсами в сети. Конфигурационный менеджмент охватывает хранение конфигурации сети и управление ею 1

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

252 (топологией сети, данными об активных и неактивных в определенный момент узлах и сетевых компонентах, сетевыми параметрами и сетевыми связями). Еще одна важная функция конфигурационного менеджмента — присваивание имен. Процесс конфигурации влияет на логические связи между ресурсами сети и контролирует размещение в ней ресурсов, распределенных по физической сети, лежащей в ее основе. Итоговая конфигурация сети должна как можно лучше соответствовать требованиям пользователя сети и сетевым прикладным задачам; — менеджмент ошибок можно назвать важнейшим компонентом менеджмента, с помощью которого достигается высокий уровень доступности сети. Обычно менеджмент ошибок состоит из набора функций для распознавания, разграничения и исправления неправильного функционирования, которое может произойти вследствие ошибок проектирования и реализации, ошибок перегрузки, внешних помех и старения; — менеджмент производительности используется для улучшения качества сетевых служб. Частная задача менеджмента производительности — определение параметров качества услуг и наблюдение за коммуникационными службами. Задачи менеджмента производительности затрагивают также планирование ресурсов сети; — менеджмент учета охватывает набор методов и средств для сбора необходимых данных и для перерасчета использования сетевых ресурсов. Другая частная задача менеджмента работоспособности — ведение счетов, распределение стоимости между службами и пользователем и др.; — менеджмент безопасности используется при обмене соответствующей информацией. Инструментарий менеджмента безопасности предлагает администратору сети доступ к функциям, обеспечивающим защиту от сбоев в работе сети и от несанкционированного доступа к ней. Аспекты жизненного цикла Аспекты жизненного цикла сети можно охарактеризовать размещением задач менеджмента во времени. Различаются три фазы жизненного цикла: планирование, реализация и работа. Анализ хода выполнения задач менеджмента во времени показывает, что на каждой из трех фаз возникают различные задачи управления сетью. Исходя из этого, каждой фазе жизненного цикла соответствуют различные задачи менеджмента.

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

253 различаются по объектам назначения. Задачами прикладного и системного менеджмента являются управление прикладной задачей или системой. Менеджмент предприятия рассматривается в иерархии сценариев как высший. Он частично включает аспекты сценариев менеджмента, которые задаются менеджментом сети, прикладной задачи и системного менеджмента, рассматриваемые в контексте предприятия. На рис. 8-1 представлен выполненный сценарий сетевого менеджмента.

Рис. 8-1. Уровни интегрированной системы менеджмента [HeN 96]

8.2. Архитектура сетевого менеджмента LON Архитектура сетевого менеджмента LON представляет собой общую схему, в которую должны вписываться многие из вышеназванных аспектов. Только многосторонняя архитектура менеджмента позволяет концептуально охватить различные функции системы менеджмента сети при конкретных требованиях предприятия. Модель архитектуры сетевого менеджмента согласно [Heg 93] Объекты менеджмента представляют собой абстракции характеристик ресурсов, которыми оперирует менеджмент. Информационная модель специфицирует схему моделирования и схему определения объекта менеджмента, предусмотренного в сети. Информация, описанная в информационной модели, охватывает только параметры, относящиеся к менеджменту: тип узла, параметры конфигурации, функции менеджмента и многие другие. С точки зрения менеджмента, из информационной модели можно выяснить реальные ресурсы аппаратного и программного обеспечения (информация менеджмента). Информационная база данных менеджмента (Management Information Base, MIB) содержит всю необходимую информацию о менеджменте сети. Эта база данных определяет описание структуры информации менеджмента, а также методы доступа к ресурсам, имеющим к нему отношение. Для

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

Модель сетевого менеджмента LON Информационная модель в LON описывает сетевые компоненты (узлы сети, повторители, мосты, маршрутизаторы), конфигурационные параметры (домены, каналы коммуникации, подсети, логические связи между распределенными приложениями, сетевые адреса и сетевые топологии), а также прикладные программы (коммуникационные объекты и библиотеки программ). Подробности о вышеназванных объектах можно узнать из главы 4, а также из [LONW 96, LONTALK, LONTR 93]. Сейчас рынок предоставляет разнообразные программные инструментарии сетевого менеджмента LON, основывающиеся на различных аппаратных и программных платформах. Некоторые наиболее важные примеры инструментариев сетевого менеджмента LON-это LonBuilder, LonMaker-Manager, MetraVision, Easylon, ALTO, IEC, Qlon, Response и Arigo-Software (подробности об инструментариях сетевого менеджмента LON см. в главе 13). Большая часть перечисленного инструментария сетевого менеджмента базируется на программном обеспечении LonManager-API, которое предоставляет в распоряжение набор библиотек программ и банк данных dBVista, способный работать под операционной системой MS-DOS. Доступ к реальным ресурсам в сети возможен в программном обеспечении API на уровне расширенного набора функций (библиотек программ C++) или на базе уровня 7 (Рис. 8-2).

255

Рис. 8-2. Структура программного обеспечения сетевого менеджмента LonManager-API Так как информационная база данных менеджмента точно не определена, то функции сетевого менеджмента, а также информация менеджмента в инструментариях сетевого менеджмента разных производителей определяются по-разному. Это приводит к тому, что системы сетевого менеджмента не могут работать вместе, и информация менеджмента между различными инструментами оказывается несовместимой. Единственный из множества инструментов, базирующихся на LonManager API, который поддерживает структуры данных, — «Network Variable External Interface Data» (.XIF-данные). В XIF-данных содержатся конфигурационные параметры сети и относящиеся к узлу сетевые переменные, а также явные сообщения [HostAp 93]. Наряду с описанной информационной моделью менеджмента LON, базирующейся на платформе LonMaker API, рынок предлагает инструментарии сетевого менеджмента, построенные на собственной информационной модели. Как пример такой платформы сетевого менеджмента LON, построенной на собственной концепции программного обеспечения информационной модели и реляционном банке данных, доступном благодаря ODBC (Open Data Base Connectivity), можно упомянуть программное обеспечение NodeTalk. Информационная модель менеджмента LON нового стандарта определена в архитектуре сетевых служб LonWorks (LNS) [Strat 96]. В LNS-архитектуре различаются две информационные модели менеджмента. Первая из них — платформа LonManagerNSS-10 — содержит необходимые для сетевого менеджмента данные в банке данных, расположенном в находящейся на карте NSS-10 рабочей памяти размером 128 байт. Изза размера памяти в системе, базирующейся на NSS-10, приходится значительно ограничивать информацию менеджмента о параметрах конфигурации, а также о состоянии узла. Точнее говоря, в базе данных менеджмента модуля NSS-10 можно определить информацию о 62 узлах, 31 программе (могут загрузиться в узел), 383

256 логических связях, 767 сетевых переменных (по 255 переменных на узел максимум), 1 домене и 1 NSS-10-модуле. NSS-10-модуль, наряду с его функциями сетевого менеджера, может также выполнять одну или несколько функций управления, измерения или регулирования. Актуальная информация менеджмента в базе данных NSS-10 об управляемых объектах предоставляется в распоряжение прикладной программе хост-процессора (Рис. 8-3) посредством свойств самих объектов (properties). Свойства объектов менеджмента, требующих управления, делают возможным не только пассивный сбор данных, но и прямой доступ к реальным объектам в сети.

Рис. 8-3. Архитектура программного и аппаратного обеспечения сетевого менеджмента на базе NSS-10 Следующая форма информационной модели менеджмента архитектуры сервера сетевых служб Lon Works (NSS) функционирует на платформе программного обеспечения, созданного для Windows 32 (LNS Developer's Kit для Windows). Банк сетевых данных NSS для Windows поддерживает следующие объекты менеджмента: — домен; — все находящиеся в домене узлы аппаратного обеспечения; — до 32 395 типов прикладных узлов; — до 1000 коммуникационных каналов; — до 1000 узлов-маршрутизаторов;

257 — до 12288 сетевых переменных селекторов связи (селекторов переменных); — до 62 сетевых переменных узлов, находящихся в нейронном чипе; — до 4096 сетевых переменных LON-узлов, находящихся в хост-процессоре; — до 254 устройств типа LNS-клиент на других LON-узлах; — данные о сервере NSS для Windows и сервере объектов архитектуры компонентов LonWorks (LonWorks Component Architecture, LCA). Доступ к объектам сетевого менеджмента сервера сетевых служб для Windows выполняется с помощью функций сетевых служб API2. Дополнительно к уровню сетевых служб, платформа LNS для Windows включает еще сервер объектов архитектуры компонентов LonWorks (LCA). LCA определяет OLE-интерфейс3 для доступа к сетевым службам и предлагает стандартный Windows-нтерфейс для связи сетевого инструментария, а также для устройств мониторинга, управления и регулирования от различных производителей. Интерфейс LCA-объект-сервер формирует ядро программного обеспечения, предлагающего методы, свойства и события интерфейса программирования, базирующегося на OLE-объектах. Эти объекты берут на себя частные функции сложного процесса менеджмента, такие, например, как инсталляция, мониторинг, обслуживание, а также управление базирующимися на LON системами. Программное обеспечение LCA-объект-сервер выполняет задачу управления объектами сетевого менеджмента, причем поддерживается многозадачное выполнение нескольких функций прикладной задачи на одном и том же объекте. Общий уровень объектов (Рис. 8-4) содержит расширяемый банк Данных хоста, который управляет относящимися к LCAфункциям данными. Банк данных хоста содержит имена объектов, bitmap-изображения, объекты LonMark, документацию для сетевых компонентов, свойства конфигурации, сетевые переменные. Кроме того, банк Данных хоста включает шаблоны аппаратного обеспечения, атрибуты сетевых компонентов пользовательской программы, а также функциональные профили LonMark с описанием стандартизированных объектов LonMark и специфики конфигурации многочисленных стандартных сетевых компонентов. Важной особенностью банка данных хоста является разрешение на доступ к данным менеджмента и их параллельное использование для всех прикладных задач LCA. Банк данных хоста при необходимости может расширяться данными, зависящими от производителя.

2 3

API — Application Programming Interface. OLE — Object Linking and Embedding.

258

Рис. 8-4. Структура интерфейсной модели LCA Коммуникационная модель архитектуры менеджмента LON Так как задачи сетевого менеджмента охватывают управление пространственно распределенными ресурсами, то сетевой менеджмент сам по себе является, очевидно, распределенным устройством. Коммуникация для задач менеджмента может основываться на различных механизмах обмена специфичной информацией. Различают в основном три вида обмена информацией менеджмента: обмен информацией за счет опроса статуса ресурсов; обмен управляющей информацией между инстанциями сетевого менеджмента и объектом менеджмента, который должен активно воздействовать на ресурсы; а также обмен сообщениями о событиях. Коммуникационная модель архитектуры сетевого менеджмента определяет обменивающиеся информацией инстанции и определяет коммуникационные службы и протокол менеджмента. Протокол LonTalk предусматривает всестороннюю концепцию коммуникационной модели сетевого менеджмента и сетевой диагностики. В нем определяются специальные типы сообщений (сообщения сетевого менеджмента, сообщения сетевой диагностики, сообщения сервисных кнопок и сообщения конфигурации маршрутизатора). Функции сетевого менеджмента построены на сообщениях сетевого менеджмента и диагностики. В разделе 4.10 были перечислены все поддерживаемые коммуникационными службами сообщения сетевого менеджмента и диагностики вместе с их синтаксисом. Эти функций менеджмента основываются на различных видах обмена сообщениями. В случае сообщения сервисной кнопки, обмен данными менеджмента управляется событиями, причем при сообщении для обработки таблицы конфигурации, как, например, «Update Address» он выполняется благодаря отсылке управляющей информации для переписывания EEPROM. В LonTalk также специфицированы сообщения сетевого менеджмента, которые инициируются статусным опросом о ресурсах. Например, для службы сетевого менеджмента, базирующейся на опросе статуса, можно назвать «Query Address». Большинство

259 сообщений сетевого менеджмента и диагностики используют службы протокола типа запрос/ответ на сеансовом уровне. В разделе 4.10 перечислены также все функции сетевого менеджмента и сетевой диагностики. Для всех типов сообщений, использующих службу запрос/ответ, протокол LonTalk определяет соответствующие типы для ответных сообщений об успешном выполнении программы или возникновении ошибок. Таблица 8-1 содержит все сообщения сетевого менеджмента и диагностики, базирующиеся на службе запрос/ответ. Сообщения сетевого менеджмента, которые не поддерживают службу запрос/ответ, могут быть обработаны службами нижних уровней, такими как Acknowledged, Unacknowledged/Repeated или Unacknowledged. Исчерпывающее описание сообщений сетевого менеджмента было приведено в разделе 4.10 (протокол LonTalk — сетевой менеджмент — сетевая диагностика). Базирующиеся на коммуникационных службах запрос/ответ сообщения сетевого менеджмента и сетевой диагностики и относящиеся к ним коды сообщений (Рис. 4-28. Кадр APDU) представлены в следующей таблице. Таблица 8-1. Коды LonTalk сообщений сетевого менеджмента и сетевой диагностики, посылаемых с помощью служб запрос/ответ Сообщения сетевого менеджмента

Код запроса

Query ID

0x61

Код успешного ответа 0x21

Код ответного сообщения об ошибке 0x01

Respond to Query

0x62

0x22

0x02

Update Domain

0x63

0x23

0x03

Leave Domain

0x64

0x24

0x04

Update Key

0x65

0x25

0x05

Update address

0x66

0x26

0x06

Query Address

0x67

0x27

0x07

Query Net Variable Config

0x68

0x28

0x08

Update Group Address Data

0x69

0x29

0x09

Query Domain

0x6A

0x2A

0x0A

Update Net Variable Config

0x6B

0x2B

0x0В

Set Node Mode

0x6C

0x2C

0x0C

Read Memory

0x6D

0x2D

0x0D

Write Memory

0x6E

0x2E

0x0E

Checksum Recalculate

0x6F

0x2F

0x0F

260 Wink

0x70

0x30

0x10

Memory Refresh

0x71

0x31

0x11

Query SNVT

0x72

0x32

0x12

Network Variable Fetch

0x73

0x33

0x13

Device Escape Code

0x7D

0x3D

0x10

Query Status

0x5

0x3

0xl

Proxy Command

0x52

0x32

0x12

Clear Status

0x53

0x33

0x13

Query XCVR Status

0x54

0x34

0x14

Примечание. Код ответного сообщения неоднозначен: он интерпретируется согласно ранее посланному запросу. (Подробное объяснение представленных кодов сообщений в разделе 4.10.) Согласно модели менеджмента OSI [IS07498-4], различают три механизма для обмена информацией менеджмента: — межуровневый менеджмент: коммуникация выполняется между процессами приложений менеджмента 7-го уровня. Обмен информацией предусматривает полный набор функций открытой коммуникационной системы (OS1), то есть 7 уровней; — уровневый менеджмент: обмен информацией менеджмента производится между специфическими инстанциями уровней. Рассматриваются функции и службы, которые специфичны для определенного уровня и не требуют служб верхних уровней. Как типичный пример, можно назвать протоколы обмена информацией маршрутизатора; — менеджмент протокола: функции менеджмента, которые являются составными частями протокола определенных уровней, такие как установка таймера и обмен параметрами протокола на фазе построения связи, поддержка обмена данными менеджмента между уровнями протокола. Помещение в протоколы уровней элементов, близких по своим функциям к менеджменту, завоевало большую популярность при раннем развитии коммуникационных систем (например, ATM, FDDI, DQDB). Вышеназванными видами коммуникации сетевого менеджмента протокол LonTalk обеспечивает только уровневый менеджмент. Сообщения сетевого менеджмента и сетевой диагностики основываются на службах сеансового уровня (службы запрос/ответ) или на службах транспортного уровня (коммуникационные

261 службы с подтверждением, без подтверждения, без подтверждения, с повторением). В качестве основного отличия LonTalk от модели менеджмента OSI можно привести слабую связь между сообщениями сетевого менеджмента, сетевой диагностики и функциями нейронного чипа. Большинство служб сетевого менеджмента протокола LonTalk перепроверяют или модифицируют область памяти нейронного чипа, так что архитектура сетевого менеджмента LON может эффективно применяться без последующих семантических модификаций ресурсов нейронного чипа. Функциональная модель Функциональная модель архитектуры менеджмента объединяет все области менеджмента в функциональные группы (например, менеджмент конфигурации, менеджмент ошибок, менеджмент защиты и др.). После этого функции менеджмента упорядочиваются с целью получения общей функциональной модели с определенными частными решениями. Функциональная модель менеджмента LonWorks может рассматриваться на двух уровнях. На уровне служб сетевого менеджмента и сетевой диагностики идентифицируются следующие восемь функциональных областей: — сообщения сетевого менеджмента для идентификации узла; — сообщения сетевого менеджмента для обработки таблицы домена; — сообщения сетевого менеджмента для обработки таблицы адресов; — сообщения сетевого менеджмента для обработки сетевых переменных; — сообщения сетевого менеджмента для обработки памяти узлов сети; — сообщения сетевого менеджмента для особых задач; — сообщения сетевого менеджмента для маршрутизатора; — сообщения сетевой диагностики. Подробное их описание см. в разделе 4.10. Группировка функций сетевого менеджмента в функциональные области на уровнях Приложения менеджмента требует применения другой концепции для функций менеджмента. В вобщем случае службы инструментария, базирующегося на LON, поддерживают инсталляцию и конфигурацию узлов, загрузку прикладной задачи в узел сети и мониторинг шины. Инструментарий сетевого менеджмента LON является широким понятием для обозначения нескольких различных приложений. У существующего инструментария сетевого менеджмента LON можно различить функции инсталляции, диагностики и обслуживания, а также частные функции создания программ.

262 Архитектура LNS предоставляет возможность разделения областей (групп). В будущем она должна служить базисом для разработки совместимых сетей. Используемые LNS для Windows объектно-ориентированные оболочки приложений базируются на архитектуре компонентов LonWorks (LonWorks Component Architecture, LCA). Программное обеспечение LCA группирует сетевые ресурсы, а также функции менеджмента на иерархически упорядоченные классы объектов (Рис. 8-5). Для каждого объекта также определены методы и свойства. Можно перечислить следующие функциональные области из описания LCA: — доступ к сетевым переменным; — обработка ошибок; — декларирование и доступ к объектам LON; — программирование сетевых компонентов; — инсталляция сетевых компонентов.

263

Рис. 8-5. Иерархия объектов в LCA Организационная модель Организационная модель архитектуры менеджмента определяет действующие компоненты, их роли и основные принципы их взаимодействия. В модели клиентсервер для каждой формы взаимодействия различаются постановщик задачи (клиент) и исполнитель (сервер). Недавно начали разрабатываться полностью симметричные формы взаимодействия сетевого менеджмента, которые исходят из взаимодействия и коммуникации между принципиально одинаковыми объектами [MoZ 93].

8.3. Сетевые службы LonWorks Профессиональный сетевой менеджмент немыслим без соответствующего специального инструментария. Такие виды деятельности, как инсталляция, обслуживание и наблюдение, требуют от инструментариев относительно большой мощности. Если затем необходима визуализация поступающих из сети LON данных, то у большинства инструментов сетевого менеджмента спектры мощности могут оказаться уже исчерпанными. Более того, требуется Построение гибких совместимых решений, которые по своим возможностям должны иметь Доступ к банкам данных и обнаруживать по индивидуальным потребностям соответствующую пользовательскую надстройку. Индустрия программного обеспечения предлагает множество мощных

264 инструментариев, которые в некоторых случаях сокращают затраты на разработку. Однако к давно решенным задачам сетевого менеджмента постоянно добавляются новые, что обусловило тенденцию разработки индивидуального программного обеспечения. Одна из причин постоянного расширения области задач инструментариев сетевого менеджмента — это увеличивающееся количество узлов в современной управляющей сети: их пятизначное количество сегодня уже не является редкостью. Так, понятие сетевого менеджмента получает совершенно новое значение. Однако речь идет о том, чтобы с помощью различных инструментов (ручных устройств, переносных персональных компьютеров, программного обеспечения дистанционного обслуживания и т. д.) реализовать одновременно задачи обработки, обслуживания, визуализации и наблюдения. Ключ к реализации такого инструментария — это концепция, которая наилучшим образом зарекомендовала себя при сетевом объединении компьютеров: архитектура клиент/сервер. Эта концепция рассматривается как стандарт для сетей данных.

8.3.1. Архитектура клиент/сервер в LON Под архитектурой клиент/сервер понимают концепцию разделения компьютеров (в LON это в основном узлы) на серверы и клиентов — сервер предоставляет клиентам свои службы. Если клиенту требуется услуга, то сервер выполняет ее и затем сообщает клиенту о возможном ответном значении или ошибке. Такую архитектуру можно найти, например, в Internet Browsers, с помощью которых можно искать информацию в World Wide Web (WWW). В разделе 7.8.3 объясняется используемый в этом случае протокол — протокол передачи гипертекста; это хороший и простой пример связи типа клиент/сервер в сети данных (в этом случае речь идет об Internet): Web-Browser (также называемый Web-клиент) требует от Web-сервера данные, и по истечении некоторого времени ожидания получает либо желаемые данные, либо сообщение об ошибке. Более сложным примером является так называемая Chat-служба, которую предлагают некоторые провайдеры Internet: эта служба позволяет нескольким пользователям одновременно общаться друг с другом в режиме online. Если Chat-участник набирает определенный текст на своей клавиатуре, то этот текст появляется у других участников конференции на экране. Решающим является то, что при этом одновременно на экране появляются сообщения других участников. Тем самым любой участник конференции видит сообщения всех участников на своем экране, что делает возможным простой способ ведения конференции в режиме online. Так, прикладная задача может быть определена и выполнена с помощью архитектуры клиент-сервер, которая ввиду недостатка места не объясняется здесь в деталях. В любом случае стоит заметить, что программное обеспечение клиент/сервер имеет определенные преимущества при обслуживании (благодаря ясному разделению задач клиента и сервера) и что эта форма архитектуры программного обеспечения идеальна для такой распределенной системы, как LonWorks, не только из соображений совместимости. В LonWorks сетевые службы (LonWorks Networks Services, LNS) делают

265 возможной реализацию архитектуры клиент/сервер [Strat 96]. Тем самым подчеркивается применимость LNS не только к компьютерам, базирующимся на Windows, но и к любым платформам (LNS Developer's Kit for Microcontrollers). Дополнительно стоит отметить способность LNS-архитектуры производить одновременную работу нескольких инструментов в одной сети LON.

8.3.2. Сервер сетевых служб и интерфейс сетевых служб LNS-архитектура определяет два основных компонента: интерфейс сетевых служб (Networks Services Interface, NSI) и сервер сетевых служб (Networks Services Server, NSS) [Nsi 96, Nss 97]. Первый компонент представляет собой клиента, тогда как второй реализует сервер. На Рис. 8-6 изображен принцип действия NSI и NSS. Справа приведена схема нескольких LNS-клиентов, которые снабжены NSI. С помощью API LNS и NSI хоста клиент может затребовать NSS. Для этого выполняется удаленный доступ к одному из нескольких других компьютеров (или узлов), которые обладают NSS. Не обязательно, чтобы каждый узел, который хочет использовать LNS-службы, обладал NSS, — достаточно только NSI, чтобы стать частью LNS-архитектуры [Tech 96].

Рис. 8-6. Принцип действия NS1 и NSS Решающим преимуществом использования NSI-NSS-методики является тот факт, что устройство сетевого менеджмента, снабженное NSI (настольный ПК, Laptop или другое переносное устройство), легко может быть добавлено к системе или удалено из нее без всякого нарушения синхронизации банка данных. Следует также отметить, что при растущих требованиях к инструментарию (например, если повысится число узлов, которыми ему нужно управлять) можно повысить мощность NSI установкой лишь одного аппаратного компонента.

266

8.3.3. API хоста сетевых служб LonWorks Под API хоста сетевых служб Lon Works понимают программный интерфейс LON, который может быть установлен на самых различных платформах. Универсальность обеспечивает исходный ANSI-C код, который можно приобрести. Таким образом, в платформу LNS можно превратить ПК или любой другой процессор для разработки устройств с любыми пользовательскими интерфейсами [Hand 96]. Единственное ограничение, накладываемое на выбор процессора, — это доступность инструментария разработки, такого как С-компилятор или отладчик. API хоста сетевых служб LNS состоит из трех частей (Рис. 8-7): различные клиенты имеют доступ к верхнему уровню, API сетевых служб. Этот уровень отвечает за основные задачи сетевого менеджмента: инсталляцию новых узлов, связь с сетевыми переменными, доступ к объектам с LonMark (и к их свойствам) и многое другое. Следующий уровень — API сетевого интерфейса — используется как вышележащими API сетевых служб, так и непосредственно клиентом. Этими уровнями пользуются для обработки сообщений LonTalk (например, для отправки значений сетевых переменных) и инициализации NSS или NSI. Другая важная задача API сетевого интерфейса обработка ошибок.

Рис. 8-7. Структура API хоста LNS Самый нижний уровень в API хоста LNS — это сетевой драйвер. Его задачей является предоставление в распоряжение клиенту независимой от аппаратного обеспечения связи с NSI или NSS. Сетевой драйвер — это прямой интерфейс к NSI или NSS.

267 Благодаря разделению функций API хоста LNS на три различных области задач в виде уровней, изменение аппаратного обеспечения (если, например, нужно установить другой процессор) повлечет минимальное изменение программного обеспечения (в этом случае нужно всего лишь заменить сетевой драйвер). Таблица 8-2. Доступ к объектам NSS Объект

Доступ

Узел

Управление узлом. Назначается NSS при добавлении узла

Программа

ID программы. Определяется при разработке прикладной задачи Индекс сетевой переменной. Определяется при разработке прикладной задачи Индекс тэга сообщения. Определяется при разработке прикладной задачи Дескриптор узла и сетевая переменная или индекс тэга сообщения из Hub. Hub — ввод или вывод соединения

Сетевая переменная Тэг сообщения Соединение

Подробный обзор функций NSS можно найти в [Tech 96]. Как показывает Таблица 8-2, NSS заведует близкими к прикладной задаче объектами (структурами данных) с помощью дескрипторов, ID или index. Из-за такой формы убыстренного доступа к ресурсам Lon Works существенно облегчается программирование инструментов сетевого менеджмента.

8.3.4. Инструментарий Для LNS-архитектуры существует полный набор инструментария, облегчающий прикладную задачу сетевого менеджмента. Как уже упоминалось выше, для платформы Windows применяется LNS Developer's Kit. Этот продукт служит для разработки задач Lon Works для сетей, содержащих более чем 32 000 узлов (что позволяет управлять всем доменом LonTalk). В LNS Developer's Kit для Windows содержится так называемый LCA Object Server (см. раздел 8.2) и NSS для Windows. LNS Developer's Kit for Microcontrollers уже упоминался в разделе 8.3.1. С этим пакетом поставляется программное и аппаратное обеспечение для разработки приложений для любых процессоров. Исходный программный код API хоста LNS поставляется на ANSI-C. Дополнительно вместе с аппаратным обеспечением поставляется модуль LonManager NSS-10 (его можно найти также под названием PCNSS в виде ISA-карты для PC), с помощью которого можно управлять сетью LON, содержащей до 62 узлов. При большем количестве узлов устанавливается модуль NSS-

268 10 в комбинации с NSS для Windows. Следует отметить, что как в программное обеспечение, так и в самостоятельно разработанное аппаратное обеспечение не нужно вносить никаких изменений — здесь реализован принцип Plug and Play. Существует еще так называемый LNS FASTART Package, который содержит оба вышеназванных продукта (LNS Developer's Kit for Windows и LNS Developer's Kit for Microcontrollers). Если в сети LON предполагается использование переносных ПК, то с помощью сетевого интерфейса РСС-10 можно установить связь с трансивером «free topology» и тем самым спроектировать удобный и мощный инструмент сетевого менеджмента. Интерфейс с переносным ПК называется «Туре II PC», что является новым обозначением интерфейса PCMCIA, который стал промышленным стандартом благодаря сверхкомпактным габаритам его стековых модулей. Два важных инструмента для разработки устройств сетевого менеджмента — это LCA Field Compiler API и LonManager Protocol Analyzer (анализатор протокола). Эти компоненты программного обеспечения позволяют использовать все функции компилятора Neuron С вместе с отладчиком, а также все возможности средств сетевой диагностики в прикладной программе. Оба эти продукта не надо рассматривать как части LNS-архитектуры, они являются дополнениями к архитектуре компонентов LonWorks, о которой речь пойдет в следующем разделе.

8.4. Архитектура компонентов Lon Works Для наиболее полного и удобного использования LNS-приложениями среды Win32 была создана архитектура компонентов Lon Works (LonWorks Component Architecture, LCA). LCA реализована в соответствии с основной тенденцией развития индустрии программного обеспечения — в ее основе положен стандарт фирмы Microsoft ActiveX. ActiveX — это новое название OLE (Object Linking and Embedding, [Ole 95]). Под этим термином понимается основное направление определения объектов и их взаимодействия в рамках Windows-приложений.

8.4.1. OLE — ActiveX Object Linking and Embedding (OLE) являлся стандартом, который определял обмен данными между приложениями Windows. Co времением OLE был не только переименован в ActiveX, но и была значительно расширена область его применения. Фирма Microsoft при разработке ActiveX или OLE для Windows действовала подобно тому, как LonMark Interoperability Guidelines при разработке LonWorks-для последней определяются типы сетевых переменных, объекты LonMark, конфигурационные свойства и профили, тогда как ActiveX стандартизирует компоненты программного обеспечения (ActiveX— или OLE-Controls), обмен данными между приложениями

269 Windows и многое другое. В OLE различают понятия OLE-Automation (автоматизация) и OLE-Control (управление). OLE-Automation — это механизм для предоставления собственных объектов в распоряжение других приложений, то есть впоследствии можно будет вызывать методы объектов и считывать либо изменять их свойства. Хорошим примером тому служит поддержка макросов многими Windows-приложениями: при программировании текстовых процессоров с поддержкой макросов с помощью среды разработки, использующей автоматизацию OLE, говорят о клиенте автоматизации (в данном случае это самостоятельно написанная программа), который получает доступ к объекту сервера автоматизации (обработка текста). Рис. 8-8 содержит некоторые пояснения. В частности, он показывает, что коммуникация выполняется односторонне. Automation Server в противоположность к OLE-Control не имеет полного доступа к Automation Client. Здесь речь уже идет не о клиенте и сервере, а о Control Container и OCX. В случае OLE-Automation, Control Container соответствует Automation Client; OCX-это рекомендуемые, но не предписываемые расширения файлов данных, которые представляют Control (это соответствовало бы Automation Server). Для лучшего понимания вопроса опишем вкратце основы OLE-Controls. При разработке программного обеспечения никогда не имело смысла открывать заново колеса, то есть самостоятельно создавать все процедуры и части программ. Гораздо целесообразнее использовать готовые решения из библиотек программ или иерархии классов, что экономит время на разработку и, следовательно, деньги. С точки зрения разработчика, библиотека подпрограмм или иерархия классов-это практичная альтернатива утомительному самостоятельному проектированию, при котором зачастую приходится разрабатывать отдельное Know-How. Но как выглядит ситуация с точки зрения производителя библиотек программ или иерархий классов? Для него встает вопрос выбора языка, для которого будет разрабатываться библиотека: Basic — потому что он самый новый; С — потому что он самый распространенный; либо Java— потому что о нем все говорят. Разрешение этого вопроса находится в стандартах программного обеспечения. Представим себе, что все производители библиотек программ и иерархий классов сошлись на одном общем стандарте в качестве интерфейса для их продуктов. Если бы удалось убедить производителей сред разработки в целесообразности единственного стандарта, то была бы возможность создавать будущие компиляторы согласно именно этому стандарту. Именно в этом следует искать ключ к пониманию OLE-Controls: тот, кто разрабатывает свою библиотеку программ согласно OLE-Controls, уже может не беспокоиться о возможном пользователе или о поддержке языков программирования. Сегодня большинство компиляторов могут работать с OLE-Controls (однако нужно обратить внимание, что этот стандарт изменил свое название на ActiveX). Архитектура компонентов LonWorks (LCA)-это, проще говоря, обширный OLE-Control. Рис. 8-9 показывает схему управления и соответствующих контейнеров. Заметим, что коммуникация осуществляется в обоих направлениях.

270

Рис. 8-8. Схема интерфейса для OLE-Automation Полное руководство по изучению OLE, а также принципам его определения и разработки можно найти в [Cont 95]. В [Com 96] объясняется основа OLE, Component Object Model (COM), и с помощью типичной проблемы программного обеспечения (управление различными версиями) показывается, как можно преодолеть принципиальные сложности благодаря применению этого стандарта.

Рис. 8-9. Схема интерфейса OLE-Control

8.4.2. Объектно-ориентированный подход в LON Одним из решающих факторов ActiveX или OLE-Control является применение методов объектно-ориентированного моделирования компонентов программного обеспечения. Понятие «объектная ориентированность» употребляется давно, например, в языке программирования Smalltalk. Тенденция применения объектно-ориентированных

271 методов стремительно развивается в течение последних лет. Словарем объектного ориентирования легко овладеть: объект, который представляет собой псевдоцентральный элемент в объектно-ориентированном программировании, — модель реального мира. Он состоит из двух частей: состояния и поведения, причем если последнее «общественно доступно», то первое остается для внешнего мира закрытым. Наконец, речь идет о частичном моделировании поведения. Реализацию объекта называют классом, который состоит из методов и свойств (атрибутов). Посредством методов класса можно получить доступ к его свойствам, совокупность всех методов одного класса образует интерфейс. Если несколько классов разделяются иерархически, то говорят об иерархии классов. После краткого введения в словарь объектно-ориентированного программирования (для таких понятий, как наследование или полиморфизм, сошлемся на [Obj 97]), поясним значение методов объектного ориентирования в LonWorks. У LCA иерархически моделируется только LON (локальная сеть). Приведем небольшой пример (см. Рис. 8-10). Левая часть рисунка показывает построение компьютера в форме иерархических связей: компьютер состоит из корпуса, частей сети, материнской платы; материнская плата состоит из ОЗУ, ПЗУ, процессора, контроллера прерываний и многого другого. Для сравнения с этим в правой части Рис. 8-10 представим упрощенную версию иерархии в LCA Object Server [Spec95, Int95]; этот сервер объектов является OLEControl, с помощью которого можно получить доступ к службам LNS в среде Windows. Как видим, он состоит из сети, которая, в свою очередь, включает в себя систему; система имеет суперузел и сетевой интерфейс. Сравнение с упрощенным построением компьютера необходимо для облегчения понимания иерархии сервера объектов. Объясним далее построение LCA.

272

Рис. 8-10. Сравнение иерархии объектов LCA с иерархией компьютера

Рис. 8-11. Общая уровневая модель архитектуры компонентов LonWorks LCA устанавливает службы уровня сетевых служб LNS. Нижние уровни LCA — это сервер данных и его API, а также построенный на нем сервер объектов LCA (это данные OCX), который делает доступными свои службы верхним уровням благодаря OLE-Control и OLE-Automation. На Рис. 8-11 объясняется, как меняется интерфейс при переходе от следующего верхнего уровня (Component Applications — компонентные приложения) к самому верхнему уровню (Director Applications — управляющие приложения) на OLE-Automation. Как уже объяснялось, LCA состоит из нескольких уровней. Рис. 8-4 показывает точное построение этой уровневой модели с учетом разделенных компонент программного обеспечения. За моделирование прикладной оболочки отвечают три различных банка данных: банк сетевых данных, который связан с LON; сервер объектов LCA имеет собственный банк для хранения тех данных, которым не предусмотрено места в сетевом банке, и сервер объектов API. На Рис. 8-4 объясняется

273 само построение сервера объектов, т.е. возможность представить этот ActiveXинтерфейс не как библиотеку программного обеспечения фиксированной величины, а только как многомерную сумму компонент. Необязательно, например, управлять функциями уровня объектов компонент посредством OLE-Control, с тем же успехом можно применять тот API, к которому сервер объектов сам имеет доступ, так называемый сервер данных API [Lca97]. Этот интерфейс можно использовать без знаний о OLE и таким образом можно обойтись меньшими непроизводительными затратами. Благодаря OLE или ActiveX программа станет примерно на 15% быстрее в той области, где данные считываются или записываются в LON. Однако стоит упомянуть, что сервер данных API не дает тех удобств, которые можно ожидать от сервера объектов OCX, несмотря на то, что на сервере данных API находятся еще некоторые другие компоненты, такие как вышеназванный полевой компилятор API (с помощью этой компоненты можно транслировать исходный код на Neuron С, отладить его и загрузить в узел). Аналогично выглядит анализатор протокола API — здесь используют программный интерфейс для анализа поступающих LON в данных. Существует много возможностей расширения банка данных сервера объектов. Например, можно одновременно применять различные методы расширения для различных прикладных задач. Посредством стандартизованного доступа ODBC (Open Database Connectivity) можно легко составлять отчеты или обмениваться информацией с другими прикладными задачами. Рис. 8-12 показывает связи между прикладными задачами, сервером объектов и расширением банка данных. На нем видна реализация архитектуры программного обеспечения, которая допускает достоверную форму взаимодействия прикладных задач, вьшолняющихся в среде Windows. Собственные стандарты Windows OLE-Automation и OLE-Control служат базисом для обмена информацией между программами. Благодаря возможности размещать собственные банки данных (или банки данных от других производителей), в LCA легко удается реализовать интеграцию и взаимодействие сложных, базирующихся на банках данных прикладных задач.

274

Рис. 8-12. Поток данных сервера объектов LCA На Рис. 8-5 изображена иерархия объектов LCA. В LCA выделяют объекты и контейнеры, причем последние представляют собой не что иное, как множества объектов (контейнер содержит несколько объектов).

275

Рис. 8-13. Простейшая иерархия объектов LCA Рис. 8-5 представляет полную иерархию LCA, включая объекты с маркой Lon, маршрутизаторы, контейнеры каналов и многое другое. Для прикладной задачи такие подробности не нужны, достаточно так называемой минимальной иерархии LCA. На Рис. 8-13 показана менее сложная иерархия, а также приведена обзорная схема основных, базирующихся на Windows, устройств. Чтобы интерпретировать рис. 8-5 и 8-13 на уровне программного обеспечения, необходимо знать представление этой иерархии в LCA. Сервер объектов LCA можно представить как так называемый родительский объект (parent object-под этим понимают верхний уровень объектной модели), который содержит объекты-потомки (child objects) или их контейнер в форме свойств (Properties). Контейнеры-потомки, в свою очередь, также имеют собственные объекты-потомки или контейнеры-потомки. Например, сервер объектов LCA как родительский объект имеет свойство «сеть» (сравните с Рис. 8-5). Следует подчеркнуть, что на этом рисунке изображены не сети, а сеть; вид обрамления (штрих или прерывистая линия — см. подпись под рисунком) определяет объект или контейнер. Контейнер «сеть» состоит из нескольких объектов «сетей», имеющих систему свойств, а контейнер «система» состоит из нескольких объектов «систем». Таблица 8-3 показывает с помощью Objects AppDevice различные свойства и методы, которые не указаны в иерархии. В следующем разделе разъясняется, каким образом программист может обрабатывать эту иерархию. Вернемся к понятиям, которые были упомянуты в разделе 8.4.2. Под Director Applications понимают приложение, которое при всем прочем должно позволять пользователю исследовать его LON с помощью графического просмотра. Пример Director Application, так называемый LCA Navigator, прилагается к LNS Developer's Kit for Windows. Стоит отметить, что между Director Applications и Component Applications (это те приложения, которые создаются на базе сервера объектов LCA) существует интерфейс (OLE-Automation), делающий возможным навигацию по данным Component Application. Для этого существует список методов и свойств, который должен содержать Component Application, чтобы обеспечить доступ для Director Applications (см. раздел 8.3.4).

276 Таблица 8-3. Свойства и методы объекта AppDevice Требуется

Методы

Build Commission Delete Export Install Load

Свойства

AppImagePath Bitmap Channel Description DeviceTemplate Domains Handle Icon Interface Location

По выбору Move Replace Reset SetConfigProps Test Wink Name Neuronld Nodeld Parent Priority ProgramTemplate SelfDocumentation State Status Subnet UserExtensions

277 Таблица 8-4. Свойства и методы прикладного интерфейса LCA Требуется Методы

Свойства

По выбору

LonWorksCommand Quit

Help Repeat Undo

Application FullName Iconic Name Parent Visible

Caption DefaultFilePath Height Left StatusBar Top Width

8.4.3. Среда разработки LCA-приложений LCA делает более удобным использование связанных с LonWorks Windowsприложений. Как уже отмечалось, благодаря применению в качестве интерфейса программного приложения OLE-Control, достигается возможность запрашивать LCA на различных платформах разработки (т.е. с различными языками программирования). Перечислить все имеющиеся в настоящее время инструменты вряд ли возможно, поэтому ограничимся лишь самыми известными. Прежде всего, это Visual Basic фирмы Microsoft. Версия 4.0 этого продукта обеспечивает OLE-Control. С помощью «Drag and Drop» можно добавить сервер объектов LCA в создаваемое приложение. Доступ серверу объектов очень прост, поэтому Visual Basic обеспечивает быструю разработку приложений (Rapid Application Development, RAD). Недостатками являются самая низкая по сравнению с другими языками программирования мощность и отсутствие стандарта для языка Basic (Basic означает Beginner's All Purpose Symbolic Instruction Code — многоцелевой символьный командный код для начинающих). Тем не менее, можно рекомендовать Visual Basic, так как он обеспечивает удобный доступ к OLE-Control и позволяет легко добиться успеха в изучении LCA-программировании. Фирмой Microsoft был также разработан Visual C++, аналог Visual Basic, обеспечивающий доступ к OLE-Control. Этот язык менее удобен, но он обладает повышенной мощностью, а также является базисом стандартизированного языка (хотя и не все диалекты C++ одинаковы — важно то, что для базисного языка (С) существует ANSI стандарт). Принимая во внимание эти преимущества, разработка приложений, основанных на LCA, в среде Visual C++ все-таки имеет смысл, так как в этом случае достигается оптимальный компромисс между удобством программирования и мощностью.

278 Похоже выглядит Delphi 2.0 фирмы Borland. В основе этой среды разработки лежит язык программирования Pascal, и можно так же легко получить доступ к LCA. Set HubDev = mySuperNodel.AppDevices.Item(m_deviceNamel) Set TgtDev = mySuperNode2.AppDevices.Item(m_deviceName2) Set HubNV = HubDev.Interface.NetworkVariables.Item(IstNvDevicel.Text) Set TargetNV = TgtDev.Interface.NetworkVariables.Item(lstNvDevice2.Text) HubNV.AddTarget TargetNV HubNV.Connect

Листинг 8-1. Связь сетевых переменных (Visual Basic) Visual Java-это язык программирования, о котором в настоящее время больше всего говорят, поэтому он заслуживает особого внимания. Используя Visual Java (фирма Microsoft) возможно разрабатывать Java-приложения, которые имеют доступ к LCA. Это особенно практично, так как в настоящее время Java является переходом от Add-On языка для World Wide Web (WWW) к основополагающему языку для распределенных устройств. Следует отметить, что Java-приложения основаны на использовании не компиляторов, а интерпретаторов, выполняющихся на многих платформах. Это позволяет выполнять части приложения в другой операционной системе (например, с целью тестирования); полностью выгружать части, отделенные от LCA; посредством удобной сетевой коммуникации, которую предоставляет Java, реализовать действительно распределенное приложение. В [Dev96], а также в [Net96] можно найти много примеров программ (в основном для Basic и C++), которые постепенно вводят в LCA-программирование. Листинг 8-1 показывает, как можно осуществить связь сетевых переменных.

8.4.4. LCA и совместимость Совместимость важна не только на уровне узлов (см. главу 10), но также на уровне приложений. Архитектура компонентов LonWorks предлагает при этом аналогично LonMark Interoperability Guidelines (она описывает датчики, исполнительные механизмы и регуляторы) основу для разработки приложений сетевого менеджмента. В [Lns96] см. подробное описание отдельных механизмов, которые обеспечивают в LCA совместимость между Windows-приложениями, LON и банками данных других производителей. Отметим, что и при использовании LNS можно разработать совместимую систему.

8.4.5. LNS- и LCA-документация от Echelon Фирма Echelon предлагает полную документацию и описание для LNS и LCA. Все эти тесты можно загрузить с Web-Site Echelon (http://www.lonworks.echelon.com/products/LNS/) на свой компьютер. Формат данных при этом или PDF-Format фирмы Adobe (бесплатное программное обеспечение, называемое Acrobat Reader, можно загрузить с http://www.adobe.com), или в Wordформате фирмы Microsoft (есть также бесплатное программное обеспечение Word Viewer на http://www.microsoft.com). Все ссылки на литературу в этой главе, которые связаны с фирмой Echelon, взяты с Web-страницы Echelon.

9.

Объекты ввода/вывода, поддерживаемые микропрограммным обеспечением

Важным свойством Neuron Chip является широкий спектр различных схем подключения внешнего аппаратного обеспечения без использования сложного интерфейсного оборудования, требующего больших затрат. Данное обстоятельство (стоимостной фактор) может оказаться решающим при выборе той или иной Fieldbusсистемы. Neuron Chip имеет в распоряжении в общей сложности 34 объекта ввода/вывода. Они подразделяются на: — 7 объектов прямого ввода/вывода; — 4 объекта последовательного побайтового ввода/вывода; — 10 объектов последовательного побитового ввода/вывода; — 15 объектов таймера/счетчика. Neuron Chip имеет также 11 линий ввода/вывода, которые можно по-разному соотносить с вышеназванными объектами. Программные объекты определяются в прикладной задаче, приводятся в соответствие с желаемыми (или возможными) объектами ввода/вывода и вызываются непосредственно [LWDD95]. Далее рассмотрим различные объекты ввода/вывода с точки зрения их применения. Детальное описание синтаксиса и импульсные диаграммы содержатся в [REFG94], [LWEB95] и [LWSR95].

280

Рис. 9-1. Линии ввода/вывода Neuron Chip и внутренняя связь с таймерами/счетчиками На рис. 9-1 показано расположение линий ввода/вывода и их соответствие внутренним таймерам.

9.1. Объекты прямого ввода/вывода В объектах прямого (непосредственного) ввода/вывода используются линии ввода/вывода, заданные при описании этих объектов.

9.1.1. Побитовый ввод/вывод (Bit Input/Output) При побитовом вводе/выводе может использоваться каждая из линий ввода/вывода. Этот метод применяется, например, при подключении реле (устройство вывода) или переключателя (устройство ввода). В обоих случаях используется только одна линия Neuron Chip. Выходное значение (бит) можно считать обратно (на 7-й уровень), например, с целью проверки и подтверждения информации. Для обеспечения реакции на внешние события при вводе можно использовать IO_changes (см. раздел 6.2).

9.1.2. Побайтовый ввод/вывод (Byte Input/Output) При побайтовом вводе/выводе используются линии IO0 — IO7 Neuron Chip. Оставшиес три линии (IO8-IO10) можно применять либо как управляющие (для мультиплексора / демультиплексора), либо для передачи дополнительной адресной информации. Если для обеспечения реакции на внешние события применяется IO_changes, то в ходе вывода можн также осуществлять обратное чтение с целью проверки информации.

281

9.1.3. Ввод по уровню (Leveldetect Input) Каждая из линий IO0-IO7 Neuron Chip может применяться для leveldetect input. Пои этом соответствующая линия запрашивается все 200 нс (при тактовой частоте Neuron Chip 10 МГц). По достижении нижнего уровня напряжения устанавливается схема-«защелка». Для отслеживания данного события из прикладной программы можно использовать when-условие с IO_changes. Например, такой алгоритм можно применять для распознавания срабатывания выключателя питания. Однако применение данного объекта ограничено временными характеристиками планировщика задач (см. раздел 6.2): многократное наступление события в течение одного цикла работы планировщика не может быть распознано leveldetect input. После начала работы соответствующего when-условия, установленная схема-«защелка» сбрасывается в исходное состояние между 35 и 66 Fс с начала работы функции. В этот момент можно зафиксировать новое событие. Для более частых событий можно использовать объект «Total Count Input» (см. раздел 9.4.8).

9.1.4. Полубайтовый ввод/вывод (Nibble Input/Output) Каждая из четырех линий IO0—IO4 Neuron Chip может использоваться для ввода/вывода слов-данных длиной 4 бита. Стандартное применение этого методавзаимодействие с дисплеем и матрицей клавиатуры, причем сигналы управления на программное обеспечение (Bit Output Object) должны также приниматься линиями ввода/вывода [LWEB92]. Допускается использование IO_changes.

9.2. Объекты последовательного побайтового ввода/вывода Объекты последовательного побайтового ввода/вывода передают байты данных с помощью определенного протокола передачи.

9.2.1. Параллельный ввод/вывод Объект параллельного ввода/вывода использует все 11 линий Neuron Chip и образует двунаправленный байтовый интерфейс с тремя сигналами подтверждения установки связи. С помощью этого объекта можно соединить два Neuron Chip или несколько Neuron Chip с микропроцессором. Для активного управления интерфейсом используется протокол передачи маркера. Максимальная длина одного блока данных255 байт. Различные варианты протокола позволяют связать два Neuron Chip, подключенных к различным сегментам сети, а также объединить несколько Neuron Chip с микропроцессором и, таким образом, реализовать подключение Neuron Chip к ПК с несколькими каналами.

282

9.2.2. Ввод/вывод Input/Output)

с

помощью

интерфейса

Muxbus

(Muxbus

При использовании интерфейса Mixbus Neuron Chip осуществляет постоянное управление передачей данных. Подтверждение установления связи не используется. Все 8 линий данных работают в мультиплексном режиме-как для передачи адресной информации, так и для передачи собственно данных, что позволяет реализовать ввод/вывод блоков до 256 байт. В качестве дополнительного аппаратного обеспечения используются внешний регистр, мультиплексор и демультиплексор. С помощью этого метода обеспечивается специальный интерфейс к микропроцессору или параллельной системе шин. Данный объект можно также использовать для расширения «Fan Out» или «Fan In» (бинарный ввод/вывод). Для того чтобы прикладная программа на языке Neuron С могла прореагировать на те или иные события, необходимо опрашивать линии ввода.

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

9.3.1. Bitshift Input/Output (побитовый ввод/вывод) Пары следующих друг за другом линий ввода/вывода Neuron Chip можно использовать для последовательной передачи или получения информации (до 16 бит максимум). Одна линия служит для ввода данных, другая — для передачи тактовых импульсов, частота которых может составлять 1, 10 или 15 кГц при тактовой частоте Neuron Chip 10 МГц. Параллельный ввод/вывод данных с разрядностью до 16 бит осуществляется при помощи внешнего сдвигающего регистра. Для управления процессом ввода/вывода нужно использовать дополнительные линии Neuron Chip.

9.3.2. Ввод/вывод с помощью шины I2C (I2C Input/Output) Шина I2С, разработанная фирмой Philips, позволяет проводить информационный обмен между узлами без возникновения больших затрат. Данная шина не является пространственно распределенной, а предназначена для объединения элементов внутри группы или, по крайней мере, внутри одного носителя. Philips также предлагает ряд 1

Это время между двумя опросами планировщиком одного и того же when-условия.

283 микросхем в области бытовой электроники и телефонной техники, снабженных шинным интерфейсом I2С и способных связываться напрямую. Таким образом, область применения данного метода — дорогостоящая коммуникационная и бытовая техника. Объекты ввода/вывода I2С позволяют производить прямое подключение Neuron Chip к шине I2C. Neuron Chip в этой схеме выполняет роль Master-устройства. Линия IO8 используется как тактовая, линия IO9-как линия данных. К обеим линиям необходимо добавлять два нагрузочных резистора (внешнее аппаратное обеспечение), так как этого требует физический протокол передачи. Neuron Chip, как Master-шины, определяет синхронизацию и допускает скорость передачи до 44 Кбит/с. В течение одного вызова функции можно передать блок до 255 байт. Детальное описание протокола шины I2С см. в [I2C95].

9.3.3. Ввод с магнитной карты стандарта ISO 7811 (Magcard Input) Объект ввода Magcard используется для обмена с устройством считывания магнитных карт стандарта ISO/OSI 7811. Для его использования необходимы три линии: IO8 как тактовая, IO9 для последовательных данных и одна линия (из IO0 — IO7) — для сигнала Timeout или прерывания функции. Поступающие данные имеют длину 5 бит, включая один бит четности. Полубайты упаковываются в байты без бита четности и записываются в буфер, длина которого — максимум 20 байт. Пользовательские данные отделяются знаком начала (ОВ шестнадцатеричное) и знаком конца (0F шестнадцатеричное). Непосредственно после знака конца принимается (но не запоминается) знак LRC2, который служит для проверки блоков данных. Функция ввода возвращает число принятых знаков или, в случае ошибки, значение «-1». Поскольку при отсутствии знаков ввода таймер Watchdog переустанавливается в исходное состояние, то можно было бы, при остановке магнитной карты или прохождении ее через считывающее устройство, остановить систему при условии, что сигнал Timeout или прерывание не активизируются. Кроме этого, сигнал Timeout используется для чтения. Листинг 9-1 содержит краткое объяснение вышесказанного.

// // // //

IO_8 [input] magcard timeout (IO_7)IO-card_data; IO_7 должен установиться в "0" — начинается процесс чтения IO_card_data — имя объекта IO_7 бит input_data_not_valid;

int nibbles_read; unsigned int input_buffer[20]; /* Величина input_buffer составляет максимум 2 0 байт, т.е. до 4 0 4-битных чисел */ when (IO_changes(input_data_not_valid) to 0){ 2

LRC означает Longitudinal Redundancy Check.

284 nibbles_read = IO_in(IO_card_data, input_buffer); . . . }

Листинг 9-1. Пример использования сигнала Timeout в объекте ввода Magcard Сигнал Timeout («input_data_not_valid» в декларации) непосредственно перед началом процесса чтения пропадает для того, чтобы можно было выполнить вызов функции еще перед поступлением знака начала. Необходимо обратить внимание на короткое время работы планировщика. Многие магнитные карты, в соответствии с ISO/OSI 7811, имеют последовательность из 15 «нулевых битов» перед знаком начала. Поскольку Neuron Chip может читать данные со скоростью 8334 бит/с при тактовой частоте 10 МГц, это означает время работы менее 1,8 мс от исчезновения Timeout до появления знака начала; в течение этого времени нужно выполнить функцию чтения, расположенную в любом месте пользовательской программы.

9.3.4. Устройство чтения с магнитных карт стандарта ISO/OSI3554 (Magtrack Input) С помощью объекта ввода Magtrack можно производить обмен с устройствами считывания магнитных карт ISO/OSI 3554. Данный объект подобен объекту Magcard, но имеет следующие отличия: — знак, который нужно принять или отправить, имеет длину 7 бит, включая бит четности; — знак начала — 05 шестнадцатеричное, знак конца — 0F шестнадцатеричное; — длина буфера приема должна составлять 78 бит; он также содержит знаки начала и конца. Величина, возвращаемая функцией IO_in(), соответствует числу сохраненных байтов или «-1» в случае ошибки. Сигнал Timeout, используемый в объекте Magcard, здесь также необходим (из чего вытекают аналогичные проблемы со временем работы планировщика). В целом можно сказать, что узлы для работы с Magcard или Magtrack, базирующиеся на Neuron Chip, для других задач коммуникации с соответствующими устройствами чтения карт подходят очень ограниченно. Проблема состоит не только в высоких требованиях к скорости реакции на поступающие данные, но и в более длительном времени считывания магнитной карты, в ходе чего прикладная программа не может обрабатывать другие события.

285

9.3.5. Ввод/вывод с помощью протокола Neurowire (Neurowire Input/Output) Объект Neurowire реализует последовательный протокол передачи, который использует линию IO8 как тактовый ввод, IO9 как последовательный выход и IO10-как линию ввода. Одна из линий IO0-IO7 может использоваться как «Chip-select» — вывод для управления подключенным аналого-цифровым или цифро-аналоговым преобразователем. В ходе передачи Neuron Chip может выполнять роль как Masterустройства, так и Slave-устройства. В качестве Master он генерирует тактовую частоту (IO8); в качестве Slave — принимает ее. Длина блока передачи ограничена 255 битами. Блок можно посылать и принимать одновременно. Скорость передачи составляет 1,10 или 20 Кбит/с. Важно: в ходе передачи прикладная программа не обрабатывается. Neurowire Input/Output используется, как правило, для связи с аналогоцифровыми и цифро-аналоговыми преобразователями, а также дисплеями.

9.3.6. Последовательный ввод/вывод (Serial Input/Output) Объекты последовательного ввода/вывода реализуют последовательный интерфейс в соответствии с EIA 232. Формат передачи: стартовый бит, 8 бит данных, стоповый бит. Максимальная скорость передачи — 4800 бит/с. Для вывода данных нужно использовать линию IO10, для ввода — IO8. Несмотря на одновременное использование двух линий ввода/вывода, возможен только полудуплексный режим. Такое ограничение является прямым следствием остановки прикладной программы на время передачи. За один раз можно послать или принять до 255 байт данных. При использовании низкой скорости передачи и, соответственно, длительном времени, может произойти срабатывание таймера Watchdog. Это обстоятельство необходимо принимать во внимание при программировании. Управление передачей в ходе коммуникации можно осуществлять посредством сигналов DTR, DSR, RTS, CTS, используя 10 оставшихся сервисных выводов.

9.3.7. Ввод/вывод в энергонезависимую память (Touch Input/Output) Фирма DALLAS Semiconductor предлагает системы энергонезависимой памяти (чтение/запись) и программируемой памяти (чтение), имеющие всего две внешние линии. Управляемый во времени протокол обеспечивает такие функции, как энергообеспечение и коммуникацию с внешними элементами. Память размещена в корпусе из нержавеющей стали, причем крышка и дно образуют электрические контакты. Часть корпуса занимает встроенная литиевая батарея (энергообеспечение), таким образом, содержимое памяти является энергонезависимым. Механическое и

286 электрическое исполнение указывает на возможность использования данного типа систем в мобильных устройствах и агрессивных средах. Основные применения: электронный ключ или «интеллектуальные» инструменты машин; защита качества (продукты, штучные товары сопровождаются этой памятью во время производства). Протокол одной линии такой памяти поддерживается Neuron Chip. Детали протокола представлены в [TMS95] и [REFG94]. За один вызов функции можно передать до 255 байт.

9.3.8. Ввод, реализованный на эффекте Виганда (Wiegand Input) Для производства кодовых карт часто применяют эффект Виганда, основанный на смене направления магнетизации в проводнике из Vicalloy при воздействии внешнего магнитного поля [PROPF94]. На карте закрепляются две дорожки из так называемой «проволоки Виганда». Запись информации производится посредством подачи импульсов (индукции), что вызывает изменение направления магнетизации проволоки. При этом одна дорожка представляет импульс «0», а другая — импульс «1». Согласно физической природе, этот поток данных не является синхронным, поскольку карты, как правило, проводятся через считывающее устройство вручную. Единственная постоянная величина — длительность (и амплитуда) отдельного импульса. Синхронизация, предлагаемая Neuron СЫр, соответствует этим параметрам. Время между двумя распознанными битами может составлять минимум 150 ;с и максимально ограничиваться только сигналом Timeout. Объект использует линии IO0—IO7. Кроме того, необходима еще одна Timeoutлиния, прерывающая процесс чтения при остановке потока импульсов (например, когда карта не движется дальше). Возвращаемая функцией величина — количество считанных битов (255 максимум). Если после вызова функции не установлено активности на обеих дорожках данных, то Neuron Chip возвращается к нормальному выполнению программы.

9.4. Объекты таймера/счетчика Объекты таймера/счетчика используют установленные в Neuron Chip два таймера/счетчика. В отличие от объектов последовательного ввода/вывода, во время использования этой группы объектов прикладная программа продолжает обрабатываться (исключение составляют объекты вывода счетчика импульсов). Это также означает, что окончание работы объекта можно объявить как событие и его не нужно опрашивать. Те или иные состояния таймера/счетчика и их смена зависят от тактовой частоты процессора. При работе используются линии IO4 -IO7, а также IO0 и IO1.

9.4.1. Двухфронтовый ввод (Dualslope Input) Объекты

Dualslope

Input

поддерживают

обмен

с

аналого-цифровыми

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

9.4.2. Ввод с записью последовательностей импульсов (Edgelog Input) С помощью объекта ввода Edgelog измеряются входные потоки импульсов и сохраняется результат измерения. Все последовательности High и Low запоминаются в виде значений типа unsigned long, кратных длительности такта процессора с регулируемым делителем. При однократном вызове функции могут быть сохранены до 255 результатов измерения. Функция возвращает количество сохраненных величин. Используются оба счетчика. В качестве линии ввода/вывода используется IO4. Объект можно применять для декодирования последовательного потока данных из устройств считывания штрих-кода или датчиков инфракрасного излучения. Поскольку минимальное время между двумя последовательными (низким/высоким и высоким/низким) периодами составляет 104 ;с, то скорость передачи данных, подлежащих расшифровке (в зависимости от способа кодирования), в любом случае не превышает 20 Кбит/с. Для использования объекта IO_changes необходима дополнительная линия ввода (синхронизация поступающего потока импульсов). Кроме того, тем прикладным данным, длительность которых превышает время планировщика Neuron Chip, должна выставляться преамбула. Это позволяет измерять частоту потока данных с достаточной точностью.

9.4.3. Инфракрасный ввод (Infrared Input) С помощью объекта ввода/вывода Infrared Input можно считывать/выводить команды дистанционного управления. Поведение во времени потока данных дистанционного управления SONY по ИК-декодеру представлено на рис. 9-2. Пакет данных начинается с заголовка длительностью 2,5 мс. Затем следует 6-битная команда, а также 6-битный адрес. «0» кодируется низким напряжением длительностью от 0,4 мс до 0,8 мс, а «1» — высоким, от 0,4 мс до 1,4 мс.

Рис. 9-2. Поток данных при приеме команд ИК дистанционного управления SONY

288 Для обозначения и декодирования команды дистанционного управления SONY используется следующая программа: команда помещается в поле code структуры ir_in_da, адрес — в поле adr. // IO4 линия инфракрасного датчика по таймеру (7) IO_ir_data; // IO4 линия бит IO_ir_data_level; boolean ir_in = FALSE; // TRUE если данные в структуре typedef struct // структура для данных инфракрасного датчика { unsigned int adr; unsigned int code; }ir_in_da; ir_in_da ir_in_data; // Инфракрасная линия для телеуправления ir_in будет установлен в TRUE // после прибытия данных CODE и ADR. Находятся в структуре ir_in_dta when(IO_changes(IO_ir_data_level) to 0) { unsigned int bits_read; unsigned int irb[2]; bits_read =I0_in(I0_ir_data, irb, 15, 64891UL, 64891UL + 53UL); if(bits_read == 12) { ir_in_data.code =irb[0] & 0x3F; irb[0] &= 0xC0; irb[0] >>= 6; ir_in_data.adr =irb[l]