А   Б  В  Г  Д  Е  Є  Ж  З  І  Ї  Й  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Ю  Я 


Програмна зв'язок

Програмна зв'язок з апаратурою нижнього рівня (датчиками, виконавчими пристроями) відбувається через драйвери.

Програмна зв'язок зводиться до установки узгоджених завдань регуляторам співвідношення потоків в зміцнює і вичерпної ССКЦЕІ колони. Інакше кажучи, замість пристосування САР до постійно змінюваних крайовим умовам, крайові умови пристосовуються до умов, закладених в САР.

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

Разом з тим, з'ясувалося, що для самонастроювання САР вона повинна обов'язково містити програмну зв'язок: склад (температура) харчування - співвідношення взаємодіючих потоків.

Для роботи з ПУС потрібно з боку центральної ЕОМ спеціальний варіант методу доступу ОТМД, що забезпечує відповідну програмну зв'язок з ПУС. Робота в частковому режимі полягає в одночасному виконанні в ПТД функцій ПУС і ЕП (так званих ЧЕП), при цьому можлива одночасна робота з методом доступу ОТМД ПУС і БТМД.

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

Контролер К5 є адаптер зв'язку, що забезпечує організацію програмно-керованої передачі 16-розрядних даних між ЗОШ та периферійним пристроєм. Він може бути використаний також в якості засобу межпроцессорной програмної зв'язку, що дозволяє двом процесорам різних комплексів СМ ЕОМ обмінюватися необхідними даними.

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

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

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

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