1.
сервіс з підтвердженням - забезпечує зв’язок між
транспортними сутностями двох або більше вузлів, який вимагає підтвердження про
отримання даних від кожного вузла-отримувача (надійний, гарантує доставку
даних);
2.
сервіс без підтвердження
- дані відправляються на декілька вузлів один раз, отримання даних
транспортною сутністю вузла-отимувача не контролюється (ненадійний, для швидкої
передачі великих обсягів даних, не критичних до надійності доставки);
3.
сервіс без підтвердження з повтореннями – дані
відправляються на декілька вузлів декілька раз, без очікування підтвердження
про доставку (ненадійний, для доставки даних великій кількості вузлів);
4.
сервіс запит/відповідь – забезпечує взаємодію прикладних Процесів
вузлів по моделі Клієнт-Сервер; дані відправляються на один або декілька вузлів
(повідомлення-запит), обробляються там, повертається підтвердження
(повідомлення-відповідь) (надійний, гарантує доставку даних та повертає
відповідь);
Функціонування перших трьох типів сервісів – задача транспортного рівня,
сервісу "запит-відповідь" – сеансового.
Для слідкування за послідовністю та кількістю TPDU пакетів, в їх заголовку вказується
ідентифікатор транзакцій, який з кожною відправкою збільшується на одиницю.
2.5.5.7. Сеансовий рівень. На даному рівні визначаються такі задачі: реалізація сервісу
"запит-відповідь"; авторизація (захист від несанкціонованого доступу);
сервіси мережного менеджменту та мережного інтерфейсу.
2.5.5.8. Рівень представлення даних. В кожному заголовку APDU вміщується інформація про інтерпретацію
повідомлень, які надсилаються. Доступні наступні типи повідомлень:
- вхідна мережна змінна;
- вихідна мережна змінна;
- явне повідомлення;
- зовнішнє повідомлення (використовується для шлюзів LonWorks);
- повідомлення мережної діагностики;
- повідомлення мережного менеджменту;
- повідомлення для сервісів "запит-відповідь".
2.5.5.9. Прикладний рівень. Разом з рівнем представлення даних прикладний рівень забезпечує функціонування
5-ти сервісів:
1. Обмін мережними змінними. Функціонування даного сервісу базується на
концепції загальних мережних змінних (NV). Кожний вузол може використати вхідні для нього мережні
змінні для керування прив’язаним для нього процесом управління. Значення кожної
мережної змінної може змінити тільки один вузол, для якого ця мережна змінна є
вихідною. Так, наприклад, датчик температури може змінювати значення вихідної
для нього мережної змінної, записуючи туди плинне значення температури.
Виконавчий механізм, що регулює подачу теплоагенту, приймає цю змінну в якості
вхідної, і подає її значення на вимірювальний вхід вбудованого ПІ-регулятору,
що забезпечує стабілізацію цієї температури. За допомогою програмного LON конфігуратору розробник
системи забезпечить зв’язок вихідних змінних одних вузлів з вхідними інших.
2. Обмін явними повідомленнями. Цей тип сервісу забезпечує передачу
повідомлень які мають вільний формат, відмінний від формату мережних змінних NV. Він передбачає обробку
повідомлень по програмі користувача, що не прописано в протоколі прикладного
рівня і може бути використаний для аперіодичного/періодичного обміну даними
процесу.
3. Обмін зовнішніми повідомленнями. Використовується для шлюзу LonTalk при
передачі даних між двома зовнішніми вузлами.
4. Сервіси мережного менеджменту. Забезпечують інсталяцію, конфігурування
вузлів, загрузку прикладних програм, управління станом вузла.
5. Сервіс мережної діагностики. Сервіс використовується для тестування
вузлів.
Процес зв’язку
мережних змінних забезпечується при конфігуруванні системи. В кожному NeuronChip є таблиця конфігурацій мережних змінних,
яка може вміщувати до 62 записів. Кожен запис характеризує конкретну мережну
змінну вузла: тип, вхідна/вихідна, пріоритет, служба, селектор змінної (умовний
ідентифікатор зв’язку) та адреса вузла з яким зв’язана дана змінна. Таким
чином, кожен вузол може мати до 62 мережних змінних.
2.5.5.10. Інтерфейс
прикладного рівня. Зв’язок між прикладними Процесами вузлів та їх
конфігурування забезпечується через два
типи інтерфейсів прикладного рівня: сумісний та несумісний інтерфейс (рис.2.24).
Сумісний інтерфейс дещо схожий на інтерфейс
прикладного рівня FF. Він базується на стандартизованих
LonMark об’єктах, які надають
вузлу певну функціональність. З одного боку, сумісний інтерфейс
використовується для обміну даними між цими об’єктами на різних вузлах, через стандартні
типи мережних змінних (SNVT). З іншого боку, цей же інтерфейс
надає можливість використання визначеного механізму конфігурування вузла через
набір стандартних типів конфігураційних параметрів (SCPT). Передача конфігураційних параметрів а також програми
проводиться за допомогою механізму передачі файлових даних, що використовує
сервіси мережного менеджменту.
Поряд з сумісним інтерфейсом
вузол може підтримувати несумісний інтерфейс, який дозволяє визначати
специфічну поведінку вузла. Обмін між прикладними Процесами вузлів через
несумісний інтерфейс проводиться через явні повідомлення (Explicit Exchange) або мережні змінні типу користувача
В сумісному
інтерфейсі всі об’єкти LonMark діляться на: об’єкти загального призначення, що
використовуються в широкому спектрі задач (наприклад об’єкт "датчик з
відкритим циклом"), та спеціалізовані об’єкти (наприклад об’єкт
"датчик температури", "датчик тиску"). В будь якому випадку
об’єкт LonMark визначається набором мережних змінних SNVT та конфігураційних параметрів SCPT. Кожна мережна змінна SNVT
має функціональне текстове ім’я, яке не може перевищувати 11 символів. Перші
три символи тобто префікс назви змінної вказують на клас та напрямок мережної
змінної: nvi – вхідна
мережна змінна, запам’ятовується в RAM; nvo – вихідна мережна змінна,
запам’ятовується в RAM; nci – вхідна
конфігураційна мережна змінна, запам’ятовується в EEPROM; nro – вихідна мережна змінна, запам’ятовується в ROM. При конфігуруванні
системи, мережні змінні "поєднують", що приводить до появи нових
записів в таблиці конфігурацій мережних змінних. Слід зазначити, що мережні
змінні об’єктів не обов’язково повинні бути використані.
Розглянемо декілька об’єктів сумісного
інтерфейсу. Для управління вузлом в цілому використовується спеціальний тип
об’єкту "Вузол" (Node
тип#0), наявність якого є обов’язковою для всіх вузлів що мають сумісний
інтерфейс. В склад об’єкту входять дві обов’язкові мережні змінні (nviRequest та nvoStatus) та декілька опціональних (рис.2.26). Змінна nviRequest дозволяє управляти станом об’єктів вузла та
робити запит на отримання статусної інформації про них, яка передається через
вихідну змінну nvoStatus.

Об’єкт "датчик" призначений для
отримання інформації з вузлів, які мають в своєму складі аналоговий або
дискретний датчик. Через вихідну змінну nvoValue інформація про вимірювальну
величину попадає в мережу. Об’єкт "виконавчий механізм" має вхід nviValue, який може управлятися
такими об’єктами як "датчик" або "контролер". Об’єкти
"датчик" та "виконавчий механізм" можуть бути двох типів: з
відкритим або закритим циклом. "Датчики" з закритим циклом (тип#2)
мають в своєму складі входи nviValueFB для підключення зворотного зв’язку від
"виконавчого механізму". "Виконавчі механізми" з закритим
циклом (тип#4) мають виходи nvoValueFB для зворотного зв’язку з "датчиками".
"Датчик" з відкритим циклом (тип#1) не має вхідної мережної змінної
для зворотного зв’язку, а "виконавчий механізм" з відкритим циклом
(тип#3) – вихідної мережної змінної.
Об’єкт "контролер" (тип#5) дозволяє
реалізовувати необхідні алгоритми управління, які вставляються між об’єктами
"датчик" та "виконавчий механізм". Тип алгоритму, що
прописаний в даному типі об’єкту визначається його функціональним профілем.
Наприклад в функціональному профілі PID визначений алгоритм ПІД-закону
регулювання, який потребує відповідних наборів конфігураційних параметрів.
Приклад відкритої системи побудованої на базі LonMark об’єктів показаний на
рис.2.27.
Таблиця 2.15
Характеристики
LON
Works.
OSI
|
характеритика
|
LON Works
|
|
NetArea
|
-
рівень датчиків
-
контролерний
рівень
|
Приклад-ний+представлення+сеансо-вий
|
AppService
|
NV/SNVT - періодичний/аперіодичний
обмін даними процесу між об’єктами вузлів;
явні повідомлення - аперіодичний обмін
повідомленнями; управління станом вузлів; діагностичні сервіси; SCPT/файлові_дані - програмування або конфігурування вузла (параметричні
дані); авторизація;
|
AppModel*
|
Видавець-Абонент ідентифікованого обміну для для NV/ SNVT/SCPT;
Видавець-Абонент обміну повідомленнями для явних
повідомлень, зовнішніх повідомлень;
клієнт-серверна модель обміну повідомленнями для
конфігураційних сервісів (файлові_дані),
сервісів мережної діагностики;
|
AppProfile
|
використання LonMark об’єктів зі стандартного
набору; функціонування алгоритмів
управління процесом через інтелектуальні функції вузлів; файл зовнішнього
інтерфейсу вузла *.XIF
|
AppProcData
|
NV/SNVT: <63 мережних змінних на Вузол;
загальна кількість не обмежена
|
AppResolut
|
залежить від конфігурації мережі, точно не
визначається із-за CSMA
|
транспортний
|
TpService
|
доступ до об’єктів;
доступ до операційної системи;
|
TpModel
|
надійні з підтвердженням;
надійні "запит-відповідь"; ненадійні без підтвердження; ненадійні
без підтвердження з повторенням; слідкування за транзакціями
|
мережний
|
NtService
|
5-рівнева
адресація вузлів; див. таб 2.9
|
каналь-ний
|
ChAddModel
|
широкомовна
адресація, ідентифікація вузлів через мережний рівень
|
ChAccess
|
predective p-persistent CSMA
|
ChChecksum
|
CRC16
|
ChSegment
|
кількість
сегментів не обмежена
|
фізичний
|
PhInterface
|
з вбудованим трансивером Differential Direct Mode -
диференційний манчестерський код; зовнішній трансивер Single-ended
Direct Mode - RS-485, інші
інтерфейси; зовнішній трансивер Special Purpose Mode – використання модемів;
|
PhMedia
|
залежить від PhInterface: вита пара; коаксіальний кабель; оптоволокно;
радіохвилі; інфрачервоні хвилі; силова проводка;
|
PhTopology
|
залежить
від PhInterface; для вбудованого трансиверу див.таб.2.8
|
PhLdrop
|
залежить від PhInterface;
|
PhBaudRate
|
залежить
від PhInterface; для вбудованого трансиверу див.таб.2.8
|
PhSegment
|
залежить від PhInterface;
|
PhNodes
|
залежить від PhInterface;
для вбудованого трансиверу див.таб.2.8
|
PhLength
|
залежить від PhInterface;
для вбудованого трансиверу див.таб.2.8
|
* - модель умовна, в LONTalk визначається сервісами, що
використовуються на транспортному рівні