РОЗРОБКА ПРОГРАМНО-МЕТОДИЧНОГО КОМПЛЕКСУ ДЛЯ ДОСЛІДЖЕННЯ РОБОТИ ОСНОВНИХ АЛГОРИТМІВ КЕРУЮЧИХ СИСТЕМ ЕАТС. Структура даних комплексу. Регістри виклику, призначення та його склад. У відповідності з багатопрограмним керуванням СКПК обслуговує велику кількість заявок, що надходять від абонентів, кожна з яких знаходиться на певному етапі, як прийом номера, його аналіз, посилка виклику, …, (розділ 1). Перевід виклику з одного етапу на інший здійснюється алгоритмами програмного забезпечення СКПК, нормальне виконання яких можливе тільки при наявності повного опису стану виклику. Дані про один виклик на час на протязі якого обслуговується інший виклик, запам’ятовується в спеціальній структурі в оперативній пам’яті системи. Ця структура складається із послідовних комірок пам’яті і називається регістром виклику (РВ – структура Calling Register, об’єкт CREG). Регістри виклику повинні зберігати доволі великий об’єм інформації, необхідної для поетапного обслуговування абонентських заявок. Перерахуємо які комірки повинні бути присутні в РВ для повного запам’ятовування стану виклику: source_shlf – лінійний номер АК джерельного абонента; destin_shlf – лінійний номер АК абонента призначення: destin_number[] – визначений системою номер, який надійшов зі сторони джерельного абонента: numptr – вказівник на прийом текучої цифри номеру, ця змінна вказує на прийому якої цифри знаходиться алгоритм прийому номера: shlf_old – попередній стан контрольної точки абонентського шлейфу; n0 – зафіксована кількість станів відповідно з низьким та високим рівнями абонентського шлейфу; imp_cur – зберігає значення кількості прийнятих цифр на теперішній момент часу; imp_old – значення кількості прийнятих цифр при попередньому опитуванні; level – відображає етап обслуговування на якому знаходиться виклик, а саме: =1 – виявлення сигналу виклику та очікування набору номера; =2 – прийом та аналіз надходячого набору номера; =3 – пошук вільного з’єднувального шляху; =4 – рівень очікування з’єднання; =5 – очікування роз’єднання. direction – напрямок виклику, може приймати наступні значення: =3 – внутрістанційний; =2 – зовністанційний; =1 – екстремальний; free – свідчить про вільність (=1) чи зайнятість (=0) регістру виклику; структура BALaddr – містить координати з’єднувальних шляхів в КП, об’єкти src та dest використовуються алгоритмом аналізу вільного з’єднувального шляху, який резервує та встановлює розмовний тракт в комутаційному полі. Дана структура має наступні поля: b88 – номер блоку матричного з’єднувача із структурою 8x8 першої ступені блоку абонентських ліній; i88 – номер входу вибраного матричного з’єднувача 8x8; o88 – номер виходу матричного з’єднувача 8x8; b44 – номер блоку другої ступені БАЛ із структурою 4x4; i44 – номер входу з’єднувача 4x4; o44 – номер виходу з’єднувача 4x4. talkTimer – змінна в якій фіксується час розмови абонента. Використовування РВ дозволяє при непостійності обслуговування виклику алгоритмами програмного забезпечення СКПК забезпечувати логічну неперервність та реальний масштаб часу обслуговування щодо абонентів. У відповідності з вищесказаним можна зробити висновок, що необхідно одночасно зберігати в пам’яті керуючої системи такої кількості РВ, яке забезпечуватиме обслуговування потрібної кількості абонентів в час найбільшого навантаження з заданою якістю (розділ 1). З цих міркувань в імітаційну модель введено змінну MAX_CALLREG, за допомогою якої можна встановлювати різну кількість РВ. Цим самим надається змога досліджувати поведінку моделі та робити відповідні висновки, щодо реальних керуючих систем. Дані про стан абонентських комплектів. Як відомо, з розділу 1, в реальних автоматичних телефонних станціях до складу АК входять пристрої, які інформують станцію про наміри, під’єднаного до цього АК, абонента: необхідність у встановленні розмовного контакту з потрібним абонентом; дії, що направлені на вимогу, щодо керуючої системи, для здійснення необхідного розмовного контакту; очікування обслуговування своєї вимоги; відмова від вимоги. Це прості електричні пристрої – реле. Також відомо, що існують два типа реле в АК: - лінійне реле, яке є інерційне в утриманні контакту КТ; - розділююче реле, для під’єднання абонентської лінії до КП. Як видно з рисунку 1.2 необхідність в інерційності лінійного реле зумовлене короткочасними розмиканнями імпульсного ключа в телефонному апараті при наборі номеру (див. параметри сигналу набору номера на рисунку 1.6. Це значить, що при короткочасному зниканні постійного струму, що проходить через абонентську лінію (цю лінію називають абонентським шлейфом), лінійне реле залишатиметься в стані утримання контакту КТ. Таким чином стан КТ лінійного реле можна використовувати в якості сигналу при відбою абонента під час набору номера. Якщо тривалість розмикання імпульсного ключа ІК (Рис. 1.5) більше за інерційність лінійного реле, тоді відпускається його контакт, далі периферійний опитуючий пристрій визначає цю зміну, а центральний керуючий пристрій фіксує, що абонент вибув з обслуговування. Короткочасні зникання струму в абонентському шлейфі фіксуються периферійним пристроєм – приймачем імпульсного набору номера, за допомогою швидкодіюче реле, що керує відповідною КТ, яка сканується з метою виявлення відсутності чи наявності струму в абонентській лінії. Якщо взяти значення сканувань відносно пройденого часу, можна легко визначити номер, який набирає абонент. В програмній моделі реальної АТС ці елементи також зберігаються, і їх описуємо у вигляді змінних. Згадувалося вище, що для визначення дій зі сторони абонента на АТС потрібно КТ, які можуть бути в двох стійких станах (замкнутому або розімкнутому), але цікавість являють не тільки їхні стани, а й моменти зміни станів. Замкнутий стан КТ ЛР означає, що абонент активний на даний момент часу, а розімкнутий стан – він є неактивним. Моменти переходу з одного стану в інший визначають запит чи відбій зі сторони абонента. Контрольній точці ЛР відповідає комірка в ОЗП комп’ютера, що займає лише один біт. Отже для моделювання 128 абонентів потрібно 128 біт, чи 128/8=16 байт. Змінна R1[16] – це динамічний масив об’ємом в 16 байт для відображення станів 128 КТ абонентських комплектів. Так як існує необхідність у зберіганні попередніх станів КТ, з метою виявлення перехідних моментів, то використовується ще один масив R2[16] аналогічний по структурі масиву R1[]. Кожен біт масиву R1 лінійно прив’язаний до відповідного АК, отже АК №1 відповідає 1-ому розряду 1-ої групи, АК №2 – 2-ому розряду 1-ої групи і так далі (Рис. 3.1). Взагалі формула для визначення адреси N-го АК є наступна: номер групи дорівнює N/8, а розташування в цій групі абонентського комплекту, який шукаємо, рівне залишку від ділення по модулю вісім N%8. Отже спочатку вибирається потрібна група, яка складається з восьми АК, а потім конкретний абонентський комплект у вибраній групі. Стан необхідної КТ АК вибирається за допомогою логічних функцій: кон’юнкції, диз’юнкції та побітових зсувів.
Рис. 3.1 Відображення АК в пам’яті комп'ютера. Наведемо приклад визначення стану 73-го АК, скориставшись такими змінними: g_abn, n_abn, m_abn: формуємо адресу групи АК – g_abn = 73 / 8 = 9; визначаємо номер АК в групі – n_abn = 73 % 8 = 1; маска для визначення стану АК – m_abn = 128 >> n_abn = 64; перевіра – R1[g_abn]&m_abn = (true or false)? = в даному випадку (Рис. 3.1) визначено активний стан абонентського шлейфу (тобто true). Для перевірки моменту переходу скористаємося змінними: R0[16], R3, R4, Rbusy[16], R5, R2[]:
результат: k – індекс групи АК, R5 – одиничні розряди в цій змінній свідчать про те, що у відповідних АК, даної групи, відбулися сигнали виклику, які потрібно в подальшому обробити, де R0[16] – масив, який призначений для заборони (чи дозволу) зчитування стану з відповідного АК (аналогічний по структурі до R1[] ), використовується у випадках несправності абонентських комплектів, щоб алгоритм прийому сигналів виклику не реагував на випадкові зміни в точках сканування; R2[] – масив попередніх станів опиту контрольних точок АК; R3 – змінна в якій зберігається результат порівняння попереднього та текучого станів k-ї групи АК, тобто виявляються комплекти в яких відбулися будь які зміни; R4 – змінна аналогічна R3, тільки ігноруються заблоковані комплекти; R5 – кінцева змінна, за допомогою якої виявляють комплекти (в k-ій групі АК) від яких надійшли сигнали виклику. Контрольна точка абонентського шлейфу, яка розташована в ПІНН, також має два стійких стани, тому для них в ОЗП відведено теж один біт пам’яті, і відповідно для системи із 128 абонентів – 128 біт, чи 128/8=16 байт. Змінна SHLF[16] – відображає стани імпульсних ключів абонентських телефонних апаратів (Рис. 1.2), та відповідно стани КТ швидкодіючих реле, які в подальшому опитуватимуться з метою визначення дій з боку абонента, які направлені на набір номеру. Для зберігання попередніх станів дій активних абонентів передбачено запам’ятовування цих станів у відповідних комірках регістрів виклику, які виділяються абоненту (при наявності вільного), запит якого надійшов до системи для обслуговування. Змінна shlf_old зберігає цю інформацію. Для КТ абонентського шлейфу цікавість являє не тільки стан, але і моменти переходу та тривалість відповідних станів, що зумовлено стандартизованими часовими параметрами сигналу набору номера (Рис. 1.6), тому в РВ виділяються такі змінні (поля) в яких зберігатиметься кількість зафіксованих станів із високим (поле – n1) та низьким (поле – n0) станом. В подальшій обробці ці поля використовуються алгоритмами для безпомилкового визначення номеру. Значення цієї інформації є відносно прив’язане до часу так як алгоритми, які їх змінюють мають певний період запуску. Отже точність прив’язки до часу є рівним періоду запуску алгоритму, який слідкує за станом абонентського шлейфу. Дані про стан поведінки зовнішнього середовища. Згадувалося в розділі 2, що зовнішнім середовищем, яке діє на роботу керуючої системи є абоненти, кожен з яких характеризується сукупністю випадкових параметрів: - момент поступлення на обслуговування, тривалість обслуговування. Основним параметром зовнішнього середовища по відношенню до системи є навантаження, тобто інтенсивність потоку заявок, яке може мінятися в залежності від таких обставин, як: - святкові дні; - ранній чи вечірній періоди доби, це можна охарактеризувати одним словом – година найбільшого навантаження на систему (розділ 1). Щоб вміло імітувати всі ці процеси необхідно використати апарат зв’язаний з формуванням та перетворенням випадкових чисел. Вихідним матеріалом для створення любих випадкових об’єктів на ЕОМ служать так званні випадкові числа, які виробляються спеціальною програмою – датчиком випадкових чисел [9], [10]. Випадкові числа можна розглядати як можливі значення xi випадкової величини (, які базуються на рівномірному закону розподілу випадкових величин в інтервалі (0…1). Методи конструювання з цих випадкових чисел різних інших більш складніших об’єктів достатньо розвинуті на теперішній час і називається перетворенням випадкових чисел [9], [10] – детальніше про це говорилося в розділі 2. Якщо потрібно отримати можливі значення yi випадкової величини (, яка має функцію щільності f(y), виходячи із випадкового числа xi, що згенеровано за допомогою датчика випадкових чисел з рівномірним законом розподілу імовірності, в інтервалі 0…1, то необхідно рішити рівняння (3.1) відносно yi [9], [10]. (3.1) В розробленій імітаційній моделі реалізований випадковий потік однорідних подій за допомогою степеневого розподілу імовірностей (3.2), який доволі точно відображає активність абонентів, яка відбувається на реальних АТС. Отже, якщо: (3.2) тоді можливі значення: (3.3) Після цього, використовуючи відомості розділу 2, формуємо ряд моментів ti поступлення заявок: (3.4) де ( - можливі значення випадкових величин з заданим спільним законом розподілу імовірностей [9], [10]. Провівши дослідження поведінки абонентів, протягом розробки моделі, прийшли до ряду основних параметрів, якими можна охарактеризувати їх поведінку по відношенню до системи, а саме (для джерельного абонента): tAct – час початку активності абонента (відносно початку роботи моделі), який беручи цей параметр для всіх абонентів характеризує закон розподілу потоку однорідних подій; tBeg – час початку набору номера, реалізований за допомогою рівномірного закону розподілу імовірностей; tTalk – час розмови з абонентом призначення (рівномірний закон); tmaxwaitforNN – максимальний час очікування сигналу «Відповідь станції»; tcurwaitforNN – лічильник, текучий час очікування сигналу «Відповідь станції»; tmaxwaitforAnswerB – максимальний час очікування відповіді абонента призначення; tcurwaitforAnswerB – лічильник, текучий час очікування відповіді абонента призначення; tidp – міжцифровий час – час між сусідніми цифрами при набору номера (для різних абонентів може бути різний міжцифровий час); num[5] – номер, який набирає абонент; ключ level – рівень на якому знаходиться абонент: = 0 – абонент знаходиться в стані очікування сигналу «Відповідь станції»; = 1 – абонент отримав сигнал «Відповідь станції» і знаходиться на інтервалі набору номера; = 2 – очікування відповіді абонента призначення; = 3 – абонент вдало провів розмову. Ключі за допомогою яких модель повідомляє (впливає на) абонентів про свій стан ( розділ 2): act – активність абонента = 1 – активний, = 0 – пасивний; oktoNN – дозвіл набору номера (в певних випадках очікування). SHLF – лінійний номер АК до якого підключений абонент. Для абонента призначення параметри поведінки схожі на попередні, але не включають такі величини, які використовуються при набору номера. Розглянемо ці параметри поведінки детальніше: TAct – час початку активності абонента, визначає час зайнятості обслуговуючого каналу, рахуючи відносно моменту отримання сигналу «Виклику» до початку активності. Реалізований за допомогою рівномірного закону розподілу імовірності; tTalk – час розмови абонента; ключ level – рівень на якому знаходиться абонент; може приймати наступні значення: = 0 – абонент ще не отримав ніякого сигналу; = 1 – абоненту надходить сигнал «Посилка виклику»; система очікує відповідь цього абонента; = 2 – абонент відповів на сигнал виклику та знаходиться на інтервалі розмови з джерельним абонентом; = 3 – абонент вдало провів розмову та поставив мікротелефонну трубку; = 5 – гуманний абонент призначення; його поведінка залежить від того хто керує локальним телефонним апаратом. Ключі: oktoTalk – нульове значення свідчить про те, що абонент очікує встановлення розмовного тракту з джерельним абонентом; одиничне – дає дозвіл на запуск лічильника, який відраховує розмовний час; act – визначає активність абонента – ця змінна повідомляє абонента призначення про те, що надійшов дзвінок, тобто сигнал виклику. Черги, як засоби передачі сигналів між основними алгоритмами системи. В імітаційній моделі, як і в реальних системах АТС, узгодження роботи алгоритмів, які направлені на обслуговуваня багатьох абонентів, відбувається за допомогою черг чи буферів ( розділ 2), в яких знаходиться інформація необхідна для збереження логіки взаємодії цих алгоритмів. У випадку систем масового обслуговування, таких як автоматичні телефонні станції, в чергах достатньо зберігати інформацію про лінійний номер АК абонента, який знаходиться на одному з декількох етапів обслуговування, тобто є активний. Кожен етап має свою чергу в якій містяться номери АК, які обслуговуються даним етапом і при проходженні відповідного абонента через цей етап, переводиться на слідуючий етап. Згруповуючи алгоритми в етапи обслуговування і знаючи, що кожен етап має свою чергу, отримуємо кінцеву кількість черг необхідних для реалізації моделі. В таблиці 3.1 приведено перелік алгоритмів та їх відповідність до етапів обсуговування. Процес запису лінійних номерів АК в черги називається формуванням заявки для відповідного етапу обслуговування. Довжина черг залежить від розрахованої кількості абонентів в годину найбільшого навантаження. Опишемо призначення черг програмно-імітаційної моделі: unsigned char qi[MAX_AA] – черга на прийом та аналіз набору номера; заявки в цю черги формуються алгоритмом, що відноситься до етапу скануваня абонентів, при виявленні активних абонентів; unsigned char qf[MAX_AA] – черга заявок для яких необхідно проаналізувати наявність чи відсутність вільного з’єднувального шляху в комутаційному полі між відповідними абонентами; запис заявок в цю чергу проводиться алгоритмом аналізу номера; unsigned char qwc[][MAX_AA] – подвійна черга заявок за якими проводиться слідкування для виявлення моменту встановлення (чи не встановлення) розмовного тракту; заявки надходять з попереднього етапу обслуговування; unsigned char qwd[][MAX_AA] – в цій подвійній черзі знаходяться заявки зформовані також попереднім етапом (очікування з’єднання), за якими ведеться слідкування з метою виявлення закінчення розмови між абонентами. unsigned char qo[MAX_AA] – до тепер ми розглядали черги заявки з яких почергово передавалися з одного етапу на інший; але на відміну від попередньо розглянутих черг, формування заявок в чергу на відбій можливий з різних етапів і залежить від поведінки абонентів, а саме: з черги на прийом та аналіз набору номера – при виявленні неіснуючого напрямку чи зайнятості абонента призначення; з черги аналізу наявності вільного з’єднувального шляху – при неможливості встановлення з’єднання між абонентами по причині відсутності вільних з’єднувальних шляхів; з черги очікування роз’єднання – при виявленні, що о дна із розмовних сторін поставила мікротелефонну трубку. Таблиця 3.1 Перелік алгоритмів та черг, які вони використовують Реалізований алгоритм. Призначення алгоритму. Етап обслуговування. Реалізована черга та вказівник.
Scaner() Виявлення сигналів виклику від абонентів Сканування абонентів в черзі знаходяться всі абоненти
ConnectAnlz() Аналіз наявності вільного з’єднувального шляху Пошук та резервування вільного з’єднувального шляху qf[] – queue for find free connection way; fptr – free pointer
WaitConnect() Сканування станів абонентів для встановлення розмовного тракту між ними Очікування встановлення з’єднання між абонентами qwc[] – queue to wait for connection; wcptr – pointer
WaitDisconnect() Сканування станів абонентів з метою виявлення закінчення розмови Очікування роз’єднання абонентів qwd[] – queue to wait for disconnection wdptr – pointer
До кожної з приведених черг призначається вказівник (Таблиця 3.1) на останню в черзі заявку. За допомогою цього вказівника можна визначити скільки заявок знаходиться в тій чи іншій черзі. Якщо, наприклад, вказівник більше від нуля, тоді в черзі присутні заявки на обслуговування, а значення вказівника визначає кількість заявок. Щоб полегшити роботу з чергами при написанні студентами відповідних алгоритмів (див. додаток програмно-методичний комплекс) розроблено декілька функці й, перелік яких приведено нижче: addQueue(int Nshlf, char* q, char* ptr) – додати в чергу q з вказівником ptr лінійний номер абонента Nshlf; subQueue(int Nshlf, char* q, char* ptr) – відняти з черги q з вказівником ptr заявку (лінійний номер АК - Nshlf); addDBLQueue(char src_shlf, char dest_shlf, char q[][],char *ptr) – додати до подвійної черги q[][] абонентів з лінійними номерами АК – src_shlf, та dest_shlf; subDBLQueue(char src_shlf, char dest_shlf, char q[][],char *ptr) – додати до подвійної черги q[][] абонентів з лінійними номерами АК – src_shlf, та dest_shlf; Відображення комутаційного поля в пам’яті. В керуючих пристроях ЕАТС стан комутаційного поля адекватно відображається в ОЗП, де для кожної абонентської, проміжної та з’єднувальної лінії відводиться однорозрядна комірка з визначеним адресом, в яку записується інформація про стан відповідної лінії (вільна – 0 чи зайнята – 1). В реалізованій моделі за стани абонентської лінії відповідає змінна Rbusy[], яка відображає стан розділюючого реле АК (Рис. 1.2), що підключає лінію абонента до БАЛ. Ця змінна використовується також при визначенні вільності (чи зайнятості) абонента. Якщо розряд в змінній Rbusy[], за попередньо визначеним адресом, рівний 0, тоді абонент є зайнятий, якщо рівний 1 – то вільний. Структура проміжних ліній, які знаходяться в БАЛ, в реалізованій моделі виконана за допомогою методу об’єднання виходів 4-х груп (А) матричних з’єднувачів 8х8 – першої ланки, і під’єднанням 2-ї ланки з 8-ми матричних з’єднувачів 4х4, як показано на рисунку 3.2
Рис. 3.2 Структура блоку абонентських ліній. Блок абонентських ліній виконує роль концентрації навантаження, як видно з попереднього рисунку кількість проміжних ліній складає 32 із входячих 128 ліній. Це значить, що коефіцієнт блокувань в БАЛ дорівнює 25%. Структура БАЛ в моделі відображається при допомозі програмної структури: struct BAL { M88 B88[16]; M44 B44[8]; } де M88 – це визначення типу даних: typedef char M88[8][8]; M44 – це також: typedef char M44[4][4]; Отже запис M88 B88[16] – означає, що в ОЗП виділяється 16 двомірних масивів, кожен з яких має розмір 8х8 байт. Аналогічно для запису M44 B44[8]. Тобто зберігається адекватність програмної структури у відповідності до спроектованої (Рис. 3.2). Відповідність методу виконання з’єднань між першою та другою ланками враховується при написання алгоритму пошука вільного з’єднувального шляху. Структура програмно-імітаційного комплексу. Розробка основних алгоритмів керуючої системи імітаційної моделі. Алгоритм прийому сигналів виклику Scaner(). Сигнали виклику від абонентів визначаються за допомогою АК, які виділяються окремо для кожного з них. Стани АК зчитуються спеціальним периферійним пристроєм – абонентським опитувачем АО (Рис. 3.3), який містить схему зчитування станів групи із восьми АК. В імітаційній моделі керуючої системи, як і в реальних системах, існує алгоритм, який відповідає за сканування станів всіх АК використовуючи вищезгаданий АО – алгоритм називається Scaner(). Для визначення сигналів виклику, групи АК скануються з фіксованим періодом часу ( розділ 2).
Рис. 3.3 Абонентський опитувач та відображення станів АК в ОЗП. Звірку з описом дій алгоритму можна проводити користуючись блок-схемою, яка наведена на рисунку .
Рис. 3.4 Блок-схема алгоритму прийому сигналів виклику. Алгоритм Scaner() виконує наступні дії: формує індекс групи АК k за допомогою якої дістає слово стану АК R1[k], цієї групи від АО; з масиву попередніх станів АК в ОЗП R2[k] дістає інформацію про попередній стан тієї ж групи АК; зрівнює ці дві інформації (попередню та текучу) і аналізує результат; при наявності виклику: визначає координати АК з якого надійшов сигнал виклику, перевіряє на наявність вільного РВ, формує заявку на прийом номера, для цього записує лінійну адресу АК в чергу на обслуговування прийому набору номера qi[], включає сигнал «Відповідь станції», при відсутності РВ - включає сигнал «Зайнято», формує заявку на очікування відбою абонента, для цього записує лінійну адресу АК в чергу на відбій qo[]; після перевірки групи з восьми АК записує новий стан цих комплектів в масив попередніх станів АК в ОЗП – R2[k]=R1[k]. Ці дії виконуються до тих пір, поки не будуть опитані всі (16) групи АК. Алгоритм прийому номера. Алгоритм прийому номера залежить від типу номеронабирача, який визначає процес набору. У випадках тастатурного номеронабирача з частотним кодуванням інформації цифри номеру передаються одним двухчастотним імпульсом. В реалізованій імітаційній моделі інформація набору номера визначається при використанні абонентами дискового номеронабирача, параметри якого в моделі реалізовані за допомогою змінних значення яких наведені в табл. 3.2. Таблиця 3.2 Параметри дискових номеронабирачів абонентів моделі Назва змінної. Призначення. Значення. Умовна одиниця.
doz тривалість імпульса 4 мс*101
iip міжімпульсна пауза 6 мс*101
idp міжцифрова пауза min 30 мс*101
Алгоритм прийому номера від дискового номеронабирача складається з двох окремих самостійно функціонуючих частин, які мають різні призначення. Програмна реалізація першої частини алгоритму прийому номера називається getimp() і призначена для прийому та накопичення імпульсів набору і має фіксований період запуску 10 мс, що виключає можливість загублення хоча б одного імпульсу. Друга складова алгоритму називається getnum(), яка забезпечує виконання наступніх дій: визначення міжцифрового інтервалу; прийому та накопичення цифр набору номера; визначення кінця набору номера; визначення відбою абонента під час набору номера. Період запуску алгоритму 120 мс, що з гарантованим запасом перевищює період слідування імпульсів набору. Для роботи першої частини алгоритму необхідна інформація про стан абонентського шлейфу знімається шляхом опиту змінної SHLF[], який відображає стани кожного ІК телефонних апаратів (Рис. 1.5). Кількість зісканованих станів з високим і низьким рівнями (для полегшення будемо важати високий рівень за одиничку ‘1’, а низький рівень стану абонентського шлейфу за нуль ‘0’) та кількість виявлених імпульсів записуються у відповідні поля РВ (розділ 3.1.1), які виділяються за АК активних абонентів. Блок схема алгоритму прийняття та накопичення імпульсів getimp() приведена на рисунку 3.5. Після запуску алгоритма диспетчером, його робота починається з аналізу черги заявок на прийом номера. Заявки формуються вище згаданим алгоритмом прийому сигналів виклику Scaner(). Якщо заявки відсутні, тобто відсутні абоненти, які здійснюють набір, то алгоритм закінчує свою роботу переходом у вихідний стан. Якщо хоча б одна заявка присутня в черзі, то починає роботу головна частина алгоритму, яка заключається в наступному: по номеру АК визначається номер РВ, який закріплений за даним АК; формуються координати АК, (номер групи – g_abn, положення в групі – n_abn); опитуємо стан КТ АК, тобто зчитуємо значення із змінної (SHLF[]), яка імітує контрольну точку; використовуючи попередній стан КТ текучого АК (поле shlf_old в РВ) визначаємо тип переходу, а саме: якщо стан КТ без змін (shlf_old = shlf), тоді в залежності від рівня збільшуємо відповідно лічильник станів з рівнем 1 – n1, чи лічильник станів з рівнем 0 – n0; якщо відбувся перехід з 1 на 0, то при виявленні (за кількістю імпульсів та цифр), що це є початок набору відключаємо сигнал “Відповідь станції”, команду на включення якого дав алгоритм Scaner(); у випадку переходу з 0 на 1, фіксується виявлення імпульсів, при умові, що кількість зісканованих станів з низьким рівнем більше 3-х (інакше імпульс важається помилковим – дережання контакту). При цьому збільшується лічильник імпульсів (imp_cur); далі запамятовується новий стан абонентського шлейфу (shlf_old=shlf) і продовжується аналіз черги на наявність наступної заявки. Закінчується робота алгоритму після перегляду всієї черги на прийом номера.
Рис. 3.5 Блок-схема алгоритму прийому та накопичення імпульсів. Перейдемо до розгляду другої частини алгоритму прийома номера – getnum(). Його суть заключається в контролі станів кількості виявлених імпульсів у регістрі імпульсів – imp_cur, через кожні 120 мс. Якщо на протязі даного періоду часу виникли зміни в їх кількості, то це розглядається як продовження набору цифри номера. Якщо змін не виявлено, то важається, що настав міжцифровий інтервал. Для здійснення процедури визначення змін у кількості імпульсів, в РВ необхідно мати контрольний регістр імпульсів – imp_old – для зберігання попереднього стану кількості імпульсів. Період запуску алгоритма вибирається виходячи з умови гарантованого визначення міжцифрового інтервалу в найгіршому випадку моментів запуску алгоритма по відношенню до стану абонентського шлейфу, який перевіряється. Блок схема алгоритму визначення міжцифрового інтервала набору номера приведена на рис.3.6. Після запуску алгоритма диспетчером, його робота починається з аналізу черги заявок на прийом номера. Якщо заявки відсутні, тобто відсутні абоненти, які здійснюють набір, то алгоритм закінчує свою роботу переходом у вихідний стан. Якщо хоча б одна заявка присутня в черзі, то починає роботу головна частина алгоритму, яка заключається в наступному: по номеру АК визначається номер РВ, який закріплений за даним АК; формуються координати АК, (номер групи – g_abn, положення в групі – n_abn); у випадку виявлення високого рівня абонентського шлейфу визначається кількість накопичених імпульсів (imp_cur=0?), якщо рівна нулю – означає, що триває міжцифрова пауза; в протилежному випадку за допомогою порівняння кількості попередніх імпульсів з текучою їх кількістю визначається: міжцифрова пауза, при рівності порівняння значень (imp_cur=imp_old?); продовження набору номера, у протиленому випадку (imp_cur!=imp_old?); при виявленні міжцифрової паузи зберігається кількість накопичених імпульсів, як наступна цифра номеру (destin_number[numptr++]=imp_cur, numptr++), підготовлюються лічильники імпульсів до набору наступних значень, тобто обнулюються (imp_cur=imp_old=0); при виявленні інтервалу продовження набору номера зберігається нова кількість імпульсів (imp_old=imp_cur); у випадку низького рівня абонентського шлейфу (SHLF[g_abn]&m_abn=0), тобто запуск алгоритму попав на один зі проміжків чи низького стану за рахунок наступного імпульсу, чи за рахунок відбою абонента під час набору номера; вирішити це питання дає змогу стан лінійного реле: високий рівень ЛР (R1[g_abn]&m_abn!=0) свідчить про те, що алгоритм попав на імпульс набору номера; низький рівень ЛР (R1[g_abn]&m_abn=0) свідчить про відбій абонента під час набору номера; при цьому необхідно зняти абонента з черги на прийом набору номера, звільнити регістр виклику та відмітити абонента як вільний та доступний іншим абонентам системи. Закінчується робота алгоритму після перегляду всієї черги на прийом номера.
Рис. 3.6 Блок-схема алгоритму визначення міжцифрового інтервалу. Алгоритм аналізу номера. Алгоритм аналізу номера використовуєть для паралельного в часі, щодо алгоритмів етапу прийома номера, визначення кінця набору номера, напрямку виклику (внутрістанційний, зовністанційний чи екстремальний) та переводу абонента на наступний етап обслуговування із внесенням в регістр виклику, для подальшої обробки, необхідних значень. Блок схема алгоритму визначення міжцифрового інтервала набору номера приведена на рис.3.7. Після запуску алгоритма диспетчером, як уже звично, робота починається з аналізу черги заявок на прийом номера. Якщо заявки відсутні, тобто відсутні абоненти, які здійснюють набір, тоді алгоритм закінчує свою роботу переходом у вихідний стан. Якщо хоча б одна заявка присутня в черзі, то починає роботу головна частина алгоритму, яка заключається в наступному: по номеру АК визначається номер РВ, який закріплений за даним АК; якщо після аналізу кількості цифр визначено, що їх кількість достатня, тоді збільшується рівень обслуговування абонента (level) та визначається напрямок виклику (CREG[].direction), а саме: при неіснуючому напрямку (CREG[].direction=0), абонент повідомляється про це за допомогою включення йому сигналу “Зайнято”, звільнюється регістр виклику, який був призначений для цього абонента; абонент переводиться в чергу на відбій та знімається з черги на прийом наьору номера; при внутрістанційному напрямку виклику (CREG[].direction=3), визначається лінійний номер АК абонента призначення та координати (g_abn, n_abn) і за допомогою масиву Rbusy[], який відображає стани всіх абонентів (в пам’яті), визначається стан уже конткретного абонента призначення; при вільному стані джерельний абонент переводиться з етапу прийняття номера на етап пошуку вільного з’єднувального шляху в КП та його резервування; в протилежному випадку, коли абонент призначення зайнятий (розмова), чи заблокований – джерельний абонент повідомляється про це включенням сигналу “Зайнято” та виконанням тих самих функцій, які були описані у випадку неіснуючого напрямку. при зовністанційному (CREG[].direction=2), або екстримальному (CREG[].direction=1) напрямків виклику – джерельний абонент переводиться на наступний етап пошуку вільного з’єднувального шляху в КП у заданому напрямку. Закінчується робота алгоритму після перегляду всієї черги на прийом номера.
Рис. 3.7 Блок-схема алгоритму аналізу номера. В процесі аналізу номера дуже важливо, щоб обробка інформації, тобто визначення чи потрібно подальше накопичення додаткових цифр для здійснення повного аналізу номера, чи вже достатньо їх, здійснювався ефективно. Вимога до ефективності обробки ставиться за рахунок того, що алгоритми, які записані в ОЗП на станціях, повинні забезпечувати роботу в реальному масштабі часу. Ця вимога задовільняється використовуючи спеціальні пошукові таблиці – найкраща з яких є деревовидна пошукова таблиця. Графова модель деревовидної структури пошукової таблиці приведена на рисунку 3.8. Верхній вузол називають корнем, нижні вузли – термінальні елементи, які містять необхідну інформацію (в нашому конкретному випадку – шукану інформацію про напрямок виклику). Вершини дерева розташовуються по рівнях. Корінь має рівень 1, безпосередньо зв’язані з ним вершини 2 рівень і т. д. Максимальний рівень h мають термінальні елементи. Кожен вузол дерева, за виключенням, містять адреси зв’язаних з ними наступних вузлів утворюючи при цьому логічну послідовність кроків швидкого пошуку напрямку. В моделі реалізований пошук за допомогою пошукової таблиці розглянутої вище, яка названа TabOrDir[][]. Розглянемо коротко її функціонування (рис.3.9). Нехай під час прийому номера, для невизначеного абонента, виявлена перша цифра 2, тоді при запуску алгоритму аналізу номера (при ітерації для абонента від якого прийнято цифру 2), пошук починається з початку деревовидної структури, тобто з корневої таблиці (0). Цифра 2 для цієї таблиці є індексом, який вказує на елемент в ній. Елементи таблиць містять два типи значень інформації. Нехай за індексом 2 міститься значення +2 (TabOrDir[0][2]=+2). Перший тип значень інформації розміщений в знаковому розряді і визначає чи потрібно ще добір цифр номера для подальшого аналізу, чи ні. Додатній знак (+) означає, що ще потрібні додаткові цифри, при цьому значення вказує адресу наступного вузла в деревовидній структурі. Кількість цифр (один) вказує до якого рівня дійшов пошук. Від’ємний знак означає, що досягнутий термінальний елемент, при цьому значення визначає вже не адресу наступного вузла, а шуканий напрямок виклику (0, 1, 2, 3). В нашому випадку (TabOrDir[0][2]=+2) необхідний добір цифр, але вже відома адреса наступного вузла (2). Алгоритм аналізу номера закінчує роботу. Через деякий час виявлено наступну – другу цифру 5 набору номера. При запуску алгоритму аналізу номера пошук починається, як завжди з корня графу і продовжується до рівня два. Нехай на цьому рівні присутнє значення +3 (TabOrDir[2][5]=+3), що також визначає адресу наступного вузла (3) та необхідність у доборі додаткових цифр. Ще через деякий проміжок часу надійшла третя цифра – 9, яка при черговому запуску алгоритму аналізу номера дозволяє визначити необхідний напрямок виклику. В пошуковій графовидній таблиці значення за індексом 9 на третьому рівні є -3 (TabOrDir[3][9]=-3). Отже напрямок виклику рівний 3, що визначає внутрістанційний виклик.
Рис. 3.9 Функціонування пошукової таблиці при аналізу номера. Для полегшення написання алгоритму аналізу номера розроблено ряд функцій для пошуку в графовидній поуковій таблиці (int IsNumQttyOrDirOk(char qtty,char num[])) та для визначення координат АК абонента призначення (unsigned char getShlf_Num(unsigned char num[],int numptr)) за номером, що надійшов від джерельного абонента. Алгоритм очікування відбою абонента. Призначення алгоритму очікування відбою полягає в слідкуванні за станом КТ лінійного реле АК абонента, якому було відмовлено в подальшому обслуговуванні. Блок схема алгоритму очікування відбою приведена на рис.3.10. Після запуску алгоритма диспетчером, робота починається з аналізу заявок черги на відбій. Якщо заявки відсутні, тобто відсутні абоненти, за якими необхідно слідкувати, тоді алгоритм закінчує свою роботу переходом у вихідний стан. Якщо хоча б одна заявка присутня в черзі, то починається робота головної частини алгоритму, яка заключається в наступному: фомуються координати АК абонента, що вибув з обслуговування; тестується КТ лінійного реле, за станом якого і визначається чи абонент поставив мікротелефонну трубку (низький), чи ні (високий); при виявленні низького стану () виключається подача сигналу “Зайнято”; відмічається абонент вільним за допомогою змінної Rbusy[]; знімається абонент з текучої черги; при виявленні високого стану () алгоритм переходить до аналізу наступної в черзі заявки; Закінчується алгоритм після перегляду всієї черги заявок.
Рис. 3.10 Блок-схема алгоритму очікування відбою. Механізм імітації поведінки абонентів. За допомогою згенерованих параметрів джерельного абонента ( розділ 3.1.3) формується масив часової активності DIN [][DIN_LEN], для кожного абонента, структура якого наведена на рисунку 3.11. begD endD +30 - 4 + 6 - 4 + 6 - 4 + 6 +30 - 4 + 6 …
Поле даних Рис. 3.11 Масив часової активності одного абонента. Пояснимо значення відповідних полів в цій структурі (Рис. 3.11): begD – вказівник (відносна адреса) на текучу позицію зчитування даних в масиві; на початку запуску моделі містить відносну адресу початку даних; endD – вказівник (відносна адреса) на кінець даних в масиві; Поле даних – містить значення за допомогою яких визначається стан абонента в певний момент часу – знаковий розряд значення визначає один із двох можливих станів КТ абонентського комплекту: 1 – значить, що абонентський шлейф замкнутий; 0 – абонентський шлейф розімкнутий; значення біля знакового розряду визначає тривалість (в мс*10) відповідного стану (в наведеному на прикладі рисунку, показано фрагмент набору номера: 3-1… - тривалість імпульса рівне 40 мс, а міжімпульсної паузи – 60 мс). Цей масив (Рис. 3.11) використовується компонентою моделі, яка відноситься до зовнішнього середовища – апарат руху абонентами, який керує станом КТ абонентських комплектів та станом КТ швидкодіючих реле, які виділяються абонентам на час обслуговування. Назва алгоритму, що виконує функції апарату руху абонентами – Reader(). При кожному запуску цей алгоритм зчитуючи текуче значення масиву DIN[i][] для кожного абонента, починає діяти, відповідно до значення знакового розряду, на змінні SHLF[] та R1[] (на R1[] дія відбувається за допомогою проміжної змінної INERTION_DOWN, яка визначає необхідну інерційність ’утримання’ значення R1[] у відповідному стані), цим самим повідомляючи систему, як уже відомо, про наступні дії абонентів. Таким чином під час роботи алгоритму Reader() формується характер зміни КТ масивів R1[] та SHLF[], які можна представити за допомогою часової діаграми (Рис. 3.12).
Рис. 3.12 Характер зміни станів КТ для джерельного абонента. Опис змінних, які відповідають за стандартизовані часові параметри сигналу набору номера наведені в таблиці 3.2. Опис інших змінних, які приведені на рисунку 3.12 приведений в розділі 3.1.3 (Дані про стан поведінки зовнішнього середовища.). Цим самим алгоритмом Reader(), але зовсім по іншому принципу відбувається активація руху абонентів призначення. Для них не потрібно спеціального масиву, як масив DIN[][], так як вони можуть приймати тільки два стійких стани – мікротелефонна трубка піднята чи поставлена. Тому для абонентів призначення використовується механізм зміни стану за допомогою переходів з одного рівня на інший. Цей механізм можна описати наступним чином: ключ act = 0 – свідчить про те , що ще не надійшов сигнал «Посилка виклику» до абонента; act = 1, level = 1 – надійшов сигнал виклику; при цьому запускається лічильник t, який в подальшому зрівнюється з часом початку активності tAct; при досягненні лічильника t значення tAct модифікується значення R1[] та SHLF[], збільшується рівень абонента на level = 2, обнулюється лічильник t; level = 2 – система повинна була визначити (так як R1[] – змінив свій стан на високий), що абонент призначення готовий для проведення розмови; абонент очікує встановлення розмовного тракту з джерельним абонентом і тому лічильник часу розмови ще не запускається – керує запуском лічильника змінна oktoTalk, нульове значення якого забороняє запуск лічильника; при встановленні розмовного тракту (значення oktoTalk модифікується на одиничне протоколом впливу моделі на абонентів, що описаний в розділі 3.2.3) запускається лічильник t, який наразі виконуватиме функцію відліку розмовного часу; при отриманні сигналу «Зайнято», ключ level = 3 встановлює абонента на завершальну стадію розмови; коли лічильник t досягнув значення tTalk модифікуються змінні SHLF[] на низький стан імпульсного контакту в номеронабирачі, але змінна R1[] не міняється так як для неї необхідно забезпечити інерційність, тому вона модифікується на наступному рівні, підвищується рівень абонента level = 3 –завершальна стадія; обнуляється лічильник t; запускається лічильник t для відрахування значення змінної INERTION_DOWN, яка визначає тривалість утримання КТ, яка відображається в масиві R1[]; через визначений змінною INERTION_DOWN період модифікується відповідна комірка змінної R1[] на низький стан, що повинно повідомляти модель про покидання абонентом системи act = 0. Характер зміни станів R1[] та SHLF[] з боку абонента призначення можна представити у вигляді часової діаграми (Рис. 3.13).
Рис. 3.13 Характер зміни станів КТ для абонента призначення. Механізм сигналів повідомлення абонентів про стан імітаційної моделі. Як вже згадувалося в розділі 2.5.3, в моделі акустичні сигнали повідомлення, які діють на реальних АТС, замінені на ключі, які змінюють ‘поведінку’ модельованих абонентів. Отже в програмній моделі реалізована система алгоритмів, які відповідають певним сигналам щодо реальних станцій. Суть цих алгоритмів можна привести до наступного: - якщо в моделі виникає необхідність, під дією зміни станів КТ АК, включення певного сигналу, то запускається відповідаючий за цей сигнал алгоритм; - цей алгоритм в свою чергу, знаючи структуру ключів керування поведінкою абонентів, видає ключ необхідний для переведення (можна сказати повідомлення) абонента у стан сприйняття відповідного сигналу від моделі. Перелік системи алгоритмів сигналів повідомлень та їх опис приведено нижче, а програмну реалізацію цієї системи приведено в додатку. OnStatAnswer(int Nshlf) – сигнал «Відповідь станції», керує ключами: oktoNN = 1 – дозволяє продовжувати зчитування з масиву часової активності DIN[][], що веде за собою зміну стану відповідної комірки масиву SHLF[] в залежності до номеру, який набирає абонент; тобто продовжується стан відповідної КТ надходженням набору номера; level = 1 – (у вихідному стані level=0) переводить абонента з рівня очікування сигналу «Відповідь станції» на рівень набору номера; OffStatAnswer(int Nshlf) – виключення сигналу «Відповідь станції»; On SataBusy(int Nshlf) – включення сигналу «Зайнято» абоненту з лінійним номером АК = Nshlf; алгоритм примушує завершити дії джерельного абонента встановивши в масиві часової активності DIN[][] вказівник на текучий елемент begD меншим на 3 від вказівника на останній елемент в масиві endD (Рис. 3.11). При цьому абонент не зразу припиняє дії, а тільки через певний проміжок часу на протязі якого спостерігач моделі може бачити цей візуалізований сигнал у відповідному до абонента віконці ( розділ 2.5.3); OffStatBusy(int Nshlf) – виключає сигнал «Зайнято»; OnStatCtrlAndCall(int Ashlf, int Bshlf) – одночасно включає сигнали «Контроль посилки виклику» та «Виклик станції» джерельному абоненту та абоненту призначення відповідно, де Ashlf – лінійний номер АК джерельного абонента, а Bshlf – лінійний номер АК абонента призначення; видає наступні ключі: Для джерельного абонента: oktoNN=0 – забороняє зчитування з масиву часової активності DIN[][] наступного значення, що означає встановлення абонента в режим очіквання відповіді абонента призначення; level=2 – переводить абонента на той рівень на якому він відраховує час на протязі якого можливе очікування відповіді абонента призначення; якщо час очікування виходить за межі (max_waitforAnswerB), то абонент завершує сеанс; Для абонента призначення, якщо ключ answer=1 (тобто абонент відповідатиме): act=1 – запускає механізм активності абонента; починається відлік часу початку активності; на протязі цього часу спостерігач моделі може бачити дію сигналів «Контроль посилки виклику» та «Виклик станції», які відображаються у відповідних абонентам віконцях; опис подальших дій абонента дивіться у розділі 3.2.2; oktoTalk=0 – встановлює абонента в режим очікування встановлення розмовного тракту, після початку активності; level=1 – запускає лічильник, кінцеве значення якого визначає момент ’підняття трубки’ ( розділ 3.2.2); якщо ключ answer=0 – ніяких дій зі сторони механізму зміни поведінки абонента (Reader()) не передбачається, про що свідчить встановлення абонента на 5-й рівень (level=5); OffStatCtrlAndCall(int Ashlf, int Bshlf) – виключає подачу візуалізованих сигналів «Контроль посилки виклику» та «Виклик станції», керує наступними ключами: oktoNN=1 – дозволяє продовження зчитування значень з масиву часової активності DIN[][], залишкова довжина якого рівна часу розмови джерельного абонента; oktoTalk=1 – дозволяє запуск лічильника часу розмови абонента призначення. Використання цих алгоритмів на лабораторних роботах відбувається наступнім чином: - при написанні студентами одного агоритму елемента керуючої системи викатиме необхідність у включенні на певній стадії, наприклад, сигналу «Відповідь станції» - тоді в програмному описі студенту достатньо викликати алгоритм, який відповідає за цей сигнал, і визначити кому адресувати його (Nshlf, Ashlf, Bshlf); далі рахується, що абонент дістав відповідне повідомлення. Керівництво користувача імітаційної моделі керуючої системи. Програмний продукт призначений для вивчення та дослідження роботи керуючих систем електронних АТС малої ємностію. Для цього програма виконана у вигляді імітатора, який виконує основні функції, що працюють на реальних АТС, та імітує надходження викликів на станцію зі сторони абонентів, таким чином моделюючи зовнішне середовище АТС. Модель виконана в зручній та наглядній, для користувача, формі сприйняття подій, які виникають під час надання системою послуг абонентам. Всі події зі сторони зовнішнього середовища відображаються у віконці (рис. 3.14), у вигляді рухомої часової діаграми станів контрольних точок для кожного із абонентів, які стають активними під час роботи моделі. У віконці активного абонента відображаються такі характеристики, як лінійний номер АК до якого під’єднаний абонент; стани КТ лінійного реле та КТ стану абонентського шлейфу; набираємий абонентом номер у вигляді послідовності імпульсів. Максимальна кількість абонентів, які можуть бути активними за визначений період роботи моделі фіксована і рівна 12 при загальній ємності станції 128 абонентських ліній. Моменти надходження викликів описуються за допомогою нескладного математичного апарату, який реально характеризує залежність між сусідніми проміжками часу, тобто між викликами. Таким математичним апаратом являється закон, який описує розподіл імовірностей в залежності від параметру потоку (інтенсивності навантаження) – закон Пуассона. Крім моментів надходження викликів абоненти характеризуються рядом інших параметрів (час початку набору номера, час розмови, номер який набирає абонент, час очікування сигналу “Відповідь станції” та час очікування відповіді абонента призначення), які реалізовані за допомогою рівномірного закону розподілу імовірностей. Події зі сторони АТС відображаються за допомогою візуалізації значень регістрів виклику, які повно описують стан виклику на певний момент часу. По середині графічної оболонки моделі можна бачити вікно (рис. 3.15), в якому приведені значення основних змінних РВ для кожного активного абонента окремо, а саме: R – номер РВ; SHLF – лінійний номер абонентського шлейфу джерельного абонента; L – етап обслуговування, на якому знаходиться абонент; n0 – кількість станів з виявленим низьким рівнем абонентського шлейфу; imp – кількість виявлених імпульсів набору номера; NUM – виявлений телефнонний номер, який набирає джерельний абонент, тобто номер абонента призначення; shlf – визначений лінійний номер абонентського шлейфу абонента призначення; D – напрямок виклику.
Рис. 3.15 Інтерфейс моделі під час активної роботи. Відомо, що реальні АТС повідомляють абонентів про свій стан за допомогою акустичних сигналів, таких як «Відповідь станції», «Зайнято», «Посилка виклику», «Контроль посилки виклику» (розділ 1), але в моделі їх використовувати недоцільно. Тому вони замінені графічним відображенням їх для кожного абонента. Таким чином під час роботи моделі можна спостерігати вище наведені сигнали у вигляді надписів у відповідних віконцях абонентів, таких як: Answer – означає, що надійшов сигнал відповіді станції до абонента; неперервний сигнал світло зеленого кольору; Busy – сигнал зайнятості станії; перервний сигнал, світло зеленого та темно червоного кольору зі скважністю 2; CALL – сигнал виклику станції для абонента призначення; перервний сигнал , світло зеленого та темно червоно кольору зі скважністю 4; Ctrl – сигнал контролю виклику станції для джерельного абонента з параметрами аналогічними до попереднього сигналу. Як було згадано використовувати акустичні сигнали для сукупності абонентів недоцільно, але для одного абонента можна передбачити. Тому в модель вмонтована система підтримки телефонного апарату, який називається локальним абонентом. До функцій локального абонента входять надання таких послуг користувачу моделі, як можливість імітації телефонного апарату використовуючи клавіатуру. Отже використовуючи клавіатуру можна легко набрати любий необхідний телефонний номер під час роботи моделі, для безпосереднього дослідження системи в любих можливих умовах. Розроблена імітаційна модель орієнтована для навчального процесу студентів. Під час вивчення дисципліни “Основи керуючих систем мереж зв’язку” студенти повинні виконувати лабораторні роботи на яких вони повинні розробляти алгоритми, які вже реалізовані (створена бібліотека основних алгоритмів) та працюють в моделі, та замінювати стандартні бібліотечні алгоритми своїми. Виконуючи процедуру заміни алгоритмів, постає питання їх відлагодження та спостереження за результатами отриманих значень. З цією метою в модель вмонтовані ряд сервісних послуг, які полегшують відлагодження розроблених студентами алгоритмів. Сервісні послуги розроблені у вигляді вікон на яких виводяться основні значення необхідні для коректної роботи керуючої системи. Перерахуємо ці послуги: трасування розроблених алгоритмів; можливість виводу сервісної послуги окремо для кожного алгоритму; вивід на екран попередніх та текучих значень системних змінних, які використовуються у вибраному для трасування алгоритмі (попередні значення виводяться червоним, а текучі значення жовтим кольором). Ці послуги моделі можна викликати за допомогою клавіатури (детальніше про функції клавіатури можна отримати при натисканні кнопки F1 - допомога). Імітаційну модель можна також використовувати для дослідження роботи керуючої системи в різних ситуаціях, наприклад, в годину найбільшого навантаження на систему, чи зменшенні, або збільшенні кількості обслуговуючого обладнання. 3. РОЗРОБКА ПРОГРАМНО-МЕТОДИЧНОГО КОМПЛЕКСУ ДЛЯ ДОСЛІДЖЕННЯ РОБОТИ ОСНОВНИХ АЛГОРИТМІВ КЕРУЮЧИХ СИСТЕМ ЕАТС. 31 3.1. Структура даних комплексу. 31 3.1.1. Регістри виклику, призначення та його склад. 31 3.1.2. Дані про стан абонентських комплектів. 32 3.1.3. Дані про стан поведінки зовнішнього середовища. 34 3.1.4. Черги, як засоби передачі сигналів між основними алгоритмами системи. 37 3.1.5. Відображення комутаційного поля в пам’яті. 39 3.2. Структура програмно-імітаційного комплексу. 40 3.2.1. Розробка основних алгоритмів керуючої системи імітаційної моделі. 40 3.2.2. Механізм імітації поведінки абонентів. 51 3.2.3. Механізм сигналів повідомлення абонентів про стан імітаційної моделі. 54 3.3. Керівництво користувача імітаційної моделі керуючої системи. 55
