1. ПРИЗНАЧЕННЯ ТА СФЕРА ЗАСТОСУВАННЯ

Програмне забезпечення віддаленого концентратора призначене для забезпечення роботи віддаленого концентратора (ВК) у складі системи «Сбор» як вузла обчислювальної мережі.

Основні функції такого вузла включають:

1. обмін інформацією лініями зв’язку з іншими вузлами мережі, включно з функціями маршрутизації транзитних даних;
2. обмін інформацією лініями зв’язку з абонентами (користувачами), які не є вузлами мережі;
3. передавання даних, отриманих від немережевих абонентів, до вузлів мережі та навпаки;
4. зберігання інформації, отриманої як від мережевих, так і від немережевих абонентів.

Отже, основне призначення програмного забезпечення віддаленого концентратора полягає у створенні інформаційного інтерфейсу між мережевими та немережевими абонентами. У випадках, коли доставка інформації неможлива, наприклад через відмову лінії зв’язку, програмне забезпечення забезпечує зберігання даних у вигляді файлів. Ці файли доставляються пізніше, після відновлення нормального функціонування передавання даних. У межах системи «Сбор» інформація від вимірювальних систем, тобто немережевих абонентів, має передаватися через віддалений концентратор до центру збору та обробки даних, а керівна інформація з центру має доставлятися назад до вимірювальних систем через віддалений концентратор.

2. ТЕХНІЧНІ ХАРАКТЕРИСТИКИ

2.1. Постановка задачі розроблення програмного забезпечення віддаленого концентратора

Програмне забезпечення віддаленого концентратора є складовою частиною загального програмного забезпечення системи «Сбор». Його не можна розглядати окремо від основних задач, які розв’язує система в цілому.

Основна задача полягає у створенні єдиного апаратно-програмного середовища, яке охоплює всіх користувачів системи «Сбор» і призначене для збору та обробки даних.

Для побудови такого середовища до всіх користувачів мають застосовуватися такі загальні принципи (вимоги):

• єдине середовище передавання даних;
• єдині принципи організації даних і доступу до них.

У віддаленому концентраторі ці принципи реалізуються шляхом використання тієї самої операційної системи та мережевого пакета, що й в обчислювальних системах центру збору даних.

Крім загальних вимог, віддалений концентратор має виконувати такі спеціальні вимоги, що випливають із тактико-технічних вимог (ТТВ) і спеціального технічного завдання (СТЗ):

• обмін даними із заданим набором вимірювальних засобів відповідно до визначених інтерфейсних і роз’ємних узгоджень;
• надійне виконання функціональних задач із необхідним рівнем автоматизації;
• достатня продуктивність (пропускна здатність).

Перша вимога виконується шляхом розроблення ПЗ ВК, яке підтримує протоколи обміну з наявними вимірювальними системами. До таких систем належать типи «Вега-Н», «Вега-К», «Вега-Т» і «Кама-А». Підключення нових вимірювальних систем до віддаленого концентратора потребує розроблення нових програм обміну без зміни ядра програмного забезпечення.

Виконання другої вимоги з погляду програмного забезпечення означає, що ВК має послідовно й адекватно реагувати на виняткові ситуації, які виникають під час обміну даними, і бути здатним розв’язувати такі ситуації з мінімальним втручанням людини (оператора).

Виконання третьої вимоги передбачає високу продуктивність обчислювальних засобів, що входять до складу ВК.

Повний вплив програмного забезпечення на виконання вимог до продуктивності ВК може бути оцінений під час розроблення робочих програм.

Відповідно до ТТВ/СТЗ, ВК має забезпечувати такі характеристики продуктивності:

• одночасний обмін даними з вимірювальними системами на швидкостях до 9600 біт/с;
• обмін даними з центром збору, включно з передаванням у реальному часі, на швидкостях до 9600 біт/с.

2.1.1. Склад апаратних засобів

Визначено два типи віддалених концентраторів (ВК) залежно від їхніх функціональних можливостей (див. рисунок 2.1) і місця встановлення.

a)

b)

Рисунок 2.1

Віддалений концентратор (ВК), див. рисунок 2.1(a), установлюється на вимірювальних пунктах (ВП) і призначений для обміну даними з вимірювальними системами (ВС) та Центром збору й обробки інформації (ЦЗОІ).

ВК (NI525.01), див. рисунок 2.1(b), установлюється в ЦЗОІ та може виконувати такі функції:

1. мережевий сервер центру збору;
2. ВК центру збору з функціями та програмним забезпеченням, аналогічними NI525.

Наразі функції 1 і 2 для NI525.01 є взаємовиключними. У майбутньому передбачається їх інтеграція.

Мережевий сервер призначений для збору даних від ВК, розташованих на вимірювальних пунктах. Спільна частина програмного забезпечення мережевого сервера та NI525 включає програми, що забезпечують формування, завантаження та роботу програмного забезпечення процесора синхронізації (SP).

Персональний комп’ютер, що входить до складу ВК, має 2–4 МБ оперативної пам’яті та 80–120 МБ дискової пам’яті. Мультиплексор, що входить до складу ВК, забезпечує спряження між персональним комп’ютером і процесором синхронізації через асинхронну інтерфейсну лінію RS232.

До функцій процесора синхронізації належать:

• електричне та логічне спряження між виходами вимірювальних систем і входом персонального комп’ютера;
• перетворення асинхронних даних у синхронні для спряження асинхронного виходу персонального комп’ютера із синхронним входом апаратури передавання даних.

Структуру процесора синхронізації показано на рисунку 2.2:

Рисунок 2.2

2.1.2. Інформаційні потоки через віддалений концентратор

Для визначення функціональності ПЗ ВК необхідно проаналізувати інформаційні потоки, що проходять через ВК. Ці потоки показано на рисунку 2.3.

Рисунок 2.3

Потік 1 являє собою потік «задачної» інформації, що передається з центру до вимірювальних систем (ВС).

Потік 2 означає транзитне передавання вимірювальних даних від вимірювальних систем до центру.

Потік 3 являє собою дані, що надходять від ВС до центру з одночасним транзитним передаванням і записом на диск. Такий підхід допомагає зберегти дані у випадку нестійкого зв’язку з центром під час сеансу.

Потік 4 використовується для передавання даних від ВС до ВК у разі пошкодження лінії зв’язку з центром. Ці дані зберігаються на диску та передаються пізніше за запитом із центру, тобто після відновлення зв’язку.

Потік 5 описує випадок, коли ВС не може приймати дані від ВК, наприклад через відсутність приймального програмного забезпечення. У таких випадках задача з центру може бути виведена на зовнішній пристрій, наприклад принтер, для ручної доставки до ВС.

Потік 6 призначений для передавання накопичених даних від ВК до центру після завершення сеансу вимірювань.

Наразі ПЗ ВК зосереджується на реалізації здійсненних потоків, тобто потоків з 2 по 6. Потік 1, за потреби, може бути підтриманий шляхом додавання окремої програми без зміни основного ПЗ ВК.

2.1.3. Вибір операційної системи

Як зазначалося раніше, вибір операційної системи для ВК насамперед визначається метою створення єдиного середовища збору й обробки інформації на центральному об’єкті. Як базову операційну систему для цього середовища було обрано UNIX.

Ключові переваги ОС UNIX включають:

• багатозадачність;
• переносність ОС;
• багатокористувацький режим;
• сильний захист від несанкціонованого доступу;
• підтримку мов структурного програмування;
• розвинені засоби налагодження;
• потужні графічні діалогові засоби;
• наявність мережевих програмних пакетів;
• сумісність із командами та файлами MS-DOS;
• відсутність вірусів.

2.1.4. Вибір мережевого середовища

Необхідність побудови єдиної системи збору та обробки вимірювальних даних зумовила використання уніфікованого комунікаційного середовища як для віддалених елементів системи «Сбор», так і для центральних комп’ютерів обробки даних.

Ця вимога виконується завдяки використанню мережевого пакета TCP/IP, реалізованого в системі UNIX.

Це мережеве програмне забезпечення підтримує як розподілені, так і локальні мережі.

Основні можливості мережевого пакета включають:

• обмін файлами між вузлами мережі;
• доступ до віддалених файлів із терміналів і прикладних програм користувачів;
• міжпроцесну взаємодію між процесами на різних вузлах, що дає їм змогу обмінюватися даними;
• міжтермінальну взаємодію;
• та інші можливості.

3. СТРУКТУРА ТА СКЛАД ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ВІДДАЛЕНОГО КОНЦЕНТРАТОРА

Програмне забезпечення віддаленого концентратора (ВК) у складі системи «Сбор» складається з двох основних компонентів:

• системного програмного забезпечення (операційна система, компілятори, драйвери тощо);
• прикладного програмного забезпечення (спеціалізовані програми ВК, що реалізують функції, описані в розділі 1).

Склад і структуру ПЗ ВК схематично показано на рисунку 3.1.

Рисунок 3.1

3.1. Системне програмне забезпечення віддаленого концентратора

Системне програмне забезпечення віддаленого концентратора (ВК) складається з таких компонентів:

• системне програмне забезпечення персонального комп’ютера (ПК);
• системне програмне забезпечення процесора синхронізації (SP).

Структуру системного програмного забезпечення ВК показано на рисунку 3.2.

3.1.1. Системне програмне забезпечення ПК

Системне програмне забезпечення ПК є набором програмних засобів, відповідальних за керування апаратними ресурсами ПК і координацію взаємодії між прикладними процесами та апаратними модулями ВК.

Системне програмне забезпечення ПК включає:

• стандартне програмне забезпечення ПК;
• драйвери пристроїв;
• мережеве програмне забезпечення.

Стандартне програмне забезпечення ПК включає операційну систему UNIX, яка виконує такі функції:

• керування пам’яттю;
• керування введенням/виведенням;
• керування файловою системою;
• керування взаємодією процесів;
• планування та диспетчеризація процесів;
• захист від несанкціонованого доступу;
• облік використання ресурсів;
• обробка командної мови.

Рисунок 3.2

Окрім ОС UNIX, стандартне програмне забезпечення ПК включає системні службові програми, компілятори та інші засоби розроблення програмного забезпечення, що використовуються для розроблення й налагодження ПЗ ВК:

• SCO VP/IX MS-DOS in the UNIX environment — емулятор MS-DOS під ОС UNIX;
• ICAM Russification Tool Kit for SCO XENIX System V/286/386 2.3, призначений для локалізації службових програм ОС російською мовою;
• компілятор C для UNIX;
• службова програма передавання файлів між середовищами MS-DOS і UNIX;
• текстовий редактор в UNIX;
• реасемблер в UNIX, що використовується для повторного асемблювання стандартних програм-драйверів в ОС UNIX;
• X-WINDOW — програмний комплекс, що полегшує розроблення ефективних людино-машинних інтерфейсів;
• символьний налагоджувач Sdb, який використовується для покращення виявлення та виправлення помилок під час розроблення програм мовою C під UNIX;
• перевіряльник синтаксису файлів C LINT для виявлення синтаксичних помилок;
• транслятор асемблера для UNIX, що використовується під час розроблення драйверів.

Важливим компонентом системного програмного забезпечення ПК є набір драйверів:

• драйвер MULTISERIAL-8;
• драйвер MULTISERIAL-16.

Для організації зв’язку між ПК і процесором синхронізації (SP) планується використання стандартного термінального драйвера. Цей драйвер підтримує мультиплексор MULTISERIAL-8/16. Під час розроблення буде оцінено доцільність реалізації спеціальних драйверів для потрібних протоколів обміну з SP. Це розглядатиметься у випадку, якщо продуктивності стандартного термінального драйвера буде недостатньо для виконання технічних вимог.

Ще одним компонентом системного програмного забезпечення є мережеве програмне забезпечення. Основна мережева функція полягає у транспортуванні даних лініями зв’язку між кількома ВК і центральним вузлом, а також у зворотному напрямку.

У мережевій частині системи «Сбор» як основний засіб у середовищі ОС UNIX використовується стек протоколів TCP/IP.

Стек TCP/IP є програмним пакетом, що складається з двох взаємопов’язаних протоколів:

• IP — Internet Protocol;
• TCP — Transmission Control Protocol.

Основна функція протоколу IP — доставляти блоки даних, що називаються датаграмами, від джерела до призначення. Датаграма містить заголовкову інформацію для маршрутизації та секцію даних. За потреби IP підтримує фрагментацію і повторне складання датаграм відповідно до властивостей фізичної мережі. Фрагменти можуть надходити не за порядком і потім збираються належним чином. Якщо будь-який фрагмент втрачено, уся датаграма вважається втраченою, що створює питання надійності.

Протокол TCP працює над протоколом IP і забезпечує надсилання та приймання сегментів змінної довжини, інкапсульованих у датаграми IP. Мета TCP — встановити надійний зв’язок між парами процесів. Надійність забезпечується перевіркою контрольної суми, поверненням коду помилки, байтовою нумерацією послідовності та вимогою підтвердження. Копія кожного сегмента ставиться в чергу для повторного передавання, і запускається таймер. Якщо підтвердження не отримано вчасно, сегмент передається повторно.

Транспортний протокол обробляє доставку користувацьких даних між конкретними портами (сокетами), які є точками доступу до транспортної служби. Для зв’язку потрібне встановлення з’єднання між двома процесами, під час якого обидві сторони формують інформацію про стан. Вона включає адреси, номери послідовності даних, розмір вікна, що вказує допустимий діапазон передавання за останнім підтвердженим байтом, і утворює структуру, відому як блок керування з’єднанням. Після завершення з’єднання ресурси звільняються.

Протоколи транспортного рівня повинні мати унікальний ідентифікатор у полі “Protocol” заголовка IP.

3.1.2. Системне програмне забезпечення процесора синхронізації (SP)

Системне програмне забезпечення SP виділено в окрему групу з таких причин:

1. процесор узгодження, будучи компонентом віддаленого концентратора (ВК), не має власної операційної системи, тому його програмне забезпечення має розроблятися автономно під ОС персонального комп’ютера;

2. програмне забезпечення SP складається з досить великого набору прикладних програм: драйверів, програм передавання, тестування, завантажувачів тощо;
3. технологія виготовлення SP, особливо програмування ПЗП, орієнтована на використання операційної системи MS-DOS.

З цих причин автономні програмні засоби, що використовуються під час розроблення ПЗ SP, включають такі системні службові програми:

• операційна система MS-DOS;
• компілятор асемблера для MS-DOS, що використовується під час розроблення програм SP;
• редактор зв’язків у MS-DOS для побудови прикладних програм SP;
• налагоджувач мови асемблера в MS-DOS для ефективного налагодження програм, що розробляються;
• реасемблер для перебудови стандартних драйверів та інших програм, доступних лише у вигляді двійкових модулів;
• текстовий редактор у MS-DOS для підготовки документації програмного забезпечення SP;
• NORTON — засіб керування файлами;
• компілятор Quick-C — використовується для тестування алгоритмів програм.

3.2. Прикладне програмне забезпечення

Прикладне програмне забезпечення призначене для виконання функцій, визначених у розділі 1. Прикладне ПЗ ВК за призначенням можна поділити на три групи:

• автономне;
• інтегроване (комплексне);
• сервісне.

3.2.1. Автономне програмне забезпечення

Структуру автономного програмного забезпечення показано на рисунку 3.3. Як видно зі схеми, воно складається з таких основних компонентів:

• програмне забезпечення ініціалізації;
• програмне забезпечення конфігурування ВК для заданого складу вимірювальних систем (ВС);
• діагностичне програмне забезпечення ВК.

3.2.1.1. Програмне забезпечення ініціалізації

Програмне забезпечення ініціалізації готує ВК до роботи. Воно включає таку програму:

• тестова програма;

Рисунок 3.3

Програма завантаження ПЗ SP з боку SP;

Програма завантаження ПЗ SP через інтерфейс C2 з боку ПК;

Програма ініціалізації адаптера.

Тестова програма виконує діагностику процесорів і оперативної пам’яті процесора синхронізації (SP) після вмикання живлення. Ця програма прошита в ПЗП кожного процесора SP.

Алгоритм тестової програми описано в розділі 3.4.1.

Програма завантаження ПЗ SP з боку SP завантажує програми в оперативну пам’ять SP із файлової системи, розташованої на ПК. Вона також зберігається в ПЗП кожного процесора SP. Завантаження виконується в діалоговому режимі з програмою-завантажувачем через інтерфейс C2 з боку ПК. Протокол обміну під час завантаження відповідає GOST 28079-89 (протокол BSC). Завантаження може виконуватися будь-якою з доступних ліній зв’язку між ПК і SP, які можуть перемикатися під час процесу. Завантаження виконується послідовно для кожного процесора, після чого лінії зв’язку звільняються для обміну даними.

Ці програми-завантажувачі також можуть читати оперативну пам’ять і передавати дані до ПК перед передаванням керування прикладним програмам. Алгоритм їх роботи описано в розділі 3.4.2.

Програма-завантажувач з боку ПК завантажує ПЗ SP і необхідні структури даних у SP. Усе програмне забезпечення та структури зберігаються у файловій системі ПК. Алгоритм роботи наведено в розділі 3.4.3.

Програма ініціалізації адаптера переводить адаптери NI599-08 і NI599-06, що входять до складу SP, у робочий стан для приймання та передавання даних у межах SP. Її алгоритм описано в розділі 3.4.4.

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

Це програмне забезпечення дає змогу налаштовувати ВК для різних конфігурацій його взаємодії з вимірювальними системами (ВС): підтримка протоколу BSC, симплексного протоколу тощо. Структуру показано на рисунку 3.3.

3.2.1.3. Діагностичне програмне забезпечення віддаленого концентратора

Структуру показано на рисунку 3.3. Це програмне забезпечення контролює стан апаратури ВК. Воно включає як автономну діагностику, так і компоненти безперервного контролю.

Автономне діагностичне програмне забезпечення включає таке:

• діагностична програма на базі ПК для автономних перевірок ВК;
• діагностична програма на базі SP;
• програмне забезпечення для автономної діагностики зв’язку із зовнішніми вузлами (ВК–центр, ВК–ВС);
• засіб читання пам’яті SP.

Діагностичний засіб на базі ПК призначений для перевірки апаратури ВК в автономному режимі, наприклад під час технічного обслуговування. Він контролює ПК, SP, лінії зв’язку між ними та адаптери SP і працює разом із діагностичними програмами на базі SP.

Діагностичні програми на базі SP взаємодіють із діагностикою ПК. Вони базуються на програмах безперервного тестування, описаних у наступному розділі.

Діагностика зв’язку із зовнішніми системами (ВК–центр і ВК–ВС) призначена для швидкого оцінювання якості зв’язку ВК. Діагностика зв’язку з ВС передбачає наявність підтримувального програмного забезпечення на ВС. Оскільки таке програмне забезпечення наразі відсутнє, у ВК замість нього використовується заглушка.

Діагностика зв’язку з центром може бути реалізована передаванням файла: центр надсилає заздалегідь визначений файл до ВК, який порівнює його з еталоном. Результат визначає якість зв’язку.

Програмне забезпечення безперервного контролю перевіряє роботу SP і зв’язок ПК–SP під час штатної роботи ВК. Воно розгортається як на ПК, так і на кожному процесорі SP.

Засіб читання пам’яті SP — це програма з боку ПК, яка перевіряє цілісність оперативної пам’яті SP. Вона порівнює завантажену програму й дані з еталонними сегментами на ПК і повідомляє про повноту та правильність. Алгоритм тут не деталізується і буде реалізований після завершення програмного забезпечення завантажувача через C2. Наразі використовується заглушка.

Повідомлення даних режиму відтворення мають структуру, показану на рисунку 3.10.

Рисунок 3.10

Повідомлення режиму відтворення можуть містити різні дані та відрізнятися за довжиною. Зміст будь-якого повідомлення визначається його вимірювальною інформацією (MI).

Вимірювальна інформація має такі значення:

• 1 - початкове повідомлення режиму відтворення;
• 2 - повідомлення оброблених системних даних;
• 3 - повідомлення коефіцієнтів кореляції оцінок вихідних параметрів;
• 4 - повідомлення часу реєстрації сигналів;
• 10 - повідомлення режиму реального часу;
• 11 - початкове повідомлення режиму реального часу;
• 12 - кінцеве повідомлення режиму реального часу;
• 13 - порожнє повідомлення режиму реального часу;
• 14 - повідомлення координат антенного поля;
• 15 - повідомлення еталона якості інформації;
• 16 - повідомлення.

Отже, повідомлення з MI 10, 11, 12, 13 є повідомленнями режиму реального часу, а повідомлення з MI 1, 2, 3, 4 — повідомленнями режиму відтворення.

Перед передаванням у лінію повідомлення від вимірювальної системи «Вега» обрамляється керівними символами та символами захисту від помилок відповідно до протоколу обміну GOST 17422-72 (див. розділ 3.3.3).

3.3.2. Структура даних вимірювальної системи «Кама-А»

Дані, що надходять від вимірювальної системи «Кама», подаються послідовністю повідомлень типу, показаного на рисунку 3.11.

Рисунок 3.11

Повідомлення складається з послідовності бітів і має фіксовану довжину.

Повідомлення починається з 5-бітового маркера, після якого йдуть 60 бітів інформації. Його структуру показано на рисунку 3.12.

Рисунок 3.12

Маркер має двійковий код 11011.

Повідомлення від вимірювальної системи «Кама-А» надходить до персонального комп’ютера від процесора синхронізації (SP) як послідовність із 13 байтів.

Тут байт 0 є маркером повідомлення, а байти з 1 по 12 містять власне інформацію.

Структуру байтів, отриманих від SP, показано на рисунку 3.13.

Рисунок 3.13

Біти 0–4 містять власне інформацію від вимірювальної системи «Кама-А», а біти 5–7 вказують порядковий номер вимірювальної системи «Кама-А», від якої повідомлення надійшло цим каналом.

Повідомлення, що передаються до мережі та зберігаються у файловій системі ВК, мають структуру, показану на рисунку 3.14.

Рисунок 3.14

Маркер початку повідомлення та 60 бітів інформації пакуються в 9 байтів повідомлення від вимірювальної системи «Кама» так, щоб утворити безперервну послідовність бітів. У результаті останні 8 байтів містять лише по одному, молодшому, інформаційному біту.

3.3.3. Протокол обміну даними з вимірювальною системою «Вега»

Текст повідомлення від системи «Вега» передається в прозорому режимі, тобто передавана інформація розглядається як двійкові коди.

Наприкінці кожного блока передається блокова контрольна послідовність (BCS). Використовуються циклічні надлишкові коди з породжувальним поліномом
X**16 + X**12 + X**5 + 1 відповідно до GOST 17422-72.

3.3.3.1. Керівні та службові символи протоколу

Керування обміном здійснюється за допомогою спеціальних службових символів (SS) і керівних послідовностей (CS), вибраних із дозволеного набору GOST 19767-74. Нижче наведено опис використаних символів і CS.

STX — Start of Text.

Символ STX надсилається передавальною станцією на початку тексту користувацьких даних. Якщо текст поділено на блоки, STX надсилається на початку кожного блока. На приймальному боці цей символ, як і інші службові символи, не поміщається в буфер користувача.

ETB — End of Transmission Block.

Якщо повідомлення поділено на блоки, передавальна станція додає цей символ наприкінці блока даних, а потім передає блокову контрольну послідовність. ETB спонукає приймальну станцію надати відповідь.

ETX — End of Text.

Символ ETX означає кінець інформаційного повідомлення. Якщо повідомлення поділено на блоки, ETX використовується для завершення останнього блока даних замість ETB. Після символу ETX іде BCS. ETX спонукає приймальну станцію надати відповідь.

EOT — End of Transmission.

Надсилаючи EOT у складі керівної послідовності, передавальна станція сигналізує про завершення або призупинення передавання; обидві станції переходять у стан контролю лінії.

Приймальна станція також може надіслати EOT, щоб повідомити про неможливість продовжувати приймання даних.

ENQ — Enquiry ("Who's there?")

Символ ENQ використовується передавальною станцією в кількох ситуаціях.

Перед початком передавання повідомлення передавальна станція використовує ENQ, щоб запитати, чи готова приймальна станція. Надсилання ENQ наприкінці блока даних замість ETB або ETX означає, що блок слід ігнорувати. Після надсилання блока даних передавальна станція використовує ENQ, щоб спонукати приймач до відповіді, якщо протягом певного часу відповіді немає, або щоб повторити останню відповідь.

AR10 — Even Positive Acknowledgement

Послідовність символів DLE і 0 використовується приймальною станцією у двох випадках:

• у відповідь на початковий ENQ — щоб повідомити передавач про готовність до приймання;
• у відповідь на кожен парний блок — якщо блок прийнято успішно і приймач готовий до наступного блока.

AR11 — Odd Positive Acknowledgement

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

NAK — Negative Acknowledgement

У відповідь на початковий ENQ приймальна станція повідомляє передавач, що вона не готова приймати повідомлення. Під час передавання приймальна станція використовує NAK, щоб вказати, що останній блок було прийнято з помилками, і запитує повторне передавання.

SYN — Synchronization

Керівний символ SYN використовується для встановлення та підтримання синхронізації між станціями. Щонайменше два послідовні символи SYN надсилаються перед кожним інформаційним блоком і перед кожною керівною послідовністю. Додатково передавальна станція надсилає SYN приймачу щонайменше один раз на секунду під час передавання.

DLE ; — Receiver Delay

Приймальна станція використовує послідовність DLE ;, щоб повідомити, що останній блок прийнято правильно, але вона тимчасово не готова прийняти наступний блок.

STX ENQ — Transmitter Delay

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

DLE < — Change of Transmission Direction

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

Оскільки прозоре передавання може призвести до збігу користувацьких даних із керівними символами, використовуються такі escape-послідовності, у яких DLE вставляється перед керівними символами STX, ETB, ETX, ENQ і SYN:

DLE STX — початок прозорого тексту,

DLE ETB — кінець прозорого блока тексту,

DLE ETX — кінець прозорого тексту,

DLE ENQ — ігнорувати цей прозорий текст,

DLE SYN — синхронізація під час передавання прозорого тексту.

Якщо необхідно передати символ DLE як частину користувацьких даних, він подвоюється.

На приймальному боці додаткові символи DLE, а також керівні символи, вилучаються.

3.3.3.2. Формати інформаційних і керівних послідовностей

Прийнято такі позначення:

• SYN — коди SYN;
• FF — байт одиниць;

Рисунок 3.15

Керівні послідовності показано на рисунку 3.16.

Рисунок 3.16

3.3.3.3. Базові процедури обміну

Основні процедури обміну схематично показано нижче.

Для простоти повний формат даних і керівних послідовностей не показано.

Нормальне передавання повідомлення показано на рисунку 3.17.

Рисунок 3.17

Запит без відповіді показано на рисунку 3.18.

Рисунок 3.18

Режим конфлікту ініціативи, тобто взаємної ініціативи, показано на рисунку 3.19.

Рисунок 3.19

Повторне передавання блока, прийнятого з помилкою, показано на рисунку 3.20.

Рисунок 3.20

Повторне передавання відхиленого блока показано на рисунку 3.21.

Рисунок 3.21

Запит затримки приймача показано на рисунку 3.22.

Рисунок 3.22

Запит затримки передавача показано на рисунку 3.23.

Рисунок 3.23

Помилку формату показано на рисунку 3.24.

Рисунок 3.24

Помилку послідовності підтверджень без виправлення показано на рисунку 3.25.

Рисунок 3.25

Помилку послідовності підтверджень із виправленням показано на рисунку 3.26.

Рисунок 3.26

Випадок, коли приймач не відповідає, показано на рисунку 3.27.

Рисунок 3.27

Випадок, коли передавач не продовжує передавання, показано на рисунку 3.28.

Рисунок 3.28

Помилку буфера на боці передавача показано на рисунку 3.29.

Рисунок 3.29

Помилку зовнішнього пристрою на боці передавача показано на рисунку 3.30.

Рисунок 3.30

Помилку або переповнення буфера, або помилку зовнішнього пристрою

на боці приймача показано на рисунку 3.31.

Рисунок 3.31

Зміну напряму передавання показано на рисунку 3.32.

Рисунок 3.32

3.3.3.4. Формування блокових контрольних послідовностей

Формування BCS має починатися після першого керівного символу блока — STX або керівної послідовності DLE STX. Ці керівні символи або керівні послідовності на початку блока не повинні включатися до розрахунку BCS.

Під час формування BCS мають включатися всі символи, передані після початкового керівного символу або керівної послідовності блока даних до кінцевого символу ETB або ETX у стандартному режимі, або до кінцевої керівної послідовності DLE ETB чи DLE ETX у кодонезалежному режимі, за винятком:

1) символів SYN у стандартному режимі або послідовностей DLE SYN у кодонезалежному режимі;

2) першого символу DLE у керівних послідовностях DLE ETB, DLE ETX або DLE DLE.

BCS має передаватися безпосередньо після керівного символу ETB або ETX у стандартному режимі, або після керівної послідовності DLE ETB чи DLE ETX у кодонезалежному режимі.

3.3.4. Протокол обміну з вимірювальною системою «Кама-А»

Процес передавання вимірювальних даних від вимірювальної системи «Кама-А» до ПК відбувається в симплексному режимі. Тому між ПК і вимірювальною системою «Кама-А» жодні протоколи обміну не підтримуються.

3.3.5. Організація даних програмного забезпечення процесора синхронізації

Для належної роботи програмного забезпечення SP оперативна пам’ять SP має бути розподілена, а місце під дані — зарезервоване (див. таблицю 1).

Дані SP організовані в таблиці та області пам’яті, які використовуються програмним забезпеченням SP для взаємодії з лініями зв’язку — як між лініями, так і між процесорами.

Основні типи даних SP такі:

• таблиці типів векторів переривань для кожного процесора SP;
• таблиці конфігурації процесорів;
• поштові скриньки (MB) в області спільної оперативної пам’яті системи;
• семафор завантаження програмного забезпечення SP.

Вводиться поняття «інформаційний канал». Це поняття не передбачає жодних фізичних пристроїв. Воно означає будь-який конкретний потік даних або від вимірювальної системи (MS), або від центру збору даних. Канал розуміється як потік інформації, що проходить через MS в одному з напрямів. За допомогою цього поняття вхідні та вихідні адреси MS і ПК логічно пов’язуються. Номери каналів можуть призначатися довільно, наприклад, шляхом зіставлення з номерами рядків у таблиці конфігурації процесів.

Номер підканалу використовується для ідентифікації даних від кількох систем «Кама». Кожен байт від «Кама» має довжину 5 бітів, тобто 3 біти залишаються невикористаними й можуть застосовуватися для ідентифікації до восьми пристроїв MS типу «Кама». Це дає змогу передавати дані від восьми систем «Кама» до ПК однією телефонною лінією, а потім розділяти їх усередині ПК.

Константа лічильника визначає швидкість передавання/приймання даних. У таблиці конфігурації процесора для константи лічильника виділено два байти. Константа задається як двобайтове шістнадцяткове число (див. сторінку 74, таблицю 3 у розділі 3).

У таблиці конфігурації процесора для адреси мікросхеми виділено два байти. Адреса мікросхеми описується як чотирисимвольне шістнадцяткове число. Молодший байт задає зміщення відносно адреси блока. У старшому байті молодші чотири біти визначають номер блока (1–5 для блоків NI599-08, 6–10 для блоків NI599-06). Старші чотири біти мають містити шістнадцяткове значення F.

Термін «адресат» означає тип MS, наприклад Vega або Kama, а також мережу і канал безперервного тестування. Однобайтове значення, що відповідає типу адресата, записується в таблицю.

Адаптери можуть бути двох типів:

• C1 (0001);
• C2 (0011).

Для типу адаптера в таблиці конфігурації процесів виділено чотири біти. Тип адаптера подається однією шістнадцятковою цифрою.

Режим роботи мікросхеми може бути таким:

• синхронний (00);
• асинхронний (11).

Для режиму роботи в таблиці конфігурації процесора виділено два біти.

Довжина байта може бути такою:

• 5 (00);
• 8 (11).

Для довжини байта в таблиці конфігурації процесора виділено два біти.

Існує два типи контролю парності:

• парна парність (11);
• непарна парність (01).

Для типу контролю парності в таблиці конфігурації процесора виділено два біти.

Під час роботи в синхронному режимі задається кількість символів синхронізації:

• один символ синхронізації (01);
• два символи синхронізації (11).

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

Можуть використовуватися такі символи синхронізації:

• SYN;
• DLE SYN;
• DLE STX.

Для кожного символу синхронізації в таблиці конфігурації процесора виділено один байт. У таблицю записується шістнадцятковий код символу синхронізації.

Довжина стоп-біта може бути такою:

• два біти (11);
• півтора біта (10);
• один біт (01).

Для колонки «довжина стоп-біта» в таблиці конфігурації процесора виділено два біти.

Для колонки «резерв» у таблиці конфігурації процесора також виділено два біти.

Загальна довжина таблиці конфігурації процесора становить 169 байтів, як зазначено в таблицях 2 і 3.

У таблицях 2 і 3 наведено приклади конфігурацій процесорів ВК, що працює з однією системою «Вега» та чотирма системами «Кама». Рядок 1 в обох таблицях містить дані для ВС «Вега», рядки 2–5 — для пристроїв ВС «Кама», рядок 6 — для мережі, а рядок 7 — для каналу безперервного тестування.

3.3.5.3. Область поштової скриньки

Для забезпечення узгодженої роботи процесорів у SP передавання даних виконується через область спільної пам’яті. У цій спільній пам’яті розміщуються поштові скриньки (MB), куди один процесор записує інформацію, а інший її читає. Кожна MB поділяється на дві частини. MB використовується для підтримки інформаційного каналу. Зустрічні потоки даних одного каналу проходять через відповідні частини MB (рисунок 3.33).

Рисунок 3.33

Наприклад, канал зв’язку з ВС «Вега» передбачає синхронне напівдуплексне передавання даних. Тому перша частина MB може використовуватися для передавання повідомлень від «Веги», а друга частина — для передавання підтверджень до «Веги». Аналогічно MB може використовуватися для будь-якого іншого каналу.

Для підтримки кількох каналів зручно розміщувати всі MB у пам’яті послідовно, без проміжків. У цьому випадку для доступу до MB може використовуватися базова адреса (назвемо її BOX). Для наочності кожній MB присвоюється номер відповідно до її зміщення від базової адреси BOX. Щоб програми однаково «розуміли», яка MB якій сутності відповідає, номер MB вважається таким, що збігається з номером каналу з таблиць конфігурації процесора.

Виходячи з архітектури ВК, максимальна кількість MB (що дорівнює максимальній кількості інформаційних каналів і, відповідно, кількості рядків у таблиці конфігурації процесора) становить 13.

Кожна з двох частин MB містить біт-індикатор наявності даних. Це молодший біт у молодшому байті кожної частини MB. Якщо біт установлено, дані в цій частині MB наявні. Якщо біт скинуто, дані відсутні. Для кожної частини MB виділяється 56 байтів (хоча оперативна пам’ять SP дає змогу використовувати більший розмір) (див. рисунок 3.34).

Рисунок 3.34

Молодший байт кожної MB називається байтом стану. У ньому зберігаються прапорці, які використовуються програмами, що працюють з MB. Молодший біт кожного байта стану зарезервовано як біт наявності даних.

3.3.5.4. Концепція використання поштової скриньки

Щоб структура даних не залежала від способу зберігання та щоб спростити обмін даними між процесорами, використовується кільцевий буфер. Програми ПЗ SP звертаються до MB через стандартні процедури:

• читання байта з буфера
• запис байта до буфера

Кільцевий буфер має «голову» — позицію, куди записуються дані, і «хвіст» — позицію, звідки дані читаються. Кільцевий буфер показано на рисунку 3.35.

Рисунок 3.35

Перші шість байтів містять службову інформацію. У кожній 50-байтовій частині MB для даних виділено 44 байти. Відповідно до рисунка 3.35, завантаження буфера починається з комірки, що йде після п’ятого байта. Коли досягається кінець MB, нові байти знову записуються, починаючи з байта після п’ятого. Під час операцій запису/читання позиції 1, 2 і 3 використовуються для відстеження «хвоста», «голови» та різниці між ними.

Умови правильної роботи кільцевого буфера:

• «хвіст» не повинен обганяти «голову».

• різниця між «головою» і «хвостом» не повинна перевищувати фізичну довжину буфера (44 байти).

Стан частини MB до завантаження в неї даних показано на рисунку 3.36. Така ситуація виникає одразу після завантаження ПЗ SP в оперативну пам’ять SP.

3.3.6. Структура завантаження сегментів

Дані та програми, що завантажуються в SP з боку ПК, зберігаються у файлах на жорсткому диску ПК. Інформація про ці файли збирається в таблицю, що зберігається у файлі сегментів на тому самому диску. Структуру файла сегментів описано в розділі 3.3.7.

Рисунок 3.37

Усі дані, що передаються до SP, поділяються на повідомлення. Кожне повідомлення містить дані з одного файла.
Структуру повідомлення показано на рисунку 3.38.

Рисунок 3.38

Формування цієї послідовності описано в розділі 3.3.3.4.
Структура тексту повідомлення, що передається, може мати одну з трьох форм залежно від потрібної дії: читання, запису або запуску програми на виконання. Дія, яку потрібно виконати, задається індикатором типу передавання, що може набувати таких значень (стосовно NI 526A):

• 2 — передати дані;
• 3 — прийняти дані;
• 4 — запустити програму на виконання.

Структуру повідомлення передавання показано на рисунку 3.39.

Рисунок 3.39

Структуру повідомлення запуску програми показано на рисунку 3.40.

Рисунок 3.40

Структуру повідомлення запиту читання пам’яті для системи керування показано на рисунку 3.41.

Рисунок 3.41

3.3.7. Файлова система віддаленого концентратора

Файл завантаження сегментів визначає відповідність між номерами сегментів, іменами файлів, що містять дані для завантаження в SP, і адресами в пам’яті SP, куди ці дані мають бути завантажені.
Файл завантаження сегментів є масивом структур такого типу:

            struct {
                char ;   /* Номер сегмента */
                int  ;   /* Адреса, за якою виконується завантаження */
                int  ;   /* Зміщення в сегменті, за яким виконується завантаження */
            };
            

Файл «Конфігурація ВП» визначає відповідність між номерами ліній мультиплексора та пристроями ВС.
Файл «Конфігурація ВП» є масивом структур такого типу:

            struct {
                char ; /* Номер лінії мультиплексора */
                char ; /* Тип ВС: 0 - немає ВС; 1 - ВС «Вега»; 2 - ВС «Кама»;
                           3 - мережа; 4 - тестова лінія */
            };
            

Файл сегмента ініціалізації векторів переривань визначає відповідність між номерами переривань і адресами, за якими розміщені відповідні програми обробки переривань.
Файл сегмента ініціалізації векторів переривань є масивом структур такого типу:

                struct {
                  char ; /* Номер вектора переривання */
                  int  ; /* Адреса сегмента програми обробки переривання */
                  int  ; /* Зміщення в сегменті програми обробки переривання */
                };
            

Файл сегмента процесора визначає відповідність логічного каналу для процесорів SP на вході та виході SP, а також містить іншу інформацію, необхідну для ініціалізації апаратури SP.
Файл сегмента процесора є масивом структур такого типу:

                struct {
                  char ;       /* Канал */
                  char ;       /* Тип переривання приймання */
                  char ;       /* Тип переривання передавання */
                  char ;       /* Номер підканалу */
                  char ;       /* Константа лічильника */
                  int  ;       /* Адреса мікросхеми */
                  char [2];    /* Адресат */
                  struct {
                    unsigned : 4; /* Тип адаптера */
                    unsigned : 2; /* Режим роботи */
                    unsigned : 2; /* Довжина байта */
                    unsigned : 2; /* Тип контролю парності */
                    unsigned : 2; /* Кількість символів синхронізації */
                    unsigned : 2; /* Довжина стоп-біта */
                    unsigned : 2; /* Резерв */
                  };
                  char ;       /* Перший символ синхронізації */
                  char ;       /* Другий символ синхронізації */
                };
            

Для кожного процесора створюється окремий сегмент процесора.

Файл сегмента образу спільної пам’яті є масивом 50-байтових записів, загалом 26 елементів. У кожному записі другий і третій байти ініціалізуються значенням 6, тоді як усі інші байти встановлюються в 0.

Файли ПЗ SP — це файли, що містять двійкові образи програм, які завантажуються в SP. Ці файли є результатом компіляції з вихідних текстів мовою C та мовою асемблера.

Інформація, отримана від пристроїв ВС, зберігається у файловій системі ВК. Під час організації зберігання вхідних даних ВС програми обробки повідомлень створюють окремий файл для кожної ВС з унікальним іменем. Ім’я файла для заданої ВС формується за схемою, показаною на рисунку 3.42.

Рисунок 3.42

Файл журналу помилок ВК містить інформацію про тип помилки та час її виникнення під час роботи ПЗ ВК.
Файл журналу помилок ВК є масивом структур такого типу:

                struct {
                  char ; /* Тип помилки: 0 - помилка безперервного тестування SP */
                         /* 1 - немає лінії зв’язку з ЦЗ */
                  long ; /* Час виникнення помилки в секундах від */
                         /* 00:00:00 1 січня 1970 року (UTC) */
                };
            

3.4. Алгоритм роботи програмного забезпечення віддаленого концентратора

3.4.1. Тестова програма процесора синхронізації

Тестування та ініціалізація процесора синхронізації виконуються відповідно до наперед визначеної послідовності кроків:

1. тест регістрів мікропроцесора;
2. тест ПЗП;
3. тест ОЗП;
4. тест програмованого контролера переривань;
5. тест таймера;
6. тест мікросхеми 580ВВ51;
7. тест тайм-ауту;
8. налаштування векторів переривань;
9. налаштування маски переривань для програмованого контролера переривань;
10. тест блока NI599-03;
11. ініціалізація блоків NI599-08;
12. очікування підключення через канал RS232.

Усі наведені вище дії виконуються незалежно від будь-яких несправностей, що можуть виникнути. Хід тестування відображається за допомогою індикаторів на блоці NI599-31. Вимкнення будь-якого світлодіода, крім світлодіода «0», означає успішне завершення відповідного тесту. Вимкнення світлодіода «0» сигналізує про початок тестування. Його ввімкнення означає успішне завершення всієї процедури тестування.

Тестові та ініціалізаційні програми зберігаються в ПЗП блока NI599-31 у такій послідовності:

• тест блока NI599-31;
• завантажувач векторів переривань;
• тест блока NI599-03;
• драйвер IRPS;
• драйвер RS232;
• область контрольної суми.

Обсяг пам’яті, який займають ці програми, та їхні адресні розташування будуть визначені на стадії розроблення програмного забезпечення.

Після завершення тестування та ініціалізації в MCC дозволяються два апаратні переривання:

• IRQ1 — тайм-аут;
• IRQ2 — сигнал «приймач готовий» від каналу IRPS.

Доступ до драйвера IRPS і протоколи обміну описані в документі AFKE.40003-01-31-31.

3.4.2. Програма завантаження ПЗ SP з боку SP

Програма завантаження ПЗ SP, що виконується з боку SP, підтримує протокол обміну через інтерфейс C2, подібний до протоколу прозорого режиму BSC відповідно до GOST 28079-89. Вона призначена для завантаження програм і даних у резидентну та системну пам’ять пристрою NI526A через один із каналів блоків NI599-08, що працює в асинхронному режимі зі швидкістю 9600 біт/с.

Програма завантаження ПЗ SP з боку SP виконує такі функції:

• ініціалізація блоків NI599-08;
• приймання даних із лінії зв’язку до резидентної та системної пам’яті пристрою NI526A за заданою адресою;
• передавання даних із резидентної та системної пам’яті пристрою NI526A до лінії зв’язку з ПК за заданою адресою;
• видача команди переходу процесора за заданою адресою;
• перевірка правильності прийнятих даних;
• формування та надсилання лінією зв’язку повідомлень-підтверджень про правильність прийнятих даних.

Програма завантаження ПЗ SP з боку SP

Програма завантаження ПЗ SP, що виконується з боку SP, отримує керування після завершення тесту блока NI599-03.

Після отримання керування програма дає процесору змогу перевірити прапорець ініціалізації блоків NI599-08.

Якщо прапорець не встановлено, тобто він не дорівнює нулю, процесор ініціалізує блоки NI599-08, налаштовуючи їх на потрібний режим роботи. Після завершення ініціалізації процесор установлює прапорець ініціалізації в одиницю. Потім він починає послідовне опитування каналів NI599-08 для встановлення зв’язку через інтерфейс C2. Коли виявлено канал, який прийняв байт із лінії зв’язку, процесор переходить до відповідної підпрограми обробки лінії.

Підпрограма обробки лінії запускається тоді, коли процесор виявляє будь-який перший канал блока NI599-08, що прийняв байт із лінії зв’язку.

Вихід із підпрограми обробки лінії, а потім і з усієї програми завантаження ПЗ SP, відбувається лише після того, як процесор отримує текстове повідомлення з командою переходу за заданою адресою в керівному масиві. Після виходу з програми завантаження ПЗ SP процесор звільняє шину, даючи іншому процесору змогу взяти керування; процедура його завантаження виконується в тій самій послідовності.

Послідовність інформаційного обміну між ПК і SP, а також обробку відповідей SP показано на рисунку 3.43.

Рисунок 3.43

Під час приймання даних від ПК підпрограма обчислює BCS (Block Check Sequence). Обчислення починається після приймання байта STX і завершується байтом ETX включно. У послідовностях байтів на кшталт DLE, DLE і DLE, ETX, прийнятих усередині тексту повідомлення, перший байт DLE відкидається і не включається до обчислення BCS.

Якщо обчислена BCS не збігається з прийнятою, у лінію зв’язку надсилається відповідь виду NAK, "FF". Під час приймання повідомлення процесор завжди аналізує обов’язковий масив керівних байтів, розташований на початку тексту повідомлення. Залежно від коду операції він виконує одну з таких дій: приймання даних, передавання даних або перехід за заданою адресою. Структуру та розташування керівного масиву в тексті повідомлення показано на рисунку 3.44.

Рисунок 3.44

Програма завантаження ПЗ SP з боку SP використовує такі процедури:

1. ініціалізувати блоки NI599-08
2. скинути змінні (набір 1)
3. скинути змінні (набір 2)
4. передати байт даних у лінію зв’язку
5. прийняти байт даних із лінії зв’язку

Програма завантаження ПЗ з боку ПК

1 Скинути змінні 1
1 IF ПРАПОРЕЦЬ ІНІЦІАЛІЗАЦІЇ не встановлено
ІНІЦІАЛІЗУВАТИ блоки NI599-08
УСТАНОВИТИ ПРАПОРЕЦЬ ІНІЦІАЛІЗАЦІЇ

1 ELSE   /* якщо ПРАПОРЕЦЬ ІНІЦІАЛІЗАЦІЇ встановлено */
УСТАНОВИТИ ЛІЧИЛЬНИК КАНАЛІВ
ПРОЧИТАТИ СЛОВО СТАНУ КАНАЛУ

2 IF БІТ ГОТОВНОСТІ ПРИЙМАЧА ВСТАНОВЛЕНО
ПРИЙНЯТИ БАЙТ ДАНИХ ІЗ ЛІНІЇ ЗВ’ЯЗКУ

3 IF ЛІЧИЛЬНИК БУФЕРА A = 2
4 IF ПРАПОРЕЦЬ 2 не встановлено
5 IF ПРАПОРЕЦЬ 1 не встановлено
6 IF БУФЕР A = ENQ “FF”
ПЕРЕДАТИ в лінію зв’язку DLE “0” “FF”

7 IF ЛІЧИЛЬНИК БУФЕРА B < 7
Скинути змінні 2
7 ELSE   /* ЛІЧИЛЬНИК БУФЕРА B = 7 */

8 IF ПРАПОРЕЦЬ СТАРТУ в БУФЕРІ B встановлено
Скинути ЗМІННІ 1
Перейти за стартовою адресою
Звільнити шину

8 ELSE   /* ПРАПОРЕЦЬ СТАРТУ в БУФЕРІ B не встановлено */
9 IF ПРАПОРЕЦЬ ПЕРЕДАВАННЯ в БУФЕРІ B встановлено
Скопіювати перший і другий байт БУФЕРА B у ДОВЖИНУ ПЕРЕДАВАННЯ
10 IF ДОВЖИНА ПЕРЕДАВАННЯ ≠ 0
Передати байт даних у лінію зв’язку
Зменшити ДОВЖИНУ ПЕРЕДАВАННЯ
10 ELSE  /* ДОВЖИНА ПЕРЕДАВАННЯ = 0 */
Скинути змінні 2
10 END-IF
9 ELSE /* якщо ПРАПОРЕЦЬ ПЕРЕДАВАННЯ в БУФЕРІ B не встановлено */
Скинути змінні 2
9 END-IF
8 END-IF
7 END-IF
6 ELSE   /* БУФЕР A ≠ ENQ “FF” */

7 IF БУФЕР A = DLE STX
Скинути ЛІЧИЛЬНИК БУФЕРА A
Скинути ЛІЧИЛЬНИК БУФЕРА B
Скинути ПРАПОРЕЦЬ 1
7 ELSE   /* БУФЕР A ≠ DLE STX */
Скинути ЛІЧИЛЬНИК БУФЕРА A
7 END-IF
6 END-IF

5 ELSE   /* ПРАПОРЕЦЬ 1 встановлено */
6 IF БУФЕР A = DLE ETX
Скинути ПРАПОРЕЦЬ 1
Додати до BCC старший байт із БУФЕРА A
Скинути ЛІЧИЛЬНИК БУФЕРА A
Установити ПРАПОРЕЦЬ 2

6 ELSE   /* БУФЕР A ≠ DLE ETX */
7 IF БУФЕР A = DLE DLE
Скопіювати старший байт A → молодший байт
Зменшити ЛІЧИЛЬНИК БУФЕРА A
7 ELSE   /* БУФЕР A ≠ DLE DLE */
8 IF ЛІЧИЛЬНИК БУФЕРА B < 7
Додати до BCC молодший байт БУФЕРА A
Зменшити ЛІЧИЛЬНИК БУФЕРА A
Скопіювати молодший байт A → БУФЕР B
Збільшити ЛІЧИЛЬНИК БУФЕРА B
9 IF ЛІЧИЛЬНИК БУФЕРА B = 7
Установити ЗМІЩЕННЯ
Установити СЕГМЕНТ
9 END-IF
8 ELSE   /* IF ЛІЧИЛЬНИК БУФЕРА B = 7 */
Додати до BCC молодший байт БУФЕРА A
Зменшити ЛІЧИЛЬНИК БУФЕРА A
Молодший байт БУФЕРА A → пам’ять
Збільшити ЗМІЩЕННЯ
8 END-IF
7 END-IF
6 END-IF
5 END-IF

4 ELSE   /* ПРАПОРЕЦЬ 2 встановлено */
Скинути ПРАПОРЕЦЬ 2
5 IF БУФЕР A = BCC
Передати в лінію DLE “1” “FF”
5 ELSE   /* БУФЕР A ≠ BCC */
Передати в лінію NAK “FF”
Скинути змінні 2
5 END-IF
4 END-IF
3 END-IF

2 ELSE  /* ПРИЙМАЧ ГОТОВИЙ = 0 */
Зменшити ЛІЧИЛЬНИК КАНАЛІВ
3 IF ЛІЧИЛЬНИК КАНАЛІВ = 0
Установити ЛІЧИЛЬНИК КАНАЛІВ
Прочитати слово стану каналу
3 END-IF
2 END-IF
1 END-IF

Процедура: ініціалізувати блоки NI599-08

Установити ЛІЧИЛЬНИК БЛОКІВ
IF ЛІЧИЛЬНИК БЛОКІВ ≠ 0
Ініціалізувати таймери
Ініціалізувати канали
Зменшити ЛІЧИЛЬНИК БЛОКІВ
END-IF
    

Процедура: скинути змінні 1

Скинути ЛІЧИЛЬНИК БУФЕРА A
Скинути ЛІЧИЛЬНИК БУФЕРА B
Скинути ПРАПОРЕЦЬ 1
Скинути ПРАПОРЕЦЬ 2
Скинути КОНТРОЛЬНУ СУМУ
    

Процедура: скинути змінні 2

Скинути ЛІЧИЛЬНИК БУФЕРА A
Скинути ЛІЧИЛЬНИК БУФЕРА B
Скинути ПРАПОРЕЦЬ 1
Скинути КОНТРОЛЬНУ СУМУ
    

Процедура: передати байт даних у лінію зв’язку

Прочитати СЛОВО СТАНУ КАНАЛУ
IF біт ГОТОВНОСТІ ПЕРЕДАВАЧА встановлено
Записати байт даних до регістра даних каналу
END-IF
    

Процедура: прийняти байт даних із лінії зв’язку

Прочитати байт даних із регістра даних каналу
Скопіювати старший байт БУФЕРА A до молодшого байта
Скопіювати байт даних до старшого байта БУФЕРА A
Збільшити ЛІЧИЛЬНИК БУФЕРА A
    

3.4.3. Завантажувач ПЗ SP через з’єднувач C2 з боку комп’ютера
Завантажувач ПЗ SP призначений для завантаження програм і даних у резидентну та системну пам’ять NI-526A. Він виконується як частина командного файла, що запускається під час старту комп’ютера.

Завантажувач отримує на вході вказівку, які файли потрібно завантажити до SP. Його вихід складається з повідомлень, що містять дані для завантаження до SP, і керівних послідовностей (CS), які реалізують протокол обміну BSC. Завантажувач взаємодіє з термінальним драйвером tty і виконує такі дії:

1) Читає з диска комп’ютера файл сегментів, що містить інформацію про всі сегменти, які мають бути завантажені до SP. Структуру цього файла показано на рисунку 3.37 (див. розділ 3.3.6).

2) Для кожного сегмента завантажувач читає відповідний файл із диска, формує повідомлення для передавання до SP через інтерфейс RS232 за протоколом BSC. У цьому обміні використовуються спеціальні керівні символи (CC) і керівні послідовності з набору, визначеного GOST 19767–74. Формати та визначення цих символів і послідовностей докладно наведені в розділах 3.3.3.1 – 3.3.3.2. Структуру обміну описано раніше в розділі 3.4.2.

3) Перед надсиланням повідомлення завантажувач обчислює BCC за допомогою CRC з породжувальним поліномом X¹⁶ + X¹² + X⁵ + 1 (GOST 17422–72, див. розділ 3.3.3.4).

4) Повідомлення передається до SP. Після надсилання завантажувач очікує підтвердження від ПЗ SP. У разі успіху, коли прийнято DLE "1" або DLE "2", завантажувач переходить до наступного сегмента.
Якщо SP відповідає DLE "NO", сегмент передається повторно до трьох разів. Після трьох невдалих спроб на терміналі виводиться повідомлення про помилку.

5) Після успішного завантаження всіх сегментів завантажувач видає команду запуску ПЗ SP (сегмент 20). Структуру цієї команди показано на рисунку 3.40 (див. розділ 3.3.6). З цього моменту завантажене програмне забезпечення починає виконуватися в SP. Якщо фінальний сегмент відсутній, запуск не виконується.

6) Завантажувач забезпечує механізм перевірки цілісності завантаження шляхом читання пам’яті SP або візуального контролю результату. Для цього потрібно реалізувати програму читання пам’яті з боку SP і утиліту порівняння на робочій станції. Формат повідомлення запиту читання пам’яті показано на рисунку 3.41 (див. розділ 3.3.6).

У відповідь на запит завантажувач SP передає дані з пам’яті SP до файла на робочій станції. Цей файл може бути виведений на екран для ручного контролю або перевірений за допомогою утиліти порівняння. Результат показується на терміналі.

Під час запуску завантажувач надсилає в лінію зв’язку керівну послідовність DLE 0 і очікує відповідь від SP у вигляді керівної послідовності DLE 0. Якщо відповідь не отримано, запит повторюється кожні 3 секунди, до 5 спроб. Після цього на терміналі робочої станції виводиться повідомлення про помилку.
Формат повідомлення показано на рисунку 3.45.

Рисунок 3.45

Це триває доти, доки не буде отримано підтвердження з боку SP або доки оператор не втрутиться у відповідь на повідомлення про несправність.

Після встановлення з’єднання програма-завантажувач одразу починає запис даних і програм до процесора синхронізації. Вона відкриває файл сегментів і запускає процедуру завантаження. Для процесу завантаження передбачено два режими роботи: технологічний і основний. Режим роботи може бути вибраний і введений оператором комп’ютера у відповідь на запит виду, показаного на рисунку 3.46.

Рисунок 3.46

Схему ієрархії функцій програми завантаження показано на рисунку 3.47.

Рисунок 3.47

В основному режимі процедура завантаження читає з диска кожен сегмент, що підлягає завантаженню. Для цього, якщо сегмент не порожній, вона відкриває файл, ім’я якого записане в таблиці файла сегментів. Його вміст розміщується в буфері повідомлення (BC). Вона формує текст повідомлення і доповнює його керівними символами, передбаченими протоколом BSC, як показано на рисунку 3.48.

Рисунок 3.48

Якщо текст містить інформацію, що відповідає символу DLE, цей символ дублюється. Для забезпечення безпомилкового передавання даних під час процедури формування контрольної суми обчислюється BCC (Block Check Character).

Потім остаточне повідомлення передається термінальному драйверу для подальшого передавання через RS232 до SP. Після цього процедура завантаження очікує підтвердження від SP: керівний сигнал DLE 0 — для кожного парного переданого повідомлення, і DLE 1 — для кожного непарного переданого повідомлення. Якщо SP надсилає керівний сигнал "NO", несправний сегмент повторно передається до трьох разів. Після цього на терміналі виводиться повідомлення про помилку. Формат повідомлення показано на рисунку 3.49. Після отримання повідомлення оператор або ініціює повторне завантаження, або викликає персонал, відповідальний за виконання робіт з технічного обслуговування.

Рисунок 3.49

Якщо передавання виконано успішно, процедура завантаження переходить до читання наступного сегмента (див. вище). Після завантаження всіх сегментів у SP процедура завантаження надсилає до SP фінальний, 20-й сегмент. Цей сегмент містить команду запуску ПЗ SP. Структуру стартового повідомлення показано на рисунку 3.40 (див. розділ 3.3.6). На цьому завантаження одного SP завершується.

Робота в технологічному режимі дає змогу перевірити правильність завантаження шляхом читання пам’яті та візуального контролю. Для цього після завантаження в SP усіх сегментів, крім останнього (див. опис завантаження сегментів в основному режимі), оператору виводиться запит у такому форматі:

Рисунок 3.50

За замовчуванням буде виконано повну перевірку всіх сегментів. Наступний запит дає змогу вибрати тип перевірки:

Рисунок 3.51

Після цього програма читання, описана нижче, надсилає до SP запит читання. Структуру повідомлення запиту показано на рисунку 3.41 (див. розділ 3.3.6). У відповідь на цей запит програма-завантажувач, розташована в SP, забезпечує передавання даних із вибраного сегмента в пам’яті SP до файла перевірки на ПК.

Якщо оператор вибрав візуальну перевірку, вміст файла перевірки виводиться на екран. У разі другого типу перевірки викликається програма порівняння, яка порівнює вихідний файл із файлом перевірки. Оператор отримує повідомлення з результатом перевірки. Якщо результат негативний, повідомлення має такий формат:

Рисунок 3.52

Після цього оператору виводиться запит:

Рисунок 3.53

Якщо введено "yes", процедура перевірки повторюється. Якщо "no", оператору дозволяється завантажити SP в основному режимі.

Рисунок 3.54

Якщо так, виконується процедура завантаження. Якщо ні, програма завантажувача ПЗ SP завершує роботу.

Для роботи програма-завантажувач використовує таке:

Системний виклик:
ALARM – установити сигнал тривоги процесу;

Бібліотечні функції:
FOPEN – відкрити потік введення/виведення;
FDOPEN – пов’язати потік із файловим дескриптором, відкритим за допомогою FOPEN;
FCLOSE – закрити відкритий потік введення/виведення;
FREAD – прочитати задану кількість байтів із вхідного потоку;
FWRITE – записати задану кількість байтів у вихідний потік;
FGETC – прочитати наступний символ із вхідного потоку STREAM;
FPUTC – записати символ у потік;

Програми: порівняння, виведення файла на екран.

Прапорці:
Прапорець старту (SF) – установлюється після приймання DLE0 від SP у відповідь на початковий запит KTM.
Прапорець безпомилкового приймання (EFRF) – установлюється під час надсилання повідомлення-запиту, скидається після приймання повідомлення без помилок. Використовується програмою читання.
Repeat – використовується процедурою завантаження. Установлюється під час надсилання повідомлення до SP, скидається після отримання позитивної відповіді.

Буфери:
RO – вихідний буфер відповідей: буфер для надсилання відповідей до SP.
MT – буфер передавання повідомлень: буфер, що містить повідомлення, які мають бути надіслані до SP.
RI – вхідний буфер приймання: буфер для приймання даних від SP.

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

Програма завантаження ПЗ до SP через інтерфейс C2 з боку ПК

Лічильник відповідей (RC) установлено в 0
Прапорець старту (SF) скинуто

LOOP  /* доки немає відповіді */
IF SF скинуто
ELSE
Запустити 3-секундний таймер
END-IF

IF лічильник відповідей менший за 5
ELSE
Вивести попередження на екран ПК
Скинути лічильник
END-IF

Надіслати запит ENQ у лінію
Перейти в режим приймання підтвердження
Збільшити лічильник відповідей на 1
Установити прапорець старту   /* SF = 1 */

END-LOOP

/* Коли прийнято DLE 0 – з’єднання встановлено */

Відкрити файл сегментів
Виконати процедуру завантаження
Надіслати запит оператору на термінал
IF потрібно завантажити другий процесор
Виконати процедуру завантаження
ELSE
END-IF

Закрити файл сегментів
    

Процедура завантаження

A := 3
Запитати оператора   /* у якому режимі працювати */
Присвоїти відповідь змінній A
Прочитати перший рядок таблиці сегментів

WHILE номер сектора (SN) ≠ 20
Repeat := 1
Лічильник повторів (RC) := 0
IF сегмент не порожній THEN
Відкрити файл
Сформувати повідомлення в MT
Сформувати BCC
WHILE Repeat > 0
Надіслати повідомлення з MT до термінального драйвера
Перейти в режим приймання підтвердження від SP
SELECT: відповідь від SP
CASE DLE 0 і DLE 1
RC := 0
CASE NO
RC := RC + 1
IF RC = 3 THEN
Вивести повідомлення на екран ПК
END-IF
END-WHILE
END-IF
Прочитати наступний рядок таблиці
END-WHILE

IF A = 1 THEN
Виконати процедуру обробки технологічного режиму
ELSE
Прочитати сегмент 20
Сформувати повідомлення в MT
Сформувати BCC
Repeat := 1
WHILE Repeat > 0
Надіслати повідомлення з MT до термінального драйвера
Перейти в режим приймання підтвердження від SP
SELECT: відповідь від SP
CASE DLE 0 і DLE 1
RC := 0
CASE NO
RC := RC + 1
IF RC = 3 THEN
Вивести повідомлення на екран ПК
END-IF
END-WHILE
END-IF
    

Процедура обробки технологічного режиму

Відкрити файл перевірки
Запитати оператора   /* який тип контролю */
IF повний контроль THEN
Прочитати перший рядок таблиці сегментів
Лічильник сегментів (SC) := 0
WHILE SC < 20
IF сегмент не порожній THEN
Виконати програму читання пам’яті
ELSE
END-IF
SC := SC + 1
END-WHILE
ELSE
Прочитати N-й рядок таблиці
Виконати процедуру читання пам’яті
END-IF

Запитати оператора   /* який тип контролю */
SELECT відповідь оператора
CASE visual
Виконати програму виведення файла на екран
CASE using comparison program
Виконати програму порівняння
Вивести результат на екран
CASE none of the above
Виконати програму виведення файла на екран
END-SELECT
    

Процедура читання пам’яті

Записати до буфера повідомлення:
1. DLE STX
2. Довжина сегмента в байтах
3. Зміщення області SP
4. Сегмент області SP
5. Прапорець читання
6. ETX

Обчислити BCC і записати її до буфера повідомлення

Передати повідомлення з буфера повідомлення до процесора синхронізації (SP)

Перейти в режим приймання від SP

Прапорець приймання без помилки := 1

WHILE Прапорець приймання без помилки = 1
Прийняти повідомлення до буфера приймання
Обчислити BCC прийнятого повідомлення
IF повідомлення було прийнято з помилкою THEN
Надіслати NAK до SP за допомогою буфера відповідей
ELSE
Записати повідомлення з буфера приймання до файла приймання
Прапорець приймання без помилки := 0
Надіслати позитивне підтвердження за допомогою буфера відповідей
END-IF
END-WHILE
       

3.4.4. Програма ініціалізації адаптера

Програма ініціалізації адаптера працює всередині SP. Вона викликається завантажувачем ПЗ SP з боку SP. Основна функція програми ініціалізації адаптера полягає у встановленні режимів роботи адаптерів відповідно до таблиці конфігурації процесора (див. таблиці 2 і 3). Програма послідовно обробляє всю таблицю, читає адреси мікросхем, визначає номер блока й тип адаптера та відповідно ініціалізує їх (спочатку блок, потім мікросхему). Щоб уникнути повторної ініціалізації блока, рекомендується використовувати регістр ініціалізованих блоків (RIB). Структуру RIB показано на рисунку 3.60.

Рисунок 3.60

Схему ієрархії функцій програми ініціалізації адаптера показано на рисунку 3.61.

Блок NI526 містить модулі NI599-06 і NI599-08, призначені для спряження C1 і C2 з VIMK. Модуль NI599-06 наразі перебуває в розробленні. Підпрограму ініціалізації NI599-06 буде розроблено після отримання технічної документації на цей модуль.

Кожен модуль NI599-08 містить:

• два таймери, реалізовані на мікросхемі 580ВИ53;
• чотири універсальні синхронно-асинхронні приймачі-передавачі (USART), реалізовані на мікросхемі 580ВВ51.

Адреса модуля задається перемичками на друкованій платі.

Ініціалізація модуля виконується шляхом запису керівного слова модуля (MCW) до відповідного регістра. Формат керівного слова модуля показано на рисунку 3.62.

Рисунок 3.61

Рисунок 3.62

Програмований таймер реалізований як три незалежні 16-бітові канали зі спільною схемою керування. Програмування режимів роботи каналів виконується індивідуально шляхом запису керівних слів (CW) до регістрів режимів каналів і констант лічильників до лічильників. Константа задається залежно від швидкості приймання або передавання даних відповідно до таблиці 3. Формат керівного слова таймера показано на рисунку 3.63.

Рисунок 3.63

USART (універсальний синхронно-асинхронний приймач-передавач) працює у двох режимах: синхронному й асинхронному. Програмування мікросхеми для будь-якого з цих режимів виконується записом у відповідні регістри: регістр інструкції режиму, регістр символу синхронізації (для синхронного режиму) та регістр командної інструкції. Формат інструкцій режиму для синхронної та асинхронної роботи показано на рисунку 3.64. Формат командної інструкції показано в таблиці 4. Адреси портів введення/виведення та налаштовані режими роботи модуля NI599-06 наведені в таблиці 5.

Таблиця 4

Формат командної інструкції

Таблиця 5

Адреси портів введення/виведення модуля NI599-08

XX — групова адреса модуля

Рисунок 3.64

ПРОГРАМА ІНІЦІАЛІЗАЦІЇ АДАПТЕРА

Виконується підпрограма ініціалізації блока
Номер каналу CN := 1

LOOP-WHILE CN менший або дорівнює загальній кількості каналів
У таблиці конфігурації процесора за адресою =
= адреса таблиці + (CN - 1) * 66H + 28H взяти адресу мікросхеми (2 байти)
У таблиці конфігурації процесора за адресою =
= адреса таблиці + (CN - 1) * 66H + 48H взяти тип адаптера (4 біти)
IF тип адаптера = 0010B   /* адаптер типу C2 */
Виконати підпрограму ініціалізації для з’єднувача C2
ELSE виконати підпрограму ініціалізації для з’єднувача C1
END-IF
CN := CN + 1
END-LOOP
    

ПІДПРОГРАМА ІНІЦІАЛІЗАЦІЇ БЛОКА

Номер каналу CN := 1

LOOP-WHILE CN ≤ загальна кількість каналів
У таблиці конфігурації процесора за адресою =
= адреса таблиці + (CN - 1) * 66H + 28H взяти адресу мікросхеми (2 байти)
Очистити молодший байт адреси мікросхеми   /* визначити власну адресу блока */

IF у регістрі ініціалізованих блоків (RIB),
біт, що відповідає каналу CN, НЕ встановлено в 0
У таблиці конфігурації процесора за адресою =
= адреса таблиці + (CN - 1) * 66H + 48H взяти тип адаптера (4 біти)
IF тип адаптера = 0010B   /* адаптер типу C2 */
виконати процедуру ініціалізації блока NI599-08
ELSE   /* адаптер типу C1 */
виконати процедуру ініціалізації блока NI599-06
END-IF
END-IF

CN := CN + 1
Установити біт CN у RIB в 1

END-LOOP
    

ПРОЦЕДУРА ІНІЦІАЛІЗАЦІЇ БЛОКА NI599-08

Номер каналу CN := 1
WHILE CN ≤ загальна кількість каналів
У таблиці конфігурації процесора за адресою =
адреса таблиці + (CN - 1) * 68H + 28H
отримати адресу мікросхеми (довжиною 2 байти)

У таблиці конфігурації процесора за адресою =
адреса таблиці + (CN - 1) * 68H + 4CH
отримати режим роботи адаптера (довжиною 2 байти)

IF режим роботи = 00   /* синхронний */
Визначити номер блока BN1 за адресою мікросхеми

IF BN = BN1   /* той самий блок */
Вибрати молодший байт адреси мікросхеми
CASE 12H:
BCW := BCW 00000010B   /* BCW - Block Control Word */
CASE 1AH:
BCW := BCW 00000100B
CASE 22H:
BCW := BCW 00001000B
CASE 2AH:
BCW := BCW 00010000B
END CASE
END IF
END IF

CN := CN + 1
END WHILE

Записати керівне слово BCW до блока, використовуючи його власну адресу та номер BN
    

ПІДПРОГРАМА ІНІЦІАЛІЗАЦІЇ ДЛЯ З’ЄДНУВАЧА C2 (ІНТЕРФЕЙС RS-232)

Очистити молодший байт адреси мікросхеми   /* визначити власну адресу
 блока */
Виконується перша процедура ініціалізації таймера.
Виконується перша процедура ініціалізації мікросхеми.
    

ПЕРША ПРОЦЕДУРА ІНІЦІАЛІЗАЦІЇ ТАЙМЕРА

З таблиці конфігурації процесора за адресою = адреса таблиці + (CN-1)*68H + 20H  
отримати константу лічильника (1 байт);  
SELECT молодший байт адреси мікросхеми  
CASE 12H  
CCW := 00101111  /* Counter Control Word */  
Надіслати CCW за адресою = базова адреса модуля + 000EH  
Надіслати молодший байт константи лічильника за адресою =  
базова адреса модуля + 0008H  

CASE 1AH  
CCW := 01001111  
Надіслати CCW за адресою = базова адреса модуля + 0006H  
Надіслати молодший байт константи лічильника за адресою =  
базова адреса модуля + 0002H  

CASE 22H  
CCW := 10101111  
Надіслати CCW за адресою = базова адреса модуля + 0006H  
Надіслати молодший байт константи лічильника за адресою =  
базова адреса модуля + 0004H  

CASE 2AH  
CCW := 00101111  
Надіслати CCW за адресою = базова адреса модуля + 0006H  
Надіслати молодший байт константи лічильника за адресою =  
базова адреса модуля  

END SELECT
    

ПЕРША ПІДПРОГРАМА ІНІЦІАЛІЗАЦІЇ МІКРОСХЕМИ

У таблиці конфігурації процесора за адресою = адреса таблиці + (CN-1)*68H +
4CH отримати дані про режим роботи мікросхеми (синхронний, асинхронний)
довжиною два біти;
IF режим роботи = 00B   /* синхронний */
Виконати процедуру налаштування мікросхеми КР580ВВ51А на синхронний
режим роботи;
ELSE   /* асинхронний */
Виконати процедуру налаштування мікросхеми КР580ВВ51А на синхронний
режим роботи;
END-IF

ПЕРША ПРОЦЕДУРА ІНІЦІАЛІЗАЦІЇ МІКРОСХЕМИ КР580ВВ51А ДЛЯ СИНХРОННОГО РЕЖИМУ

Інструкція режиму (MI) := 00010000B  
/*тип синхронізації — внутрішній, контроль увімкнено (парність парна або непарна)*/

З ТАБЛИЦІ КОНФІГУРАЦІЇ ПРОЦЕСОРА отримати дані про кількість символів синхронізації  
за адресою = адреса таблиці + (CH–1)*68H + 52H, довжиною 2 байти,  
тип контролю за адресою = адреса таблиці + (CH–1)*68H + 50H, довжиною 2 байти,  
довжину байта за адресою = адреса таблиці + (CH–1)*68H + 4EH, довжиною 2 байти

IF довжина байта = 11B   /* 8 → D2 = 1 і D3 = 1 */  
MI := MI + 00001100B  
END-IF

IF тип контролю = 11B   /* контроль парності */  
MI := MI + 00100000B  
END-IF

IF кількість символів синхронізації = 01B   /* один символ синхронізації */  
MI := MI + 10000000B

Надіслати інструкцію режиму (MI) за адресою мікросхеми
З ТАБЛИЦІ КОНФІГУРАЦІЇ ПРОЦЕСОРА за адресою =
адреса таблиці + (CH–1)*68H + 58H отримати перший символ синхронізації, 
 довжиною 1 байт
Надіслати символ синхронізації за адресою мікросхеми
Надіслати командну інструкцію (CI) := 10110111B за адресою мікросхеми

ELSE   /* два символи синхронізації */
Надіслати інструкцію режиму (MI) за адресою мікросхеми
З ТАБЛИЦІ КОНФІГУРАЦІЇ ПРОЦЕСОРА за адресою =
адреса таблиці + (CH–1)*68H + 58H отримати перший символ синхронізації, 
 довжиною 1 байт
Надіслати перший символ синхронізації за адресою мікросхеми
З ТАБЛИЦІ КОНФІГУРАЦІЇ ПРОЦЕСОРА за адресою =
адреса таблиці + (CH–1)*68H + 60H отримати другий символ синхронізації, 
 довжиною 1 байт
Надіслати другий символ синхронізації за адресою мікросхеми
END-IF

Надіслати командну інструкцію (CI) := 10110111B за адресою мікросхеми
    

ПІДПРОГРАМА НАЛАШТУВАННЯ МІКРОСХЕМИ KP580VV51A ДЛЯ АСИНХРОННОГО РЕЖИМУ

Інструкція режиму (MI) := 00010000B /* контроль парності увімкнено, 
                                       режим роботи 1:16 */

З ТАБЛИЦІ КОНФІГУРАЦІЇ ПРОЦЕСОРА отримати:
довжину стоп-біта  
за адресою = адреса таблиці + (CN–1)*68H + 56H, довжиною 2 біти
тип контролю  
за адресою = адреса таблиці + (CN–1)*68H + 50H, довжиною 2 біти
довжину байта  
за адресою = адреса таблиці + (CN–1)*68H + 4EH, довжиною 2 біти

IF довжина стоп-біта = 11B   /* два стоп-біти */  
MI := MI + 11000000B  
END-IF

IF тип контролю = 11B   /* контроль парності */  
MI := MI + 00100000B  
END-IF

IF довжина байта = 11B   /* 8 бітів → D2 = 1 і D3 = 1 */  
MI := MI + 00001100B  
END-IF

Надіслати інструкцію режиму (MI) за адресою мікросхеми  
Надіслати командну інструкцію (CI) := 10110111B за адресою мікросхеми
    

3.4.5. Програма введення даних для конфігурації ВК

Програма призначена для створення та модифікації файла конфігурації віддаленого концентратора (ВК). У файлі зберігаються номери ліній мультиплексора та типи ВП. Структуру файла див. у розділі 3.3.7.

Схему ієрархії функцій програми введення даних для конфігурації ВК показано на рисунку 3.73.

Рисунок 3.73

Програма введення даних конфігурації в псевдокоді показана на рисунку 3.74.

Відкрити файл
IF файл не існує
Створити файл
Відкрити файл
END-IF
Вивести вміст файла на екран
IF потрібно ввести нові дані або змінити наявні
WHILE надходять запити
Ввести номер лінії мультиплексора
IF такий номер існує
Ввести новий тип ВП
END-IF
Ввести значення типу ВП
END-WHILE
END-IF
Закрити файл
    

3.4.6. Програма формування таблиць конфігурації процесора

Програма призначена для створення та модифікації таблиці конфігурації процесора, яка потім завантажується в SP. Програма отримує вхідні дані, введені з клавіатури у відповідь на запити.

Вихідними даними є файл.

Структура файла наведена в розділі 3.3.7.

Схему ієрархії функцій програми конфігурування зовнішніх зв’язків SP показано на рисунку 3.75.

Рисунок 3.75

Програма формування таблиць конфігурації процесора на рисунку 3.76.

Програма формування таблиць конфігурації процесора в псевдокоді показана на рисунку 3.76.

Відкрити файл
IF файл не існує
Створити файл
Відкрити файл
END-IF

Вивести вміст файла на екран

IF потрібно змінити таблицю
IF потрібно заповнити новий рядок у таблиці
WHILE є запити на введення
Ввести номер каналу
WHILE кількість колонок у таблиці <= кількість введених значень
Ввести решту даних, розділяючи їх натисканням клавіші "Enter"
END-WHILE
END-WHILE
END-IF

IF потрібно змінити окремі дані в будь-якому рядку
Вказати номер каналу
Внести зміни в потрібній колонці
END-IF
END-IF

Закрити файл
    

3.4.7. Програма формування файла сегмента ініціалізації векторів переривань

Програма призначена для створення та модифікації файла сегмента ініціалізації векторів переривань. У файлі зберігаються номери нових векторів переривань і адреси програм обробки переривань, а також виконується прив’язка нових адрес обробників до наявних кодів векторів переривань.

Вхідними даними програми є номери векторів переривань і адреси програм обробки переривань, що вводяться з клавіатури ПК. Вихідним результатом є файл сегмента ініціалізації векторів переривань, призначений для завантаження в SP.

Структура файла наведена в розділі 3.3.7.

Схему ієрархії програми формування файла сегмента ініціалізації векторів переривань показано на рисунку 3.77.

Рисунок 3.77

Програма формування файла сегмента ініціалізації векторів переривань у псевдокоді показана на рисунку 3.78.

Відкрити файл
IF файл не існує
Створити файл
Відкрити файл
END-IF

Вивести вміст файла на екран

IF потрібно ввести нові дані та змінити наявні дані
WHILE надходять запити на введення
Ввести номер вектора
IF такий номер існує
IF потрібно продовжити
Ввести нове значення адреси обробника переривання
END-IF
END-IF
Ввести значення адреси обробника переривання
END-WHILE
END-IF

Закрити файл
    

3.4.8. Програма формування файла сегментів завантаження SP

Програма готує файл сегментів завантаження SP, який потім використовується програмою завантаження. Програма завантаження завантажує дані до процесора синхронізації (SP), використовуючи інформацію, збережену у файлі сегментів. Структуру файла див. у п. 3.3.7. Кожен рядок файла сегментів містить інформацію про сегмент даних, який має бути завантажений до SP. Ця інформація вводиться під час діалогу програми з оператором. Вихідними даними програми є файл сегментів завантаження SP.

Ієрархію функцій програми формування файла сегментів завантаження SP показано на рисунку 3.79.

Рисунок 3.79

Програма формування файла сегментів завантаження SP у псевдокоді показана на рисунку 3.80.

Відкрити файл
IF файл не існує
                Створити файл
                Відкрити файл
END-IF

Вивести вміст файла на екран

IF потрібно змінити таблицю
Порахувати кількість рядків у таблиці N
WHILE надходять запити
Ввести ім’я сегмента
Обчислити довжину сегмента
IF ім’я сегмента вже існує
Очистити значення в колонці довжини сегмента поточного рядка
Ввести нове значення довжини сегмента
END-IF
Записати значення довжини сегмента в таблицю DS(N)
Визначити новий номер сегмента N++
Записати N у колонку номера сегмента поточного рядка
END-WHILE

IF планування адрес пам’яті автоматичне
Призначити адресу AD(1) = 1000 сегменту з номером N(1)
WHILE номер рядка N(N) <= кількість рядків у таблиці N
Призначити адресу сегменту N(N), обчислену як сума 
довжини сегмента DS(N–1) і відповідної адреси AD(N–1)
 попереднього рядка таблиці
END-WHILE
END-IF

Ввести значення адрес у порядку спадання номерів сегментів,
розділяючи їх клавішею "Enter"
END-IF

Закрити файл
    

3.4.9. Програма безперервного тестування SP з боку ПК

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

Програма виконує такі функції:

1. Надіслати байт у канал.
2. Прийняти байт із каналу.
3. Порівняти два байти. Якщо вони збігаються, програма продовжує роботу; інакше вона записує помилку до файла журналу.

Байт надсилається періодично, приблизно кожні 10–60 секунд.

Програма безперервного тестування використовує системні виклики:

1. ALARM – установити сигнал тривоги для процесу;
2. SIGNAL – задати дії для оброблення сигналу;

Використовуються такі бібліотечні функції:

1. FOPEN – відкрити потік;
2. FREAD, FWRITE – двійкове введення/виведення;
3. FSEEK – установити позицію потоку;
4. PRINTF – форматований вивід;
5. GETCHAR – прочитати символ або слово з потоку.

Схему ієрархії функцій програми безперервного тестування з боку ПК показано на рисунку 3.81.

Рисунок 3.81

Програма безперервного тестування в псевдокоді показана на рисунку 3.82.

Відкрити файл зовнішнього пристрою
Відкрити файл журналу помилок

WHILE надходить сигнал переривання від таймера
Установити часовий інтервал надсилання байта
Записати байт до файла зовнішнього пристрою
Прочитати байт із файла зовнішнього пристрою
Порівняти надісланий і прийнятий байти
IF байти не рівні
Отримати час виникнення помилки
Записати цей час до файла журналу помилок
END-IF
END-WHILE
    

3.4.10. Програма безперервного тестування SP з боку процесора 1

Програма безперервного тестування з боку процесора 1 призначена для контролю роботи мультиплексора типу MULTISERIAL і SP. Програма працює разом із програмами безперервного тестування SP з боку процесора 2 і ПК. Тестові дані надсилаються до SP і приймаються від SP програмою безперервного тестування з боку ПК. Коли байт даних прийнято з лінії зв’язку, програма записує його до буфера за допомогою стандартної процедури запису до буфера, розташованої в області спільної пам’яті.

Схему функціональної ієрархії показано на рисунку 3.83.

Рисунок 3.83

Програма безперервного тестування SP з боку процесора 1 — див. рисунок 3.84.

ПРОЧИТАТИ байт даних із мікросхеми
ЗАПИСАТИ байт до буфера
    

3.4.11. Програма безперервного тестування SP з боку процесора 2

Програма працює в SP. Програма безперервного тестування з боку процесора 2 призначена для контролю роботи мультиплексора MULTISERIAL і SP. Програма працює разом із програмами безперервного тестування SP з боку процесора 1 і ПК.

Схему ієрархії показано на рисунку 3.85.

Рисунок 3.85

Програма безперервного тестування SP з боку процесора 2, див. рисунок 3.86.

ПРОЧИТАТИ байт із буфера
ПЕРЕДАТИ байт даних
    

Процедура: прочитати байт із буфера на рисунку 3.87.

Завантажити до регістра BX значення: номер каналу * 100 – 100 [+50]
IF BOX[BX + 3] > 0
Взяти значення з комірки BOX[BX + 2] і завантажити його до SI
Прочитати байт інформації за адресою BOX[BX + SI]
Збільшити BOX[BX + 1] на 1

IF BOX[BX + 3] = 1
Очистити молодший байт у BOX[BX]
END-IF

Зменшити BOX[BX + 3] на 1
END-IF
    

3.4.12. Програма ідентифікації переривання процесором 1

Програма працює в SP. Вона починає роботу після передавання керування за апаратним перериванням для приймання інформації з лінії зв’язку. Після отримання керування вона опитує регістр команд/стану (CSR) задіяних адаптерів і, виявивши канал, через який надійшла інформація, формує програмне переривання для програми обслуговування цього каналу.

Адреси CSR обчислюються через зміщення відносно адрес задіяних мікросхем. Адреси мікросхем кожного каналу зберігаються в таблиці конфігурації процесора. У таблиці конфігурації невикористані поля адрес адаптерів містять нульове значення, що дає змогу відрізняти поля з інформацією від порожніх полів.

Схему ієрархії функцій показано на рисунку 3.88.

Рисунок 3.88

Програма ідентифікації переривання процесором 1 показана на рисунку 3.89.

Отримати адресу мікросхеми
Модифікувати адресу адаптера до адреси CSR
За адресою CSR перевірити прапорець наявності даних
IF дані наявні
Отримати тип переривання для приймання 
             з таблиці конфігурації процесора 1
Виконати програмне переривання
END-IF
    

3.4.13. Програма ідентифікації переривання для процесора 2

Програма ідентифікації переривання для процесора 2 є аналогічною програмі ідентифікації переривання для процесора 1.

3.4.14. Драйвер приймання даних від ВС «Вега»

Драйвер приймання даних від «Веги» працює в SP. Він призначений для приймання байтів даних із синхронної лінії зв’язку між ВК і ВС «Вега». Драйвер приймає дані у двох режимах: прозорому та непрозорому. У прозорому режимі вилучається непарний символ DLE, а також символи заповнення DLE і SYN. У непрозорому режимі вилучаються символи заповнення SYN.

Схему ієрархії драйвера показано на рисунку 3.90.

Рисунок 3.90

Драйвер приймання даних від «Веги» показано на рисунку 3.91.

прочитати байт даних із лінії;
якщо біт прозорого режиму встановлено
    працювати в прозорому режимі;
інакше
    працювати в непрозорому режимі;
end-if
    

Процедура роботи в прозорому режимі, див. рисунок 3.92.

IF біт DLE скинуто
IF байт даних є DLE THEN
Установити біт DLE;
ELSE
Записати байт до буфера;
ENDIF
ELSE   /* тобто якщо біт DLE встановлено */
IF байт даних є одним із ETX, ETB, US, ENQ THEN
Скинути біт прозорого режиму;
Записати DLE до буфера;
Записати байт до буфера;
Скинути біт DLE;
ENDIF
IF байт даних є SYN THEN
Скинути біт DLE;
ENDIF
IF байт даних є DLE THEN
Записати DLE до буфера;
Записати байт до буфера;   /* другий DLE */
Скинути біт DLE;
ENDIF
ENDIF
    

Процедура роботи в непрозорому режимі, див. рисунок 3.93.

IF біт DLE встановлено THEN
IF байт даних є STX THEN
Записати DLE до буфера;
Записати STX до буфера;
Установити біт прозорого режиму;
ELSE
Записати DLE до буфера;
Записати байт до буфера;
ENDIF
ELSE   /* біт DLE не встановлено */
IF байт даних є SYN THEN
Нічого не передавати;
ENDIF
ENDIF
    

Процедура запису байта до буфера, рисунок 3.94.

/* BOX — мітка початку області поштових скриньок */

Завантажити до регістра BX значення: номер каналу * 100 – 100 [+50]
IF BOX[BX + 3] > 0 THEN
Отримати значення з комірки BOX[BX + 2] і передати до SI
Записати байт даних за адресою BOX[BX + SI]
Збільшити BOX[BX + 2] на 1
Збільшити BOX[BX + 3] на 1
Установити біт наявності даних у байті стану
END-IF
    

3.4.15. Драйвер приймання даних від ВС «Кама»

Драйвер приймання даних від системи «Кама-А» (далі — «Кама») призначений для приймання інформації від ВС «Кама», присвоєння даним номера підканалу та запису інформації до поштової скриньки (MB).

Розроблення цієї програми базується на таких особливостях і домовленостях:

• максимальна швидкість приймання даних від «Ками» становить 200 бод;
• кількість інформаційних бітів у байті від «Ками» дорівнює 5;
• дані, що надходять до SP з кількох телеграфних ліній, мультиплексуються і передаються до ПК однією лінією з’єднувача C2;
• передавання до ПК виконується 8-бітовими передаваннями, з яких три біти використовуються для ідентифікації номера телеграфного каналу;
• читання з лінії та запис до буфера виконуються за допомогою стандартних процедур.

Схему ієрархії драйвера показано на рисунку 3.95.

Рисунок 3.95

Драйвер приймання даних від «Ками», рисунок 3.96.

Прочитати байт даних із мікросхеми
Прочитати номер підканалу
Позначити байт даних
Записати байт до буфера
    

3.4.16. Драйвер приймання даних від ПК до ВС «Вега»

Драйвер приймання даних від ПК до «Веги» працює в SP. Драйвер приймає байти даних відповідно до протоколу взаємодії з «Вегою» (див. розділ 3.3.3). Драйвер записує байти даних до буфера та встановлює прапорці, що дає програмі передавання даних до «Веги» змогу відстежувати безперервні послідовності символів (GOST 28079–89).

Схему ієрархії драйвера показано на рисунку 3.97.

Рисунок 3.97

Драйвер приймання даних від ПК до «Веги», рисунок 3.98.

Прочитати байт даних із лінії зв’язку до ПК

IF біт очікування BCC встановлено
Виконати модуль очікування BCC
ELSE
IF біт DLE скинуто
IF байт даних є DLE
Записати до комірки 4 з комірки 2
Установити біт заборони передавання
Записати байт до буфера
Установити біт DLE
ELSE  /* запис текстового (інформаційного) байта */
Записати байт до буфера
Записати до комірки 4 з комірки 2
END-IF
ELSE  /* тобто якщо біт DLE встановлено */
SELECT байт даних
CASE DLE:
Записати байт до буфера
Записати до комірки 4 з комірки 2
Скинути біт заборони передавання
Скинути біт DLE
CASE ETX або ETB або US:
Записати байт до буфера
Скинути біт DLE
Скинути біт прозорого режиму
Установити біт очікування BCC
CASE STX:
Скинути біт заборони передавання
Записати байт до буфера
Записати до комірки 4 з комірки 2
Скинути біт DLE
Установити біт прозорого режиму
DEFAULT:
Скинути біт заборони передавання
Записати байт до буфера
Записати до комірки 4 з комірки 2
Скинути біт DLE
END-SELECT
END-IF
END-IF
    

Модуль очікування BCC, рисунок 3.99.

IF біт 1-го байта BCC встановлено THEN
Записати байт до буфера
Скопіювати вміст комірки 2 до комірки 4
Скинути біт заборони передавання
Скинути біт DLE
Скинути біт очікування BCC
Скинути біт 1-го байта BCC
ELSE
Записати байт до буфера
Установити біт 1-го байта BCC
END-IF
    

Байт стану в секції поштової скриньки під час проходження інформації від ПК до «Веги» показано на рисунку 3.100. Цифри позначають біти байта стану.

Рисунок 3.100

3.4.17. Програми сканування поштових скриньок

Програма перевіряє наявність даних у поштовій скриньці, переданих від одного SP до іншого, і передає ці дані програмі обробки.

Програма має перевіряти біт наявності інформації в байті стану, розташованому в 50-байтовій секції поштової скриньки. Коли біт наявності встановлено, програма сканування звертається до таблиці конфігурації процесора і виконує програмне переривання для програми передавання даних.

Програму сканування поштової скриньки в псевдокоді показано на рисунку 3.101.

WHILE канал існує в таблиці процесора
Знайти адресу другої 50-байтової секції поштової скриньки
Перевірити біт наявності інформації
IF біт установлено THEN
За номером каналу знайти адресу мікросхеми
За адресою мікросхеми знайти регістр команд/стану (CSR)
Перевірити готовність до передавання
IF готовий THEN
Визначити тип переривання для передавання
Виконати програмне переривання
END-IF
END-IF
END WHILE
    

Програма сканування інформації в процесорі синхронізації процесором 2 відрізняється від програми сканування інформації процесором 1 тим, що сканується перша 50-байтова секція кожної поштової скриньки, задіяної в обміні даними.

3.4.18. Програма передавання даних до ВС «Вега» від ПК

Програма передавання інформації від ПК до «Веги» виконує передавання відповідно до протоколу обміну з «Вегою». Програма працює в інтерфейсному процесорі (IP). Вона передає байти даних із поштової скриньки (MB) до вимірювальної системи (ВС). Програма отримує керування через програмне переривання від програми сканування MB. Алгоритм дає змогу безперервно передавати послідовності DLE ETB, (DLE ETX, DLE US), BCC і DLE DLE, що запобігає вставлянню символів заповнення в ці послідовності. Схему ієрархії програми показано на рисунку 3.102.

Рисунок 3.102

Прочитати байт із комірки 4 поштової скриньки
Прочитати байт із комірки 1 поштової скриньки

IF байт із комірки 4 ≠ байт із комірки 1
Передати
END-IF

IF байт із комірки 4 = байт із комірки 1
IF біт блокування передавання скинуто
Передати
END-IF
END-IF
    

У програмі передавання даних до «Веги» від ПК використовується процедура «Передавання» — див. рисунок 3.104.

Процедура: Передавання

Прочитати байт із буфера
IF біт DLE встановлено THEN
IF байт даних є STX THEN
Передати байт даних
Увімкнути прозорий режим
Скинути біт DLE
END-IF
IF байт даних є ETX або ETB або US THEN
Передати байт даних
Вимкнути прозорий режим
Скинути біт DLE
END-IF
ELSE
Передати байт даних
END-IF
    

3.4.19. Програма передавання даних до ПК від ВС «Вега»

Програма передавання даних до ПК від ВС «Вега» працює в SP. Програма отримує керування від програми сканування поштової скриньки через програмне переривання. Коли для зберігання інформації в MB для всіх каналів, незалежно від типу й характеру інформації, використовується кільцевий буфер, застосовуються уніфіковані операції читання та запису до буфера. Схему функціональної ієрархії програми передавання даних до ПК від «Веги» показано на рисунку 3.105.

Рисунок 3.105

Прочитати байт із буфера
Передати байт даних
    

3.4.20. Програма передавання даних від ВС «Кама» до ПК

Програма передавання інформації від «Ками» до ПК працює в процесорі синхронізації (SP). У разі використання кільцевого буфера для зберігання інформації в поштовій скриньці (MB) для всіх каналів, незалежно від типу й характеру інформації, застосовується уніфіковане читання та запис до буфера. Схему функціональної ієрархії програми передавання інформації від «Ками» до ПК показано на рисунку 3.107.

Рисунок 3.107

Програма передавання інформації до ПК від «Веги» Рисунок 3.106

3.4.21. Програма-диспетчер

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

Вхідними даними для програми-диспетчера є інформація, що міститься у файлі «КОНФІГУРАЦІЯ ВП».

Результатом роботи програми-диспетчера є набір паралельних процесів для приймання, зберігання та передавання інформації від ВС до центру обробки даних (ЦОД), див. рисунок 3.109.

Рисунок 3.109

Програма-диспетчер запускає програму читання файла «КОНФІГУРАЦІЯ ВП». У результаті виконання програми читання файла заповнюється масив «КОНФІГУРАЦІЯ ВП». Програма-диспетчер послідовно переглядає всі елементи масиву «КОНФІГУРАЦІЯ ВП» і, залежно від каналу, пов’язаного з ВС, запускає відповідний процес.

Програма-диспетчер використовує такі програми:

• читання файла «КОНФІГУРАЦІЯ ВП»;
• транспорт від ВС «Вега»;
• транспорт від ВС «Кама».

Склад і кількість використовуваних програм можуть змінюватися.
Програма-диспетчер у псевдокоді: рисунок 3.110.

Прочитати файл «КОНФІГУРАЦІЯ ВП» до масиву «КОНФІГУРАЦІЯ ВП»

LOOP — ДЛЯ кожного елемента масиву «КОНФІГУРАЦІЯ ВП»
SELECT ТИП ВС
CASE 0: Ніяких дій
CASE 1: Передавання від ВС «Вега»
CASE 2: Передавання від ВС «Кама»
END SELECT
END LOOP
    

Програма читання файла «КОНФІГУРАЦІЯ ВП» використовує системні виклики:

• відкрити файл;
• прочитати файл;
• закрити файл.

Програма читання файла «КОНФІГУРАЦІЯ ВП» у псевдокоді: рисунок 3.111.

Відкрити файл «КОНФІГУРАЦІЯ ВП»
Прочитати файл «КОНФІГУРАЦІЯ ВП» до масиву «КОНФІГУРАЦІЯ ВП»
Закрити файл «КОНФІГУРАЦІЯ ВП»
    

Транспортна програма від ВС «Вега» організовує приймання інформації від ВС «Вега», підтримання відповідного протоколу зв’язку, оброблення інформації з визначенням її типу — дані в реальному масштабі часу (RTS) або дані відтворення, зберігання інформації у файловій системі ВК і передавання інформації до ЦОД. Ці функції виконують програми:

• приймання повідомлень від ВС «Вега»;
• оброблення повідомлень від ВС «Вега».

Це незалежні процеси, породжені транспортною програмою від ВС «Вега». Транспортна програма від ВС «Вега» керує взаємодією між породженими процесами за допомогою програмного каналу, через який відбувається обмін даними.

Транспортна програма від ВС «Вега» використовує системний виклик:

• створити канал;

і програми:

• приймання повідомлень від ВС «Вега»;
• оброблення повідомлень від ВС «Вега».

Рисунок 3.112

Рисунок 3.112

Транспортну програму від ВС «Вега» в псевдокоді показано на рисунку 3.113.

Створити канал  
Приймати повідомлення від ВС «Вега»  
Обробляти повідомлення від ВС «Вега»
    

Транспортна програма від ВС «Кама» організовує приймання інформації, що надходить від ВС «Кама» в симплексному режимі, зберігання інформації у файловій системі ВК і передавання інформації до ЦОД. Такі функції виконуються програмами:

• приймання повідомлень від ВС «Кама»;
• оброблення повідомлень від ВС «Кама».

Це незалежні процеси, породжені транспортною програмою від ВС «Кама». Транспортна програма від ВС «Кама» керує взаємодією породжених процесів через програмний канал, який використовується для обміну даними. Рисунок 3.114

Рисунок 3.114

Транспортна програма від ВС «Кама» використовує системний виклик:

• створити канал;

і програми:

• приймання повідомлень від ВС «Кама»;
• оброблення повідомлень від ВС «Кама».

Транспортну програму від ВС «Кама» в псевдокоді показано на рисунку 3.115.

Створити канал;
Приймати повідомлення від ВС «Кама»;
Обробляти повідомлення від ВС «Кама»;
    

3.4.21.1. Програма приймання повідомлень від ВС «Вега»

Програма призначена для приймання повідомлень від ВС «Вега» і передавання їх до каналу зв’язку.

На вході програма отримує повідомлення, керівні послідовності (CS) і керівні символи (CC), що надходять від SP. На виході — повні повідомлення, які передаються до програми оброблення повідомлень, а також керівні послідовності, що пересилаються до SP.

Програма виконує такі дії:

1. Підтримує протокол зв’язку BSC. Керування обміном здійснюється за допомогою спеціальних керівних символів і послідовностей керівних символів, вибраних із дозволеного набору відповідно до GOST 19767-74.

Основні процедури обміну описані в розділі 3.3.3.3.
Структуру інформаційного повідомлення, прийнятого з лінії зв’язку SP, показано на рисунку 3.116.

Структура інформаційного повідомлення

Рисунок 3.116

2. Приймає повідомлення від ВС «Вега». Вилучає керівні символи (CC), керівні послідовності (CS) і додаткові символи (DLE) та передає повідомлення до програми оброблення.
3. Обчислює блокову контрольну послідовність прийнятого блока і за допомогою програми порівняння перевіряє правильність прийнятої інформації.
   Залежно від результатів порівняння видає позитивне або негативне підтвердження для прийнятого повідомлення.
4. Аналізує готовність програми оброблення прийняти повідомлення і, залежно від рівня готовності, формує відповідь. Аналіз готовності виконується модулями перевірки готовності та переповнення.

Ієрархію функцій програми приймання повідомлень показано на рисунку 3.117.

Рисунок 3.117

Після запуску програма приймання переходить у режим контролю лінії. Перед початком передавання повідомлення передавальна станція за допомогою ENQ (Enquiry) запитує приймальну станцію, тобто ВК, про готовність до роботи — встановлення логічного з’єднання. Після приймання ENQ програма приймання виконує процедуру перевірки готовності (описану нижче) і, якщо приймач готовий, формує DLE 0; інакше — NAK (Negative Acknowledge). Після видачі NAK програма повертається в режим контролю лінії.

Для керування ходом виконання програми використовуються такі прапорці:

• End of Transmission Flag (ETF) — установлюється після надходження DLE STX і характеризує стан приймання/передавання; скидається після приймання або надсилання EOT, що означає стан контролю лінії.

• Format Error Flag (FEF) — установлюється, коли виявлено помилку в порядку керівних послідовностей і керівних символів або в структурі інформаційного повідомлення під час передавання. Установлення FEF переводить програму в режим контролю лінії. FEF скидається після приймання ENQ.

• DLE0 Flag — відповідає за видачу DLE 0 для кожного правильно прийнятого парного блока і DLE 1 для кожного правильно прийнятого непарного блока. Установлюється після приймання DLE 0 і скидається після приймання DLE 1.

• DLE1 Flag — установлюється після приймання першого DLE і скидається після приймання керівних символів ENQ, ETB, ETX або DLE, що безпосередньо йдуть після першого DLE 1.

Після приймання запиту на з’єднання від передавальної станції та видачі позитивного підтвердження програма готова приймати дані. End of Transmission Flag (ETF) скидається. Відповідно до протоколу обміну BSC, основні процедури якого описані в розділі 3.3.3, дозволено приймання таких керівних послідовностей і керівних символів: EOT, ENQ, STX ENQ, DLE STX. Якщо прийнято інші керівні послідовності або символи, установлюється Format Error Flag (FEF). Програма переходить у режим контролю лінії. Для зберігання та оброблення вхідних даних програма використовує кілька буферів. Буфер A використовується для читання байтів із лінії зв’язку. Блоковий буфер (BB) зберігає прийняті байти, що належать одному блоку. Буфер повідомлення (MB) накопичує текст повідомлення для подальшого передавання до каналу. Контрольний буфер (CB) використовується програмою перевірки. Він містить усі символи, що підлягають перевірці. Псевдокод програми наведено нижче.

Програму приймання повідомлень від інформаційної системи «Вега» в псевдокоді показано на рисунку 3.118.

Режим роботи = YES  
Скинути End of Transmission Flag (ETF)   /* ETF = 0 */

WHILE режим роботи
Виконати процедуру читання байта до буфера A
Скинути лічильник байтів (BC);   /* BC = 0 */
SELECT вміст A:

CASE ENQ        /* хто там? (enquiry) */
Виконати обробник керівної послідовності ENQ

CASE STX ENQ    /* затримка на боці передавача */
Виконати обробник керівної послідовності STX ENQ

CASE EOT        /* кінець передавання */
Виконати обробник керівної послідовності EOT

CASE DLE STX    /* початок тексту */
Виконати обробник керівного символу DLE STX

CASE none of the above
Установити Format Error Flag (FEF)
/* FEF = 1 */

END SELECT
END WHILE
    

Процедуру оброблення керівної послідовності ENQ у псевдокоді показано на рисунку 3.119.

IF End of Transmission Flag (ETF) скинуто THEN   /* тобто ETF = 0 */
Виконати перевірку готовності приймача
IF приймач готовий THEN
Надіслати DLE 0
Записати DLE 0 до вихідного буфера відповідей (RO)
Установити DLE0 Flag       /* DLE0 Flag = 1 */
Установити End of Transmission Flag (ETF)   /* ETF = 1 */
ELSE   /* не готовий */
Надіслати NAK
ENDIF

ELSE   /* ETF = 1 */
Виконати перевірку готовності приймача
IF приймач готовий THEN
Виконати процедуру контролю переповнення
IF виявлено переповнення THEN
Надіслати DLE
ELSE
Надіслати повідомлення з RO
ENDIF
ELSE   /* не готовий */
Надіслати EOT
Скинути End of Transmission Flag (ETF)   /* ETF = 0 */
ENDIF
ENDIF
    

Після приймання керівної послідовності ENQ, якщо End of Transmission Flag (ETF) скинуто, тобто програма перебуває в режимі контролю лінії, виконується перевірка готовності приймача. Якщо відповідь позитивна, DLE 0 надсилається в лінію зв’язку і записується до вихідного буфера відповідей (RO). Після цього встановлюються DLE0 Flag і ETF. Якщо перевірка готовності показує, що приймач не готовий, програма формує керівну послідовність NAK.

Керівний символ ENQ може також надходити в режимі приймання-передавання. У цьому разі виконується процедура перевірки готовності. Якщо система не готова, формується керівний символ EOT (End Of Transmission), який сигналізує про завершення з’єднання, End Of Transmission Flag (ETF) скидається, і програма переходить у режим контролю лінії. Якщо система готова, виконується процедура контролю переповнення (див. нижче). Якщо виникає переповнення, формується керівний символ DLE (Data Link Escape); інакше з буфера відповідей виводиться повідомлення.

Процедуру в псевдокоді для оброблення керівного символу STX ENQ показано на рисунку 3.120.

IF ETF (End Of Transmission Flag) встановлено   /* ETF = 1 */
ВИДАТИ NAK   /* Negative Acknowledge */
ELSE   /* ETF = 0 */
/* відповіді немає */
УСТАНОВИТИ Format Error Flag (FEF = 0)
END IF
    

Інформаційна система «Вега» надсилає керівний символ ENQ замість чергового блока даних, щоб повідомити про тимчасову неготовність до передавання. Після приймання керівного символу ENQ у режимі приймання-передавання процедура приймання видає NAK і очікує продовження передавання. Якщо керівний символ ENQ надходить у режимі контролю лінії, установлюється Format Error Flag (FEF). Відповідь не видається.

Процедуру в псевдокоді для оброблення керівного символу EOT показано на рисунку 3.121.

IF ETF (End Of Transmission Flag) встановлено   /* ETF = 1 */
Скинути прапорець ETF       /* ETF = 0 */
Надіслати повідомлення про кінець передавання на термінал
ELSE   /* ETF = 0 */
/* відповіді немає */
Установити Format Error Flag       /* FEF = 0 */
END IF
    

Інформаційна система «Вега» сигналізує програмі — надсилаючи керівний символ EOT — або про завершення передавання, або про призупинення передавання. Процедура приймання обробляє символ EOT, надсилаючи повідомлення про кінець передавання на термінал. End Of Transmission Flag (ETF) скидається, після чого програма переходить у режим контролю лінії.

Процедуру в псевдокоді для оброблення керівного символу DLE STX показано на рисунку 3.122.

СКИНУТИ DLE1 Flag        /* DLE1 Flag = 0 */
IF ETF (End Of Transmission Flag) скинуто   /* ETF = 0 */
УСТАНОВИТИ Format Error Flag     /* FEF = 0 */
ELSE   /* ETF = 1 */
ВИКОНАТИ процедуру «прочитати байт до буфера A»
WHILE (A ≠ ETB AND A ≠ ETX AND A ≠ ENQ AND DLE1 Flag ≠ 1)
WHILE (A ≠ DLE1)
ЗАПИСАТИ A до блокового буфера (BB)
ЗАПИСАТИ A до контрольного буфера (CB)
ВИКОНАТИ процедуру Control1
ВИКОНАТИ процедуру «прочитати байт до буфера A»
END WHILE
ВИКОНАТИ процедуру «прочитати байт до буфера A»
IF A = DLE1 THEN
ЗАПИСАТИ A до байтового буфера
ЗАПИСАТИ A до контрольного буфера (CB)
ВИКОНАТИ процедуру Control1
ELSE
СКИНУТИ DLE1 Flag     /* DLE1 Flag = 0 */
END IF
END WHILE

CASE A OF
ENQ     /* ігнорувати блок даних */
ВИДАТИ NAK
ETB     /* кінець блока */
ВИКОНАТИ процедуру «обробити ETB»
ETX     /* кінець тексту */
ВИКОНАТИ процедуру «обробити ETX»
OTHERWISE
УСТАНОВИТИ Format Error Flag
СКИНУТИ DLE1 Flag     /* DLE1 Flag = 0 */
END CASE
END IF
    

ВС «Вега», надсилаючи керівний символ EOT, сигналізує програмі або про кінець передавання, або про призупинення передавання. Процедура приймання обробляє символ EOT, надсилаючи на термінал повідомлення про кінець передавання. End Of Transmission Flag (ETF) скидається, після чого програма переходить у режим контролю лінії.

Процедуру в псевдокоді для оброблення керівного символу ETB показано на рисунку 3.123.

СКИНУТИ DLE1 Flag         /* DLE1 Flag = 0 */
ЗАПИСАТИ ETB до контрольного буфера (CB)     /* ETB = End Of Transmission Block */
ВИКОНАТИ процедуру Control1
ВИКОНАТИ процедуру «перевірити готовність приймача»
IF приймач готовий THEN
ВИКОНАТИ процедуру Control2
IF результат = 0 THEN
ПЕРЕДАТИ блоковий буфер (BB) до буфера повідомлення (MB)
ВИКОНАТИ процедуру «перевірити переповнення»
IF переповнення немає THEN
IF DLE0 Flag = 1 THEN
ВИДАТИ DLE1      /* надіслати керівний символ DLE1 */
УСТАНОВИТИ DLE0 Flag = 0
ЗАПИСАТИ DLE1 до вихідного буфера (OB)
ELSE   /* DLE0 Flag = 0 */
ВИДАТИ DLE0      /* надіслати керівний символ DLE0 */
УСТАНОВИТИ DLE0 Flag = 1
ЗАПИСАТИ DLE0 до вихідного буфера (OB)
END IF
ELSE   /* є переповнення */
ВИДАТИ DLE1
IF DLE0 Flag = 1 THEN
УСТАНОВИТИ DLE0 Flag = 0
ЗАПИСАТИ DLE1 до вихідного буфера (OB)
ELSE   /* DLE0 Flag = 0 */
УСТАНОВИТИ DLE0 Flag = 1
ЗАПИСАТИ DLE0 до вихідного буфера (OB)
END IF
END IF
ELSE   /* повідомлення прийнято з помилкою */
ЗАПИСАТИ NAK до вихідного буфера (OB)
ВИДАТИ NAK      /* надіслати Negative Acknowledge */
END IF
ELSE   /* приймач не готовий */
ВИДАТИ EOT       /* надіслати End Of Transmission */
СКИНУТИ ETF Flag       /* ETF = 0 */
END IF
    

Процедуру в псевдокоді для оброблення керівного символу ETX показано на рисунку 3.124.

СКИНУТИ DLE1 Flag          /* DLE1 Flag = 0 */
ЗАПИСАТИ ETX до контрольного буфера (CB)     /* ETX = End Of Text */
ВИКОНАТИ процедуру Control1
ВИКОНАТИ процедуру «перевірити готовність приймача»
IF приймач готовий THEN
ВИКОНАТИ процедуру Control2
IF результат = 0 THEN
ПЕРЕДАТИ блоковий буфер (BB) до буфера повідомлення (MB)
ПЕРЕДАТИ буфер повідомлення (MB) до каналу
ВИКОНАТИ процедуру «перевірити переповнення»
IF переповнення немає THEN
IF DLE0 Flag = 1 THEN
ВИДАТИ DLE1       /* надіслати керівний символ DLE1 */
УСТАНОВИТИ DLE0 Flag = 0
ЗАПИСАТИ DLE1 до вихідного буфера (OB)
ELSE   /* DLE0 Flag = 0 */
ВИДАТИ DLE0       /* надіслати керівний символ DLE0 */
УСТАНОВИТИ DLE0 Flag = 1
ЗАПИСАТИ DLE0 до вихідного буфера (OB)
END IF
ELSE   /* є переповнення */
ВИДАТИ DLE1
IF DLE0 Flag = 1 THEN
УСТАНОВИТИ DLE0 Flag = 0
ЗАПИСАТИ DLE1 до вихідного буфера (OB)
ELSE   /* DLE0 Flag = 0 */
УСТАНОВИТИ DLE0 Flag = 1
ЗАПИСАТИ DLE0 до вихідного буфера (OB)
END IF
END IF
ELSE   /* повідомлення прийнято з помилкою */
ЗАПИСАТИ NAK до вихідного буфера (OB)
ВИДАТИ NAK       /* надіслати Negative Acknowledge */
END IF
ELSE   /* приймач не готовий */
ВИДАТИ EOT       /* надіслати End Of Transmission */
СКИНУТИ ETF Flag       /* ETF = 0 */
END IF
    

Керівний символ STX (Start Of Text) надсилається передавальною станцією на початку тексту даних користувача. Якщо текст поділено на блоки, STX надсилається на початку кожного блока. Кожен наступний байт даних, прочитаний із лінії зв’язку, одночасно записується до блокового буфера та контрольного буфера. Якщо два керівні символи DLE (Data Link Escape) прийнято поспіль, один із них відкидається. Запис триває до приймання керівної послідовності DLE ETB, DLE ETX або DLE ENQ.

Якщо повідомлення, що передається, поділено на блоки, передавальна станція сигналізує про кінець блока даних керівним символом ETB, а потім надсилає керівний символ BCC. Після приймання керівного символу DLE ETB процедура приймання припиняє запис до блокового буфера, записує символ ETB до контрольного буфера, а потім викликає процедуру контролю для перевірки цілісності прийнятого буфера. Якщо інформацію прийнято без помилок, вона видає керівний символ DLE0 або DLE1 — залежно від DLE0 Flag — і передає блок із блокового буфера до буфера повідомлення.

Керівний символ ETX означає кінець інформаційного повідомлення. Якщо повідомлення поділено на блоки, ETX позначає кінець останнього блока замість ETB. Після приймання керівного символу DLE ETX процедура приймання — після виконання всіх дій, які виконуються при DLE ETB, — передає зібране повідомлення з буфера повідомлення до каналу зв’язку.

Надсилаючи керівний символ ENQ у кінці блока даних замість ETX або ETB, ВС «Вега» вказує, що цей блок слід відкинути. У відповідь на цей керівний символ процедура приймання видає NAK.

Якщо прийнято керівний символ або послідовність, не оброблені вище, установлюється Format Error Flag. Після цього програма переходить у режим контролю лінії.

Для підтримки процедури приймання необхідно розробити такі програми:

• процедуру перевірки готовності приймача;
• процедуру контролю інформації;
• процедуру читання байта з лінії зв’язку до буфера A;
• процедуру контролю переповнення.

Процедура приймання використовує такі системні виклики:

ALARM – установити сигнал тривоги процесу.

Процедура перевірки готовності приймача контролює наявність повідомлення про несправність. Якщо таке повідомлення є, вона повертає 1; інакше повертає 0. Готовність перевіряється кожного разу, коли процедура приймання має сформувати відповідь за протоколом BSC. Якщо несправність виникає під час сеансу зв’язку, процедура видає керівний символ EOT; якщо вона виникає під час початкового опитування, процедура видає керівний символ NAK.

Процедура контролю призначена для обчислення блокового контрольного символу прийнятого інформаційного блока (BCC1). Вона викликається для кожного символу, прийнятого від ВС «Вега», який підлягає перевірці. Під час формування BCC використовується циклічний код із породжувальним поліномом x**16 + x**12 + x**5 + 1 (GOST 17422-72).

Обчислення BCC1 починається після приймання керівної послідовності DLE STX. Ці керівні послідовності на початку блока не повинні включатися до обчислення BCC1. У процесі обчислення BCC1 включаються всі символи, передані після послідовності DLE STX, крім першого символу DLE у керівних послідовностях DLE ETB, DLE ETX і DLE DLE.

Обчислення BCC1 виконується за схемою, показаною на рисунку 3.125.

Рисунок 3.125

BCC1 обчислюється шляхом виконання таких кроків:

1. Очистити LFSR.
2. Зберегти значення біта 15 LFSR у V.
3. Зсунути вміст LFSR на один біт праворуч.
4. Записати в щойно звільнений біт 0 LFSR значення останнього біта контрольного буфера (CB), а потім зсунути контрольний буфер на один біт праворуч.

5. Проаналізувати значення біта 15 LFSR, збережене у V. Якщо воно дорівнює 1, додати 1 за модулем 2 до бітів 0, 5 і 12 LFSR. Якщо V дорівнює 0, дія не потрібна.

Повторювати кроки 2–5, доки всі інформаційні біти з контрольного буфера (CB) не будуть послідовно введені до LFSR.

Процедура Control2 призначена для перевірки правильності передавання інформаційного блока шляхом порівняння BCC1, обчисленого процедурою Control1, з BCC, сформованим ВС «Вега». Control2 викликається процедурою приймання кожного разу, коли на лінію зв’язку має бути надіслано підтвердження приймання блока. Блок вважається прийнятим без помилок, якщо контрольні послідовності збігаються, і помилковим, якщо вони не збігаються.

Програма читання байта читає байт інформації з лінії зв’язку і розміщує його в буфері A. Якщо передавання інформації від передавальної станції припиняється, вона видає повідомлення на термінал про припинення передавання і переходить у режим контролю лінії. Текст програми наведено нижче на рисунку 3.126.

IF Format Error Flag установлено   /* FEF = 1 */
Запустити таймер на n секунд і скинути FEF   /* FEF = 0 */
ELSE
Запустити таймер на n секунд
END IF

WHILE таймер не завершив роботу
Прочитати байт до буфера A
IF буфер A містить дані THEN
RETURN
END IF
END WHILE

ВИДАТИ повідомлення на термінал про припинення передавання  
ПЕРЕЙТИ в режим контролю лінії
    

Після обчислення BCC1 прочитати 2 байти з лінії зв’язку до BCC2. Порівняти його вміст із LFSR. Якщо вони рівні, повернути 0 до процедури приймання; якщо ні — повернути 1.

Псевдокод процедури Control1 показано на рисунку 3.127(a), а процедури Control2 — на рисунку 3.127(b).

C = 8      // C – кількість бітів у контрольному буфері
WHILE C > 0
ЗБЕРЕГТИ значення біта 15 LFSR у V
ЗСУНУТИ LFSR на один біт праворуч
ЗАПИСАТИ до біта 0 LFSR значення біта C контрольного буфера (CB)
ЗМЕНШИТИ C на 1
IF V = 1 THEN
ДОДАТИ 1 за модулем 2 до бітів 0, 5 і 12 LFSR
END IF
END WHILE
    

Прочитати 2 байти до BCC2;   /* BCC2 — буфер, що містить прийнятий BCC1 */
IF BCC2 = LFSR THEN
RETURN 0    /* помилки немає */
ELSE
RETURN 1    /* повідомлення прийнято з помилкою */
END IF
ОЧИСТИТИ LFSR
    

Процедура перевірки переповнення виконується кожного разу, коли на лінію зв’язку має бути надіслано позитивне підтвердження. Вона перевіряє, чи може процедура приймання вчасно завершити оброблення повідомлення. Якщо може, вона повертає 0; якщо ні — повертає 1.

3.4.21.2. Програма оброблення повідомлень від ВС «Вега»

Програма оброблення повідомлень для вимірювальної системи «Вега» визначає тип вхідної інформації — дані в реальному масштабі часу або дані відтворення, зберігає прийняту інформацію у файловій системі ВК і передає її програмам, відповідальним за доставлення мережею до центру збору.

Вхідними даними для програми оброблення повідомлень «Веги» є повідомлення, прийняті через програмний канал від процедури приймання «Веги».

Вихідними даними програми оброблення повідомлень «Веги» є повідомлення, що надсилаються мережею з використанням таких примітивів:

openpath(), sendviapath(), closepath()

Ці примітиви будуть надані Науково-технічним центром космодрому Плесецьк.

Схему необхідних функцій показано на рисунку 3.128.

Структура повідомлень системи «Вега», а також типи повідомлень описані в розділі 3.3.1.

Рекомендації щодо іменування файлів зберігання інформації від вимірювальної системи наведені в розділі 3.3.7.

Рисунок 3.128

Програму оброблення повідомлень для вимірювальної системи «Вега» в псевдокоді показано на рисунку 3.129.

ПРОЧИТАТИ «програмний канал»
IF information_type = real-time data THEN
SELECT information_index
CASE initial_message
ВІДКРИТИ файл
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
CASE final_message
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
ЗАКРИТИ файл
CASE message
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
CASE empty_message
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
END SELECT
ELSE
SELECT information_index
CASE initial_message
ВІДКРИТИ файл
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
CASE final_message
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
ЗАКРИТИ файл
CASE message
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
END SELECT
END IF
    

3.4.21.3. Програма приймання повідомлень від ВС «Кама»

Програма приймання повідомлень для вимірювальної системи «Кама» читає інформаційні байти з процесного каналу, надіслані ВС «Кама», сортує вхідні байти для кожної ВС «Кама» до власного буфера і пакує прийняті байти в безперервний бітовий потік, що утворює інформаційне повідомлення ВС «Кама».

Вхід: послідовність байтів, що надходить із процесного каналу.

Вихід: безперервна послідовність бітів, що формує повідомлення і передається до програмного каналу для процедури оброблення повідомлень «Ками».

Псевдокод програми приймання повідомлень «Ками» показано на рисунку 3.130.

ПРОЧИТАТИ байт із каналу  
ВИДІЛИТИ три старші біти  
ms_info := значення цих трьох старших бітів // інформація від вимірювальної системи

CASE ms_info OF
0: виділити повідомлення для системи 0
…
N: виділити повідомлення для системи N
END CASE
    

Програму «Виділити повідомлення» в псевдокоді показано на рисунку 3.131.

IF byte_value = marker_value THEN
IF marker_flag = TRUE THEN
ЗАПИСАТИ повідомлення до каналу
bit_count := 0
ELSE
bit_count := записати байт до буфера пакування
marker_flag := TRUE
END IF
ELSE
IF marker_flag = TRUE THEN
bit_count := записати байт до буфера пакування
END IF
END IF
    

Структуру програми приймання повідомлень для вимірювальної системи «Кама» показано на рисунку 3.132.

Рисунок 3.132

Процедура запису байта до буфера пакування записує п’ять молодших бітів кожного байта, прийнятого від вимірювальної системи «Кама», до буфера без проміжків, формуючи безперервний потік інформаційних бітів.

Вхідними даними для програми запису байта до буфера з пакуванням є: 1) кількість байтів, записаних до буфера, 2) байт інформації від ВС і 3) адреса буфера.

Кількість бітів, записаних до буфера.

У описі програми в псевдокоді використовуються такі скорочення:

• BBA: адреса байта буфера
• BMS: байт від вимірювальної системи
• NBB: кількість бітів у байті
• NBW: кількість бітів, записаних у байті ВС
• NUB: кількість незаписаних бітів у байті ВС
• NMB: кількість бітів повідомлення
• NOB: кількість зайнятих бітів у байті буфера

Програму «Записати байт до буфера з пакуванням» у псевдокоді показано на рисунку 3.133.

/* Алгоритм пакування телеграфних пакетів до буфера              */
/* BMS — вхідний байт від вимірювальної системи                  */

#define TELEGRAPH_PACKET_SIZE 5 /* Розмір телеграфного пакета в бітах
                                 (від адаптера) */
#define NBB 8                   /* Кількість бітів в одному байті буфера       */

BBA := NMB / NBB               /* Адреса байта буфера = int(NMB / NBB)         */
NOB := NMB % NBB               /* Зайняті біти в поточному байті буфера        */
NBW := NMB % NBB               /* Біти, записані в байті ВС (те саме, що NOB)  */
BMS := BMS << NBW              /* Вирівняти нові біти з вмістом буфера         */
*BBA := *BBA | BMS             /* Об’єднати BMS з байтом буфера за адресою BBA */
NUB := TELEGRAPH_PACKET_SIZE - NBW  /* Решта бітів BMS, ще не збережених                    */

IF NUB <= 0 THEN
    NMB := NMB + TELEGRAPH_PACKET_SIZE  /* Усі 5 бітів записано в один байт   */
ELSE
    NBW := TELEGRAPH_PACKET_SIZE - NUB  /* Біти, записані в поточний байт     */
    NMB := NMB + NBW            /* Оновити загальну кількість записаних бітів */
    BBA := NMB / NBB            /* Нова адреса буфера                         */
    BMS := BMS >> NUB           /* Отримати решту бітів                       */
    *BBA := *BBA | BMS          /* Об’єднати решту з наступним байтом буфера  */
    NMB := NMB + NUB            /* Знову оновити загальну кількість бітів     */
END IF

3.4.21.4. Програма оброблення повідомлень від ВС «Кама»

Програма оброблення повідомлень для ВС «Кама» зберігає вхідну інформацію у файловій системі ВК і передає її до ЦЗ (центру збору).

Вхідними даними для програми оброблення повідомлень ВС «Кама» є повідомлення, що надходять програмним каналом від процедури приймання повідомлень ВС «Кама».

Вихідними даними програми оброблення повідомлень ВС «Кама» є повідомлення, надіслані мережею з використанням мережевих примітивів, і ті самі повідомлення, збережені у файловій системі ВК.

Програма оброблення повідомлень ВС «Кама» організовує передавання вхідної інформації до мережі з використанням примітивів

openpath(), sendviapath(), closepath(),

які будуть надані НТЦ космодрому Плесецьк (Науково-технічним центром).

Псевдокод програми оброблення повідомлень ВС «Кама» показано на рисунку 3.134.

Структуру програми оброблення повідомлень ВС «Кама» показано на рисунку 3.135.

ПРОЧИТАТИ «програмний канал»
SELECT measuring_system_number
CASE 0
ВІДКРИТИ файл
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
ЗАКРИТИ файл
...
CASE 4
ВІДКРИТИ файл
ЗАПИСАТИ повідомлення до файла
НАДІСЛАТИ повідомлення мережею
ЗАКРИТИ файл
...
END SELECT
    

Рисунок 3.135

3.4.22. Програма приймання та розподілу мережевої інформації

Програма приймання та розподілу мережевої інформації приймає й маршрутизує командну інформацію від ЦЗ до кожної ВС на кожному ВП, зберігаючи її у файловій системі ВК. Крім того, вона може приймати з мережі командну інформацію для програми-диспетчера, щоб запустити потрібний прикладний процес.

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

Вихідними даними програми приймання та розподілу є повідомлення, надіслані конкретним ВС і збережені у файловій системі ВК.

Псевдокод програми приймання та розподілу показано на рисунку 3.136.

ПРИЙНЯТИ повідомлення з мережі
SELECT MS_type
CASE 0
ЗАПИСАТИ до файла
НАДІСЛАТИ повідомлення до ВС
CASE 1
ЗАПИСАТИ до файла
НАДІСЛАТИ повідомлення до ВС
...
CASE N   // N ≤ 7
ЗАПИСАТИ до файла
НАДІСЛАТИ повідомлення до ВС
END SELECT
    

Ця програма взаємодіє з мережевим ПЗ ВК через командний примітив «receive», який, як і інші примітиви, надається НТЦ космодрому Плесецьк.

Рисунок 3.137

3.4.23. Драйвер приймання даних у SP від центральної лінії

Драйвер приймання інформації в SP з лінії зв’язку з центром працює всередині SP. Він призначений для забезпечення приймання інформації з лінії зв’язку з центром і її запису до PY для подальшого передавання через ПК. Драйвер використовує операцію біт-стафінгу з видаленням нуля.

Необхідність біт-стафінгу полягає в такому. За відсутності даних для передавання мережею інтерфейсний процесор лінії на передавальному кінці видає безперервну послідовність символів заповнення виду 01111110. Повідомлення з даними, які самі можуть містити символ заповнення, вставляються в цю послідовність. Щоб відрізнити інформаційний символ від символу заповнення в потоці даних, передавач вставляє нуль після будь-якої послідовності з п’яти одиниць поспіль.

На приймальному кінці лінії вхідний потік даних безперервно контролюється на наявність п’яти одиниць поспіль: якщо після п’яти одиниць іде «0», він відкидається; якщо іде шоста «1», це означає прийнятий символ заповнення.

Схему ієрархії функцій драйвера показано на рисунку 3.138.

Рисунок 3.138

Псевдокод драйвера приймання інформації до процесора узгодження (SP) з лінії зв’язку з центром показано на рисунку 3.139.

; Драйвер приймання інформації
; Цей алгоритм обробляє вхідний потік даних, виконує видалення біт-стафінгу
; і записує результат до буфера
; Перевірки CRC/прапорців кадру виконуються в ПЗ ПК,
; цей код обробляє лише побайтове приймання та видалення біт-стафінгу.

; Блок: ініціалізація буфера та лічильників
output_buffer := empty         ; Буфер для збереження оброблених байтів
C := array of zeros [0..15]    ; Масив лічильників:
                               ;   C[R4] — лічильник оброблених бітів у R4
                               ;   C[R3] — лічильник послідовних одиниць у R3
output_bit_buffer := 0         ; Бітовий буфер для накопичення оброблених бітів
output_bit_count  := 0         ; Кількість бітів в output_bit_buffer
R1 := 0     ; Регістр для читання байта даних, операцій біт-стафінгу
R2 := 0     ; Регістр для передавання байта до буфера, містить залишок із R1
R3 := 0     ; Кількість бітів, установлених у 1 після 0 (від LSB до MSB)
R4 := 0     ; Регістр для решти бітів, ще не переданих до буфера
R5 := 0     ; Значення попереднього залишку
R6 := 0     ; Допоміжний регістр
R7 := 0     ; Лічильник оброблених бітів

; Блок: основний цикл оброблення потоку даних
WHILE дані доступні на лінії зв’язку
; Блок: читання даних із лінії зв’язку
Прочитати байт даних із лінії зв’язку
R1 := байт даних                    ; Зберегти прочитаний байт у R1

; Блок: перевірка типу байта
IF байт даних є інформаційним THEN
; Ініціалізація для оброблення інформаційного байта
R5 := 8                            ; Кількість бітів у байті
R4 := 0                            ; Лічильник оброблених бітів

; Прочитати наступний байт і об’єднати його з R1
Прочитати байт даних із лінії зв’язку
R1 := (R1 << 8) OR байт даних  ; Об’єднати два байти в R1 (16 бітів)

; Блок: виконання видалення біт-стафінгу
CALL "Bit-Stuffing Zero Deletion" with R1
; Після виклику R1 містить оброблені дані,
; R4 — кількість оброблених бітів (має бути встановлена підпрограмою,
 від 0 до 15),
; result_pos — кількість бітів у результаті
IF R4 > 15 THEN
R4 := R4 % 16          ; Забезпечити перебування R4 у межах для C[R4]
END IF

; Блок: накопичення оброблених бітів

IF result_pos > 16 THEN
 result_pos := 16  ; Запобігти переповненню
END IF
output_bit_buffer := (output_bit_buffer << result_pos) OR R1
output_bit_count  := output_bit_count + result_pos

; Блок: запис до буфера, якщо накопичено 8 або більше бітів
WHILE output_bit_count >= 8
byte_to_write := (output_bit_buffer >> (output_bit_count - 8)) AND 0xFF
Записати byte_to_write до буфера
output_bit_count  := output_bit_count - 8
output_bit_buffer := output_bit_buffer AND ((1 << output_bit_count) - 1)
END WHILE

; Блок: додаткове побітове фільтрування R1
; Цей блок може маскувати шість послідовних одиниць (потребує уточнення);
; розглянути винесення в окрему процедуру,
;  якщо він не потрібен для біт-стафінгу
R3 := 0               ; Скинути лічильник одиниць після 0
loop_counter := 1     ; Окремий лічильник циклу, щоб уникнути доступу до C[0]
WHILE loop_counter <= 8
IF loop_counter < 5 THEN
bit := (R1 >> (R7 % 16)) AND 1 ; Перевірити біт у позиції R7 
                                     ; (з обмеженням)
IF bit = 1 THEN
R3 := R3 + 1                   ; Збільшити R3, якщо біт дорівнює 1
loop_counter := loop_counter + 1
ELSE
R3 := 0                        ; Скинути R3 на нульовому біті
loop_counter := loop_counter + 1
END IF
ELSE
R6 := R1
R6 := R6 >> C[R4]
R6 := R6 >> max(0, C[R4] - 1)  ; Подвійний зсув, можливо, 
;для маскування 6 послідовних одиниць
R1 := R1 AND R6
loop_counter := loop_counter + 1
END IF
IF R3 > 0 THEN ; Уникнути доступу до C[0]
C[R3] := C[R3] + 1 
END IF  
R7 := R7 + 1                 ; Збільшити кількість оброблених бітів
END WHILE
; Блок: розподіл бітів після біт-стафінгу та оброблення
IF R4 < R5 THEN
R2 := R1
R5 := 8 - R4
ELSE
; Передати R5 молодших бітів із R1 
; до старших бітів R2
IF R5 = 0 THEN
R2 := 0                         ; Уникнути зсуву на 8, коли R5 = 0
ELSE
R2 := (R1 AND ((1 << R5) - 1)) << (8 - R5)
END IF
R1 := R1 >> R5
Записати молодший байт R2 до буфера
R2 := R1
R5 := max(0, min(8, 8 - R4 + R5))  ; R5 обмежено до [0, 8]
                                   ; до [0, 8], щоб запобігти переповненню
END IF

ELSE   ; Блок: оброблення керівних байтів
Записати байт даних до буфера
END IF
END WHILE

; Блок: запис решти бітів
IF output_bit_count > 0 THEN
byte_to_write := (output_bit_buffer << (8 - output_bit_count)) AND 0xFF
Записати byte_to_write до буфера
END IF

Операцію біт-стафінгу з видаленням нуля в псевдокоді показано на рисунку 3.140.

; Операція біт-стафінгу з видаленням нуля
; Цей алгоритм виконує видалення біт-стафінгу (видалення нуля після п’яти одиниць)
; Вхід: R1 (16-бітовий регістр із даними
                 ; більші входи потребують 32-бітового результату)
; Вихід: R1 (оброблені дані), R4 (кількість оброблених бітів,
; включно з пропущеними стафінговими нулями, може перевищувати 16),
; result_pos (кількість бітів у результаті)

; Блок: ініціалізація змінних
ones_count := 0        ; Лічильник послідовних одиниць
processed_bits := 0    ; Лічильник оброблених бітів
result := 0    ; Результат після видалення біт-стафінгу 
               ; (використати 32 біти, якщо result_pos > 16)
result_pos := 0        ; Позиція в результуючому бітовому потоці
i := 0                 ; Лічильник позиції біта
skip_next := FALSE     ; Прапорець пропуску наступного біта (стафінгового нуля)

; Блок: оброблення всіх 16 бітів у R1
WHILE i < 16
bit := (R1 >> i) AND 1
processed_bits := processed_bits + 1

    ; Визначити, чи копіювати поточний біт до результату
copy_bit := TRUE

IF bit = 1 THEN
ones_count := ones_count + 1
IF ones_count = 5 AND i < 15 THEN
next_bit := (R1 >> (i + 1)) AND 1
IF next_bit = 0 THEN
copy_bit := TRUE          ; П’ята "1" уже скопійована
skip_next := TRUE         ; Прапорець пропуску наступного біта
processed_bits := processed_bits + 1 ; Урахувати пропуск
ones_count := 0
END IF
END IF
ELSE
ones_count := 0
END IF
ELSE
ones_count := 0
END IF

IF copy_bit THEN
IF bit = 1 THEN
result := result OR (1 << result_pos)
END IF
result_pos := result_pos + 1
END IF

IF skip_next THEN
i := i + 2                    ; Пропустити стафінговий нуль (крок +2)
skip_next := FALSE
ELSE
i := i + 1                    ; Звичайний крок
END IF
END WHILE

; Блок: оновлення вихідних значень
R1 := result
R4 := processed_bits

; Блок: повернення керування до драйвера
RETURN R1, R4, result_pos
    

3.4.24. Драйвер приймання даних від ПК до SP для центральних ліній зв’язку

Драйвер приймання інформації від ПК до SP для лінії зв’язку з центром працює всередині SP. Драйвер приймає з лінії зв’язку з ПК інформацію, адресовану центру збору. Прийнята інформація після операції біт-стафінгу записується до буфера поштової скриньки.

Схему ієрархії драйвера показано на рисунку 3.141.

Рисунок 3.141

Драйвер приймання інформації від ПК до SP для лінії зв’язку з центром показано на рисунку 3.142.

ЗАБОРОНИТИ переривання
ПРОЧИТАТИ байт даних із мікросхеми до R1
ПЕРЕМІСТИТИ R4 до R5
ВИКОНАТИ операцію біт-стафінгу в R1
R3 ← кількість одиниць після першого нуля
ЗАПИСАТИ кількість «зайвих» бітів до R4
R4 := R4 + R5
ВИКЛИКАТИ «Передати частину байта з R1 до R2 з урахуванням залишку в R2»
ЗАПИСАТИ молодший байт R2 до буфера
ЗСУНУТИ старший байт R1 праворуч на 8 − R4 бітів
IF R4 = 8 THEN
ЗСУНУТИ R1 праворуч на 8 − R4
ЗАПИСАТИ молодший байт R1 до буфера
END IF
ДОЗВОЛИТИ переривання
    

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

ПЕРЕМІСТИТИ молодший байт R1 до старшого байта R2
ЗСУНУТИ старший байт R2 ліворуч на C(R4) бітів
ВИКОНАТИ OR молодшого і старшого байтів R2
ЗБЕРЕГТИ результат у молодшому байті R2
    

Процедура: виконати операцію біт-стафінгу

C(R7) := 1
C(R8) := 1
WHILE C(R8) ≤ 8 DO
IF C(R3) = 5 THEN
IF bit (R7 + 1) in R1 is 1 THEN
Вставити 0 у позицію R7 + 1
C(R7) := C(R7) + 1
R3 := 0
END-IF
END-IF
C(R7) := C(R7) + 1
Перевірити біт N; if він дорівнює 1 then C(R3) := C(R3) + 1
C(R8) := C(R8) + 1
END-WHILE
    

Процедура вставлення цифри 0 у позицію R7 + 1

СКОПІЮВАТИ R1 до R6
ЗСУНУТИ R1 праворуч на R7
ЗСУНУТИ R1 ліворуч на R7 + 1
ЗСУНУТИ R6 ліворуч на 16 − R7
ЗСУНУТИ R6 праворуч на 16 − R7
ВИКОНАТИ AND R1 з R6, зберегти результат назад до R1
    

R4 := R4 + R5

Зсунути старший байт R1 праворуч на (8 − R4)

R4 + R5 > 8

3.4.25. Програма передавання даних від центру до ПК

Програма передавання інформації від центру до ПК працює всередині SP. У разі використання кільцевого буфера для зберігання інформації в поштовій скриньці для всіх каналів, незалежно від типу й характеру інформації, застосовується уніфікована операція читання та запису до буфера.

Рисунок 3.146

Псевдокод програми передавання інформації від центру до ПК показано на рисунку 3.147.

ПРОЧИТАТИ байт із буфера  
ПЕРЕДАТИ байт даних
    

3.4.26. Програма передавання даних від SP до центру

Програма передавання інформації від SP до центру працює всередині SP. У разі використання кільцевого буфера для зберігання інформації в поштовій скриньці для всіх каналів, незалежно від типу й характеру інформації, застосовується уніфікована операція читання та запису до буфера. Схему ієрархії функцій програми показано на рисунку 3.148.

Рисунок 3.148

Псевдокод програми передавання інформації від SP до центру показано на рисунку 3.149.

ПРОЧИТАТИ байт із буфера  
ПЕРЕДАТИ байт даних
    

3.4.27. Драйвер приймання даних у SP від центральної лінії в режимі байт-стафінгу

У цьому розділі розглянуто варіант забезпечення прозорості переданих даних за допомогою байт-стафінгу. Передбачається, що за відсутності даних до мережі безперервно передається послідовність заповнення виду DLE STX. На приймальному кінці ця послідовність програмно відкидається. Якщо в потоці даних випадково з’являється символ, що збігається з DLE, на передавальному кінці він дублюється, а на приймальному кінці видаляється.

Драйвер працює в ОС SP. Він призначений для приймання інформації, переданої від центру збору, і запису її до поштової скриньки SP для подальшого передавання до ПК. У варіанті байт-стафінгу інформація з лінії зв’язку з центром надходить побайтно; під час пауз надходять байти заповнення у вигляді DLE STX. У тексті інформації можуть траплятися два символи DLE, один із яких має бути відкинутий.

Схему ієрархії драйвера приймання інформації в SP з лінії зв’язку з центром показано на рисунку 3.150.

Рисунок 3.150

Драйвер приймання інформації в SP з лінії зв’язку з центром у варіанті байт-стафінгу показано на рисунку 3.151a.

; ----------------  Оброблення даних із лінії зв’язку  ----------------
; Цей алгоритм читає дані з лінії зв’язку, обробляє прапорці DLE
; і записує дані до буфера.
; Примітка: він видаляє стафінг на основі логіки прапорця DLE.

READ_DATA_BYTE                         ; Прочитати байт даних із лінії
COUNTER ← COUNTER + 1                  ; Збільшити лічильник байтів
CALL VOSST_PROCEDURE                   ; Викликати VOSST згідно з вимогою

IF FLAG_DLE = 1 THEN
IF DATA_BYTE = DLE THEN
WRITE_BUFFER DATA_BYTE          ; Передати стафінговий DLE до буфера
FLAG_DLE ← 0                         ; Скинути прапорець
END IF
FLAG_DLE ← 0     ; Відкинути символ заповнення, наприклад ‘STX DLE STX’
ELSE
IF DATA_BYTE = DLE THEN
FLAG_DLE ← 1                         ; Наступний байт є стафінговим
ELSE
WRITE_BUFFER DATA_BYTE          ; Звичайний байт даних
FLAG_DLE ← 0                         ; Додаткова стійкість
END IF
END IF

Процедуру відновлення показано на рисунку 3.151b.

;  ---------------- Процедура: VOSST Procedure ----------------
; Ця процедура виконує збереження регістрів, керування буфером поштової скриньки
; і скидання лічильника

SAVE_REGS                            ; Зберегти регістри

DS ← ADDRESS_OF_MAILBOX_0            ; Установити покажчик DS на початок
                                     ; усіх кільцевих буферів у поштовій скриньці

IF FLAG_DLE = 1 THEN                     ; Перевірити прапорець DLE
IF DATA_BYTE = SYN THEN           ; Перевірити керівний байт SYN
COUNTER ← 0                        ; Скинути лічильник на початку пакета
END IF
END IF

IF COUNTER overflowed THEN                ; Виявлення тайм-ауту / переповнення
COUNTER ← 0                        ; Запобігти переповненню
CHIP_ADDR ← FIND_TARGET_CHIP()     ; Знайти потрібну мікросхему
OUTPUT 0DB7h TO CHIP_ADDR          ; Надіслати команду синхронізації / скидання
END IF

RESTORE_REGS                                ; Відновити регістри
RET                                         ; Повернутися з процедури

3.4.28. Драйвер приймання даних від ПК до SP для передавання центральною лінією в режимі байт-стафінгу

Драйвер працює в SP. Він приймає байти даних від ПК і передає їх до буфера поштової скриньки для подальшого передавання до лінії зв’язку з центром. Після приймання символу DLE він дублюється. Схему ієрархії показано на рисунку 3.152.

Рисунок 3.152

Драйвер приймання інформації від ПК до SP для лінії зв’язку з центром у варіанті байт-стафінгу показано на рисунку 3.153.

ПРОЧИТАТИ байт даних із мікросхеми
IF байт даних є DLE
ЗАПИСАТИ DLE до буфера
END IF
ЗАПИСАТИ байт до буфера
    

3.4.29. Алгоритм мережевого програмного забезпечення віддаленого концентратора

Система «СБОР» за допомогою мережевого програмного забезпечення забезпечує такі функції:

• передавання вимірювальної інформації від віддалених концентраторів до центру збору для подальшого оброблення;
• обмін організаційною інформацією.

Передавання вимірювальної інформації відбувається у трьох режимах:

• передавання в реальному масштабі часу;
• передавання затриманої інформації;
• режим відтворення.

Обмін організаційною інформацією включає:

• обмін формалізованими повідомленнями;
• телеконференції;
• передавання структурованих документів;
• передавання двійкових файлів.

Підпрограми мережевого програмного забезпечення мають забезпечувати оброблення розривів з’єднання і подальше відновлення шляху доступу через мережеве середовище, виконуючи всі необхідні дії для відновлення міжзадачної взаємодії.

3.4.29.1. Передавання вимірювальних даних у реальному масштабі часу

Основною характеристикою режиму реального часу є передавання інформації зі швидкістю її надходження.

Інформація для транспортної підсистеми надходить від програмного забезпечення, яке безпосередньо взаємодіє з вимірювальними засобами через процесор узгодження ВК. Споживачами інформації є кілька процесів у вузлі центру збору. Один із них, обов’язковий, — процес-реєстратор, який записує всю прийняту інформацію на дискові накопичувачі. Решта процесів можуть завантажуватися в різних режимах роботи за потреби.

Виведення повідомлень до лінії зв’язку в реальному масштабі часу забезпечують такі програми:

• формування черги повідомлень;
• передавання повідомлень із черги до мережі.

Функціональний опис і алгоритми цих програм див. відповідно в розділах 3.4.29.5 і 3.4.29.6.

3.4.29.2. Передавання затриманих даних реального часу

Оскільки передавання вимірювальної інформації відбувається в умовах потенційно ненадійних каналів реального часу, можливі переривання зв’язку з окремими вузлами. Ці переривання можуть виникати навмисно, з ініціативи оператора, який керує процесом інформаційного обміну, або з технічних причин, що виникли в каналі зв’язку. У будь-якому разі ці ситуації мають відстежуватися й оброблятися підпрограмами мережевого середовища.

Вимірювальна інформація, що передається до центру збору в реальному масштабі часу, одночасно записується на зовнішній носій ВК. Якщо встановити зв’язок із центром неможливо, інформація, затримана щодо моменту реального часу, записується на диск ВК і доповнюється прапорцем, який характеризує її як затриману, а потім передається до центру збору в режимі відносного часу.

Транспортування затриманої інформації (DI) відбувається у 2 етапи:

• формування файлів, що містять затриману інформацію;
• передавання цих файлів до віддаленого вузла та їх реєстрація на диску файлового сервера центру збору.

Перший етап реалізується програмним модулем формування файлів, що містять затриману інформацію, написаним мовою C (див. розділ 3.4.29.7). На другому етапі виконується командний файл мовою Shell, який включає виклик стандартної мережевої користувацької утиліти передавання файлів FTP (див. розділ 3.4.29.8).

3.4.29.3. Передавання даних у режимі відтворення

У режимі відтворення інформація передається у відносному часі. Швидкість передавання визначається тільки пропускною здатністю лінії зв’язку. Під час роботи в режимі відтворення інформація вже перебуває в зовнішній пам’яті ВК, що досягається поєднанням режиму реального часу для ВК і відсутності зв’язку з центром.

Для реалізації передавання інформації в режимі відтворення використовується командний файл мовою Shell (див. розділ 3.4.29.9).

3.4.29.4. Передавання організаційних даних

Ця функція активується програмою з центру збору. Наразі її лише окреслено, і вона призначена для підтримання таких операцій:

• обмін одноразовими формалізованими повідомленнями;
• міжтермінальний обмін, тобто телеконференції, між абонентами мережі;
• передавання структурованих документів;
• передавання попередньо розрахованих даних.

Усі ці функції можуть виконуватися за допомогою сервісу "e-mail", доступного кожному оператору, який використовує термінал системи «СБОР».

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

Під час обміну одноразовими формалізованими повідомленнями мережеве середовище надає такі сервіси:

• можливість підготовки та модифікації файла повідомлення;
• перегляд формалізованих повідомлень і вибір повідомлень, необхідних для передавання;
• міжтермінальний обмін заздалегідь підготовленими повідомленнями;
• доступ користувачів до сервісу "e-mail" за паролем, включно з процедурою реєстрації;
• ведення і, за потреби, відображення списку активних користувачів та їхніх псевдонімів;
• підтвердження успішної доставки повідомлення.

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

Система передавання структурованих документів передбачає передавання файлів від одного користувача до іншого, незалежно від активності останнього. Передані файли заносяться до спеціального каталогу і потім можуть бути вибрані одержувачем за потреби. Під час реєстрації користувач отримує повідомлення про наявність файлів, адресованих йому. Користувач може переглядати анотації до вхідних файлів і вибирати потрібні документи у своєму каталозі.

Передавання документів здійснюється за допомогою черги. Усі файли, що потребують передавання, розміщуються в черзі, а монітор "e-mail", переглядаючи файл запитів, намагається встановити логічний канал у вузлі одержувача і надіслати відповідний файл до нього. Після успішного передавання запис запиту видаляється з черги, а початковий файл вилучається.

Попередньо розраховані дані можуть бути двійковими, текстовими або іншими файлами довільної внутрішньої структури. Передавання відбувається «наосліп» у двійковій формі без будь-яких змін. Відправник може мати можливість супроводжувати інформацію відповідним паролем. Отже, під час реалізації функції обміну організаційними даними мережеве середовище має забезпечити таке:

• організувати роботу системи "e-mail";
• підготовку вихідних даних для передавання фіксованих повідомлень від одного віддаленого вузла до іншого;
• міжзадачний зв’язок у віддалених вузлах мережі.
• підтримку виконання підпрограм приймання, відображення та підтвердження повідомлень віддаленим користувачем;
• організацію доступу до сервісу "e-mail" через систему паролів;
• наявність додаткової підпрограми, яка надає користувачу інформацію про поштових абонентів і конкретні номери терміналів, з якими вони працюють.

3.4.29.5. Алгоритм програми формування черги повідомлень

Програма формування черги повідомлень виконує такі функції:

• створює чергу повідомлень;
• розміщує повідомлення в черзі.

Вхідна інформація: адреса й довжина повідомлення, які надходять від програм оброблення повідомлень від ВС «Вега» (див. розділ 3.3.1) і «Кама» (див. розділ 3.3.2).

Схему ієрархії функцій програми формування черги повідомлень показано на рисунку 3.154.

Рисунок 3.154

Програма формування черги повідомлень працює з ідентифікатором черги повідомлень msgid.

Ідентифікатор msgid відповідає черзі повідомлень і структурі даних msgid_ds.

Структура даних msgid_ds черги повідомлень містить:

• структуру msg_perm прав на операції з чергою повідомлень,
• msg_first - покажчик на перше повідомлення в черзі,
• msg_last - покажчик на останнє повідомлення в черзі,
• msg_cbytes - поточну кількість байтів у черзі.
• msg_qnum - кількість повідомлень, що наразі перебувають у черзі,
• msg_qbytes - максимальну кількість байтів, дозволену в черзі,
• msg_lspid - ідентифікатор процесу, який останнім виконав операцію msgsnd,
• msg_lrpid - ідентифікатор процесу, який останнім виконав операцію msgrcv,
• msg_stime - час останньої операції msgsnd,
• msg_rtime - час останньої операції msgrcv,
• msg_ctime - час останньої операції зміни,
• msg_qnum - це кількість повідомлень, що наразі перебувають у черзі,
• msg_qbytes - це максимальна кількість байтів, дозволена в черзі,
• msg_lspid - це ідентифікатор процесу, який останнім виконав операцію msgsnd,
• msg_lrpid - це ідентифікатор процесу, який останнім виконав операцію msgrcv,
• msg_stime - це час останньої операції msgsnd,
• msg_rtime - це час останньої операції msgrcv,
• msg_ctime - це час останньої операції зміни.

Структура msg_perm, яка задає дозвіл на операції з повідомленнями, включає такі елементи:

• ідентифікатор користувача, який створив чергу;
• ідентифікатор групи користувачів, які створили чергу;
• ідентифікатор користувача;
• ідентифікатор групи.

Тип дозволу на операції з повідомленнями інтерпретується так:

• 00400 - читання власником
• 00200 - запис власником
• 00060 - читання, запис групою
• 00006 - читання, запис іншими

Алгоритм програми формування черги повідомлень подано на рисунку 3.155.

УСТАНОВИТИ прапорець першого входу в програму  
PRENTRY := 0  
УСТАНОВИТИ прапорець зайнятості програми  
PRG := 1  
IF чергу НЕ створено THEN
СТВОРИТИ і ОТРИМАТИ її ідентифікатор msgid
УСТАНОВИТИ прапорець PRENTRY := 1
УСТАНОВИТИ лічильник повідомлень qnum := 0
ELSE
IF черга ВЖЕ заповнена THEN
УСТАНОВИТИ прапорець переповнення PR := 1
ELSE
ПОМІСТИТИ повідомлення до черги
qnum := qnum + 1
УСТАНОВИТИ прапорець PRG := 0
END IF
END IF
    

Програма формування черги повідомлень використовує такі системні виклики:

• msgget отримати ідентифікатор черги повідомлень msgid;
• msgsnd надіслати повідомлення до черги;
• msgrcv прочитати повідомлення з черги.

3.4.29.6. Алгоритм програми передавання мережевих повідомлень

Програма передавання повідомлень із черги до мережі передає повідомлення від ВС «Вега» або «Кама».

Програма передавання повідомлень із черги до мережі не аналізує вміст повідомлень. Функції програми показано на рисунку 3.156.

Рисунок 3.156

Програма передавання повідомлень із черги до мережі виконується в середовищі TCP/IP Interactive Unix із використанням сокетів. Сокет — це кінцева адресована точка зв’язку (блок) усередині програми, пов’язана з одним із процесів обміну. Іменована пара сокетів однозначно визначає з’єднання між комутованими вузлами — центром збору і ВК. Взаємодія процесів в обміні має форму з’єднання клієнт-сервер; програма передавання повідомлень із черги до мережі є клієнтом, а програма приймання в центрі збору — сервером, причому клієнт є активним процесом, а сервер — пасивним процесом.

Клієнт використовує такі мережеві виклики:

• socket
• bind
• connect
• write
• read
• close

Клієнт і сервер використовують однакові мережеві виклики для приймання та надсилання повідомлень і різні мережеві виклики під час установлення з’єднання. На сервері після створення його сокета для встановлення з’єднання з клієнтом мають бути видані два мережеві виклики:

• listen, вказує готовність прослуховувати вхідні запити на з’єднання;
• accept, використовується для приймання з’єднання, тобто виклику connect, від клієнта.

Виклик повертає клієнту підтвердження з’єднання. Після встановлення з’єднання дані можна передавати/приймати за допомогою таких викликів: write, read, send, recv.

Виклики send, recv ідентичні write, read, за винятком аргументу flags. Якщо на серверному сокеті немає повідомлень, виклик recv очікує, доки ці повідомлення надійдуть.

Програма виведення ініціює обмін, тобто діє як активний клієнт. Клієнт установлює з’єднання з програмою-сервером центру збору за допомогою мережевого виклику connect, параметрами якого є: socket і адреса призначення.

Алгоритм надсилання повідомлення через сокет показано на рисунку 3.157.

СТВОРИТИ SOCKET  
ПРИСВОЇТИ SOCKET ІМ’Я  
УСТАНОВИТИ З’ЄДНАННЯ  
ПРИЙНЯТИ З’ЄДНАННЯ НА SOCKET  
WHILE У ЧЕРЗІ Є ПОВІДОМЛЕННЯ  
НАДІСЛАТИ ПОВІДОМЛЕННЯ
IF підтвердження НЕ отримано THEN
УСТАНОВИТИ прапорець затриманої інформації
END IF
END WHILE
    

3.4.29.7. Програма формування файлів затриманої інформації

Ця програма реалізує такі функції:

• вибір файлів, зареєстрованих під час конкретних випробувань. Вибір файлів виконується на основі дати, заданої оператором, від якої необхідно виконати післясеансове передавання затриманої інформації.
• перегляд вмісту файла і вибір за конкретною ознакою записів, що містять затриману інформацію;
• формування нових файлів, що містять затриману інформацію, у каталозі COLLECTION/DATA/SERVER/TMP.

Вхідні параметри: Flag - ознака наявності DI;

Вихідна інформація: файли, що містять DI, розміщуються в каталозі COLLECTION/DATA/SERVER/TMP.

Після активації програми на екрані з’являється запит,

у якому оператор має ввести дату, починаючи з якої файли будуть вибиратися для виявлення в них DI.

Дата вводиться у форматі DD/MM/YY.

Останній рядок екрана містить підказку, що пояснює значення і формат дати, яка вводиться.

Схему ієрархії функцій програмного модуля формування файлів затриманої інформації показано на рисунку 3.158.

Рисунок 3.158

Опис програми формування файлів із затриманою інформацією в псевдокоді подано на рисунку 3.159.

; Алгоритм “Extract DI Records” — копіювання записів із позначкою DI 
                                                           ; до окремого файла
IF DI = yes THEN
IF directory COLLECTION/DATA/SERVER/TMP DOES NOT exist THEN
CREATE directory COLLECTION/DATA/SERVER/TMP
END IF

WHILE there are files in COLLECTION/DATA/SERVER directory
OPEN file from COLLECTION/DATA/SERVER directory
OPEN file for writing DI

WHILE NOT end of file
READ record into buffer
IF 1st character of record = DI indicator THEN
WRITE record to DI file
INCREMENT record pointer in DI file by 1
END IF
INCREMENT record pointer in source file by 1
END WHILE

CLOSE file from COLLECTION/DATA/SERVER directory
CLOSE file for writing DI
WRITE file to COLLECTION/DATA/SERVER/TMP directory
GET next file from COLLECTION/DATA/SERVER directory
END WHILE
END IF

Формування імен файлів, що містять DI, відбувається так: до імені початкового файла, який містить вимірювальну інформацію, першим символом додається символ "O".

3.4.29.8. Алгоритм командного файла для передавання затриманої інформації

Командний файл мовою Shell працює так:

1. Установлює з’єднання з віддаленим вузлом за допомогою команди OPEN утиліти FTP.
2. Установлює каталог COLLECTION/DATA/SERVER/TMP як поточний.
3. Записує список усіх файлів у каталозі COLLECTION/DATA/SERVER/TMP до змінної DirTmp.
4. Організовує цикл, доки значення спискової змінної DirTmp не є порожнім.
5. У тілі циклу виконуються такі операції:
   • значення елемента списку DirTmp передається як параметр до FTP;
   • виконується команда PUT утиліти передавання файлів FTP;
   • після видачі повідомлення про нормальне завершення передавання файла цей файл видаляється з каталогу;
   • покажчик збільшується, і виконується перехід на початок циклу.
6. Закриває з’єднання з віддаленим вузлом за допомогою команди CLOSE утиліти FTP.

Надалі передані файли можуть бути приєднані до файлів, що містять вимірювальну інформацію цього типу, або можуть оброблятися самостійно.

3.4.29.9. Алгоритм командного файла для передавання інформації в режимі відтворення

Алгоритм командного файла для передавання інформації в режимі відтворення такий:

1. Вміст файла, що містить список файлів для передавання в режимі відтворення, присвоюється списковій змінній Flist.
2. Установлюється з’єднання з віддаленим вузлом за допомогою команди OPEN утиліти FTP.
3. Організовується цикл, доки спискова змінна Flist не є порожньою.
4. У тілі циклу:
   • ім’я файла, вибране зі спискової змінної Flist, передається як параметр до утиліти передавання файлів FTP.
   • файл передається до віддаленого вузла за допомогою команди PUT утиліти FTP і записується на диск файлового сервера центру збору.
5. З’єднання з віддаленим вузлом закривається за допомогою команди CLOSE утиліти FTP.

4. ТЕХНІКО-ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ

Особливістю програмного забезпечення, що розробляється для ВК, є широке використання стандартного програмного забезпечення і прикладних технічних засобів. Використовуються операційне середовище і мережеві засоби, що постачаються для персональних комп’ютерів типу IBM PC.

Такий підхід є обґрунтованим з погляду витрат на розроблення, оскільки в сучасних інформаційних системах витрати на розроблення програмного забезпечення становлять до 80% загальної вартості робіт.

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

LIST OF ABBREVIATIONS / ПЕРЕЛІК СКОРОЧЕНЬ

Примітка: скорочення SP у цьому документі означає Synchronization Processor — процесор узгодження. Якщо в окремих фрагментах трапляється форма PS, її слід розглядати як технічну помилку або слід буквального перекладу скорочення «ПС», а не як окремий термін.

LIST OF USED DOCUMENTS / ПЕРЕЛІК ВИКОРИСТАНИХ ДОКУМЕНТІВ

1. Єдина система програмної документації. Москва: видавництво стандартів, 1985
2. GOST 17422-72
3. GOST 19767-74
4. J. Hughes, J. Michtom. Структурний підхід до програмування. Москва: Мир, 1980

ДОДАТОК А. МЕТОД ПОБУДОВИ ОПТИМАЛЬНОЇ ТОПОЛОГІЇ ФІЗИЧНОЇ СТРУКТУРИ ОБЧИСЛЮВАЛЬНОЇ МЕРЕЖІ ОБМІНУ ПОВІДОМЛЕННЯМИ

A.1. Традиційні топології обчислювальної мережі обміну повідомленнями

Топологія обчислювальної мережі обміну повідомленнями — це її фізична структура, тобто спосіб, у який вимірювальні системи (MS) з’єднані з вузлами збору даних. Термін «топологія» запозичений із геометрії та використовується для опису схеми зв’язності такої розподіленої мережі. Традиційні топології, показані на рисунку A.1, включають:

1. ієрархічну (деревоподібну),
2. горизонтальну (шинну),
3. зіркоподібну,
4. кільцеву,
5. комірчасту.

Рисунок A.1. Традиційні мережеві топології.

Кожна з цих конфігурацій застосовувалася в різних технічних системах — від військових комплексів до цивільних систем спостереження й телеметрії.

A.1.1. Структура обчислювальної мережі обміну повідомленнями

У контексті побудови топології ми розглядаємо системи, у яких кілька розподілених вимірювальних систем (MS) передають дані до центрального вузла — концентратора Центру збору (CCC), безпосередньо або через проміжні вузли — віддалені концентратори (RC).

Така архітектура типова для систем, що працюють на великих географічних просторах: від ракетно-космічних комплексів, де вимірювальні системи розміщують уздовж траєкторії польоту, до метеорологічних служб, де розташування вимірювальних систем визначається регіональною географією.

В усіх випадках мережа має ієрархічну структуру:

• верхній рівень — концентратор Центру збору (CCC),
• середній рівень — віддалені концентратори (RC),
• нижній рівень — вимірювальні системи (MS).

A.1.2. Топологія обчислювальної мережі обміну повідомленнями

Обчислювальна мережа обміну повідомленнями будується як ієрархічна структура, у якій кожен елемент нижчого рівня передає інформацію через один або кілька проміжних вузлів до центрального вузла збору — концентратора Центру збору (CCC).

Вимірювальні системи (MS) підключаються або безпосередньо до CCC, або через один із віддалених концентраторів (RC), установлених у вибраних точках мережі. Така конфігурація дає змогу істотно зменшити загальну вартість ліній зв’язку та спрощує спряження різнорідних компонентів. У цьому сенсі віддалений концентратор (RC) виконує роль універсального елемента фізичної структури мережі, забезпечуючи інтеграцію будь-якої вимірювальної системи в єдину ієрархію.

Ключовий принцип — логіка обміну повідомленнями: кожен вузол мережі передає не сирі потоки даних, а змістовні повідомлення, які можуть містити телеметрію, керівні команди або вимірювальні кадри. Сама архітектура не залежить від конкретної апаратури чи протоколів зв’язку.

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

A.2. Метод побудови оптимальної топології фізичної структури обчислювальної мережі обміну повідомленнями

«Технічні задачі зазвичай постають як задачі оптимізації з двох основних причин. По-перше, обмеженість ресурсів і різноманітність наших потреб змушують нас обережно використовувати ресурси й зважувати потреби. По-друге, виробництво та використання технічних засобів приводять не лише до бажаних, а й до небажаних наслідків, тому від добрих рішень технічних задач завжди очікують оптимізації фактичної користі». [3]

Розглянемо відомі методи проєктування топологій мереж передавання даних. Згідно з [1], ці методи класифікуються так:

1. проєктування топології комунікаційної підмережі для підтримки трафіку, що генерується терміналами, зокрема вибір розташування вузлів, ліній зв’язку та пропускної здатності кожної лінії;
2. проєктування локальної мережі доступу, тобто набору ліній зв’язку, що з’єднують термінали з вхідними вузлами підмережі.

З урахуванням територіального та географічного розподілу вимірювальних пунктів і вимірювальних систем (MS), наприклад уздовж траєкторії випробувального польоту МБР, природно розглядати мережу як локальну мережу доступу.

Існують два можливі способи підключення вимірювальних систем: або безпосередньо до концентратора Центру збору (CCC), або через віддалений концентратор (RC). Якщо такий вибір доступний, він відкриває можливість мінімізувати вартість системи обробки інформації для збору вхідних телеметричних даних.

Водночас, використовуючи раніше введені спрощення та припущення, Ніколаєв поширив відомий метод «додавання», запропонований J. Martin і описаний M. Schwartz [4], на нові класи об’єктів і систем — зокрема на обчислювальну мережу обміну повідомленнями та віддалені концентратори. Оптимальна за вартістю топологія системи збору телеметричних даних «Сбор» для космодрому Плесецьк також була розроблена автором із використанням цього методу «додавання», що підтверджено актами впровадження.

Комплексне й точне розв’язання задачі синтезу топології є складним завданням. Бажаний підхід полягає в розробленні та використанні готових алгоритмів і їх об’єднанні в програмний пакет топологічного синтезу. Прикладом такого пакета є «Програмно-методичний комплекс автоматизованого проєктування топології мікроелектронної апаратури», розроблений Ніколаєвим у співпраці з Волошиним [2].

Формальніше постановку задачі можна описати так: множина \( N \) вимірювальних систем має бути підключена через віддалені концентратори до CCC. За наявності множини вимірювальних систем і множини можливих місць розташування RC необхідно вибрати відповідну підмножину та визначити, які вимірювальні системи підключаються до яких RC, а які — безпосередньо до CCC. RC може розміщуватися разом із самою вимірювальною системою, як у системах «Вега».

Вартість установлення RC включає вартість обладнання, вартість введення в експлуатацію та вартість лінії зв’язку між RC і CCC. Передбачається, що до одного RC може бути підключено не більше ніж \( N_{\text{max}} \) вимірювальних систем. Наприклад, комплект NI525 включає 6 вимірювальних систем, тоді як метеорологічний концентратор «Бриз», що використовувався в Державній гідрометеорологічній службі України, підтримує 45 вимірювальних систем.

Передбачається, що CCC має необмежену пропускну здатність. Нехай вартість підключення \( i \)-ї вимірювальної системи до \( j \)-го RC позначається як \( C_{ij} \), де \( i = 1 \ldots N \), \( j = 0 \ldots N_K \) — при цьому 0 відповідає CCC.

Визначимо точний вираз для цільової функції загальної вартості \( S \), яку потрібно мінімізувати. Введемо змінну...

Введемо змінну \( x_{ij} \), де

Змінна \( y_j \) дорівнює 1, якщо \( RC_j \) встановлений і використовується, і \( y_j = 0 \), якщо \( RC_j \) не встановлений. Інакше кажучи, \( y_j = 1 \), якщо \( \sum_{i=1}^{N} x_{ij} > 0 \), і \( y_j = 0 \) в іншому випадку. Отже, \( y_j = 1 \), якщо до j-го RC підключена принаймні одна вимірювальна система.

Тоді вираз для загальної вартості, яку потрібно мінімізувати, має такий вигляд:

Перший доданок визначає вартість установлених RC, а другий доданок — вартість ліній зв’язку, що з’єднують вимірювальні системи з RC. Мінімізація функції \( S_{\Sigma} \) має виконуватися з урахуванням обмежень.

1)  \[ \sum_{j=0}^{N_K} x_{ij} = 1,\quad i = 1, N, \] що означає, що кожна вимірювальна система обов’язково має бути підключена або до віддаленого концентратора (RC), або безпосередньо до центрального концентратора (CCC).

2)  \[ \sum_{j=0}^{N_K} x_{ij} \leq N,\quad j = 1, \overline{N_K}, \] що означає, що до будь-якого RC може бути підключено не більше ніж N вимірювальних систем.

Задача полягає у визначенні множини змінних \( y_j \) і \( x_{ij} \), які мінімізують \( S_{\Sigma} \) за обмежень 1) і 2).

Якщо цілочисельне обмеження \( x_{ij} = 0 \) або \( 1 \) замінити нецілочисельним обмеженням

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

З літератури [14] відомо, що розв’язок, отриманий симплекс-методом, буде цілочисельним, тобто \( x_{ij} \) дорівнюватиме 0 або 1. Тому розв’язання задачі без урахування цілочисельних обмежень автоматично приведе до оптимального цілочисельного розв’язку.

Складність розв’язання задачі визначається розмірністю мережі. Тому для великих мереж рекомендується використовувати евристичні алгоритми, такі як “addition” і “removal” [83].

Щоб пояснити використання евристичних методів побудови топології, розглянемо приклад побудови обчислювальної мережі обміну повідомленнями методом “addition”. Є вісім вимірювальних систем (MS), інформацію від яких потрібно зібрати в центральному концентраторі збору (CCC).

У цьому випадку можна встановити три віддалені концентратори (RC): \( K_1, K_2, K_3 \), які можуть збирати інформацію та передавати її до Центру збору.

Припустимо, що вартість установлення RC, включно з вартістю лінії зв’язку до CCC, становить (в умовних одиницях):

Вартість ліній зв’язку між вимірювальними системами та вузлами (CCC і RC) визначається елементами матриці \( C_{ij} \).

Матриця вартості з’єднань між вимірювальними системами (MS) та вузлами (CCC і RC):

Рядки відповідають вимірювальним системам (MS), а стовпці представляють вузли: стовпець 0 відповідає центральному концентратору CCC, тоді як стовпці 1, 2 і 3 представляють віддалені концентратори RC₁, RC₂ і RC₃ відповідно.

На рисунку A.2 показано множину автономних MS і RC, місця розташування яких відомі та використовуються як вихідні дані для побудови топології обчислювальної мережі обміну повідомленнями.

Спочатку всі вимірювальні системи (MS) підключені до центрального концентратора збору даних (CCC):

Рисунок A.2. Множина MS і RC як фізичних елементів побудованої
обчислювальної мережі обміну повідомленнями.

Спочатку відомі лише запропоновані місця встановлення концентраторів (RC). Установлення RC виконується за ітераційною схемою, спрямованою на поступове зменшення загальної вартості обчислювальної мережі обміну повідомленнями.

Цей алгоритм належить до класу алгоритмів найшвидшого спуску.

Рисунок A.3. Початковий етап — підключення всіх MS безпосередньо до CCC.

На початку розв’язання задачі передбачається, що функціонує лише центральний концентратор збору даних (CCC), а всі вимірювальні системи (MS) підключені до нього безпосередньо, як показано на рисунку A.3.

Початкова загальна вартість зіркоподібної топології обчислювальної мережі обміну повідомленнями обчислюється шляхом підсумовування елементів нульового стовпця матриці C:

$$ S_{\Sigma} = \sum_{i=1}^{8} C_{i0} = 27\ \text{c.u. (conventional units)} \tag{A.4} $$

Крок 1. Послідовно встановити RC у вимірювальних пунктах і визначити економію вартості за від’ємними значеннями різниць:

$$ C_{ij} - C_{i0},\quad j = 1,3,\quad i = 1,8. \tag{A.5} $$

Значення різниць показані в таблиці A.1. Якщо RC₁ встановити з підключеними вимірювальними системами MS₁, MS₂ і MS₃, загальна вартість мережі зменшиться до 25 одиниць:

Якщо концентратор \( RC_1 \) встановити з підключеними вимірювальними системами \( MS_1 \), \( MS_2 \) і \( MS_3 \), загальна вартість мережі зменшиться до 25 одиниць:

\[ S_1 = \sum_{i \in \{3,4,5,7,8\}} C_{i0} + \sum_{i \in \{1,2,6\}} C_{i1} + f_1 = 25\ \text{c.u.} \tag{A.6} \]

Якщо замість першого концентратора \( RC_1 \) встановити другий концентратор \( RC_2 \), загальна вартість мережі зменшиться до 18,5 одиниць:

\[ S_2 = \sum\limits_{i \in \{2,3,7\}} C_{i0} + \sum\limits_{i \in \{1,4,5,6,8\}} C_{i2} + f_2 = 18.5\ \text{c.u.} \tag{A.7} \]

Вартість мережі на першому кроці (за встановлення лише одного віддаленого концентратора) стане мінімальною і дорівнюватиме 17 одиницям, якщо замість другого концентратора \( RC_2 \) встановити третій концентратор \( RC_3 \).

\[ S_3 = \sum_{i \in \{1,2,3,4\}} C_{i0} + \sum_{i \in \{5,6,7,8\}} C_{i3} + f_3 = 17\ \text{c.u.} \tag{A.8} \]

Рисунок A.4. Перший крок алгоритму “addition”: установлення RC.

На основі розрахованої загальної вартості обчислювальної мережі обміну повідомленнями з одним установленим віддаленим концентратором зроблено висновок, що встановлення третього концентратора \( RC_3 \) є найвигіднішим варіантом, оскільки зменшує вартість мережі на 10 одиниць \( (27 - 17) \). Конфігурації, що дають 25 і 18,5 одиниць, не ілюструються, оскільки вони є проміжними та менш вигідними порівняно з конфігурацією в 17 одиниць, вибраною для подальшої оптимізації.

Крок 2. Після встановлення RC₃ додається наступний концентратор, і доцільність підключення або RC₁, або RC₂ оцінюється з погляду потенційної економії. Розглядаються всі вимірювальні системи (MS), включно з тими, що вже підключені до RC₃. Для цього складається таблиця A.2. На основі від’ємних значень у таблиці A.2 стає зрозуміло, що підключення вимірювальних систем MS₁ і MS₂ до RC₁ дає перевагу за вартістю. Потім економія вартості перевіряється:

Рисунок A.5. Топологія мережі після встановлення наступного RC.

Тепер додаємо концентратор RC₂ і перевіряємо, чи є його встановлення обґрунтованим. Різниці показані в таблиці A.3. Установлення RC₂ дає економію вартості завдяки підключенню до нього вимірювальних систем, позначених як P₄ і P₅. Перевіримо загальну вартість мережі. Вона становитиме:

Рисунок A.6. Топологія мережі з мінімальною вартістю.

A.3. Топологія мережі обміну повідомленнями: покрокове формування

← →

A.4. Висновки

1. Обчислювальна мережа обміну повідомленнями, що охоплює віддалені вимірювальні системи (MS), організована як ієрархічна структура, де концентратор Центру збору (CCC) розташований на верхньому рівні, віддалені концентратори (RC) працюють на проміжному рівні, а MS розташовані на нижньому рівні. Така організація придатна для телеметричних, метеорологічних та інших розподілених систем, що працюють у реальному часі.
2. Методологія побудови оптимальної топології полягає в адаптації методу "addition" до нового класу задач, де віддалені концентратори (RC) слугують універсальними вузлами для інтеграції різних вимірювальних систем в єдину мережу на основі пріоритетного обміну повідомленнями.
3. Технологія інформаційного концентратора продемонструвала здатність переносити рішення з військової сфери до цивільних систем — метеорології, транспорту, енергетики, — підкреслюючи її універсальність і масштабованість.
4. Для проєктів, що реалізуються з використанням SCRUM або інших гнучких методологій, калькулятор надає оцінки трудомісткості, які узгоджуються з водоспадним методом у межах інженерної точності приблизно ±5%. Це робить інструмент застосовним навіть у сучасних середовищах agile-розробки.
5. Калькулятор трудомісткості на головній сторінці стискає 39 років інженерного досвіду в алгоритми. Він відображає, як моя команда досвідчених розробників реалізувала б ваш проєкт, балансуючи трудомісткість, розмір команди та строки. Ці числа — не просто оцінки: вони підкріплені реальними системами, що працюють в екстремальних умовах: військовими платформами реального часу, де відмова неприпустима, і метеорологічними комплексами, які безперервно збирають дані понад 25 років, не зупиняючись навіть під час ураганів. Якщо ви можете зробити краще — мій досвід став для вас трампліном, і це найвищий успіх. 👉 Спробувати калькулятор.

Генеалогія інформаційних концентраторів

1991 — "Сбор"
Концентратор пройшов кваліфікаційні випробування.

1993 — "Сбор"
Було створено криптографічно захищену мережу між Плесецьком (Мирним) і Воркутою.

1995 — "Сбор"
Систему "Сбор" було введено в експлуатацію: Северодвінськ — Мирний — Воркута.

1995 — "Єдиний центр управління"
Було впроваджено пріоритетну обробку: команди управління оброблялися з вищим пріоритетом.

1997 — "Єдиний центр управління"
Адаптивне управління антенними полями географічно розподілених радіотехнічних систем у реальному машинному часі під час випробувань балістичних ракет.

1998 — Підключення модернізованої MS "Вега", Норильськ, через супутниковий канал і апаратуру "Кристал".

1999 — Метеорологічний концентратор "Бриз"

• Перекодування та переформатування повідомлень на льоту
• Розширена шкала пріоритетів
• Динамічне керування трафіком і перемикання напрямків
• Досі перебуває в експлуатації

2002 — СКНОУ

• Розширені можливості математичних обчислень у реальному часі
• Скорочені функції керування трафіком через відсутність спеціальних вимог
• Візуалізація стану передавання, обчислень і супутникових угруповань у реальному часі

2014 — Облік міських пасажиропотоків

• Концентратор використовується як ключовий елемент системи реального часу в міському громадському транспорті
• Як вузол комутації повідомлень концентратор повністю розв’язує фізичні пристрої та логіку системи, даючи змогу будувати гнучку архітектуру без обмежень

Посилання до Додатка A: топологія обчислювальної мережі обміну повідомленнями

1. Мартин Дж. Планирование информационно-вычислительных систем. – М.: Радио и связь, 1982.
   Martin J. Planning of Information and Computing Systems. – Moscow: Radio i Svyaz, 1982.
2. Волошин А.Н., Николаев А.Н. Программно-методический комплекс проектирования топологии. – Киев: ИПРИ, 1991.
   Voloshin A.N., Nikolaev A.N. Software and Methodological Package for Topology Design. – Kyiv: IPRI, 1991.
3. Шеффлер И. Условия механизации мышления. – М.: Прогресс, 1978.
   Scheffler I. Conditions for Mechanization of Thinking. – Moscow: Progress, 1978.
4. Шварц М. Компьютерные системы связи. – М.: Мир, 1982.
   Schwartz M. Computer Communication Systems. – Moscow: Mir, 1982.

Concentrator-91, збережений для професійної спільноти як історичний артефакт і навчальний приклад водоспадної розробки на стадії технічного проєкту. Перший концентратор автора серед багатьох наступних.

Спіть спокійно. Постачайте вчасно.

Перевірена процедура планування від команди Concentrator:

1. Оцініть трудомісткість проєкту
2. Визначте правильний розмір команди
3. Працюйте без авралу в останню мить

“Проста методологія, яка давала нам змогу спокійно спати навіть напередодні жорстких строків.”

⚡ Оцініть свій проєкт

Працює лише для тих, хто підтримує свободу

Андрій Ніколаєв
Технічний керівник, проєкт Concentrator-91