8.3.9. Чому “в Cache’-технології”?

Насправді перша реалізація qWord з’явилася більше двадцяти років тому, але мала з Cache’ спільних “прапредків” і “спільне| місце існування” – ідеї, методології, засоби програмної реалізації і додаток.

Не дозвільним представляється питання, чому qWord реалізується в Cache’-технології, а не в якій-небудь інший.

Відповідь украй повчальна з практичної точки зору.

Не тому, що в програмній реалізації Cache’-технології було щось, а тому, що не було нічого зайвого! Тільки один, але ретельно розроблений механізм В*-дерев і один тип даних – символьний рядок, а всі до єдиного обмеження як логічні, так і реалізаційні поставлені явно і однозначно.

Звичайно, до цієї сокири довелося додати і мистецтво і інтуїцію Конструктора – і варево, нарешті, вдалося.

Зараз, коли в основному і теорія завершена, і досвід накопичений, ми можемо стверджувати: все що можна в Cache’-технології можливе і в інших технологіях, але тільки якщо Конструктор Системи зуміє подолати всі капкани і пастки, побудова яких є невід’ємною частиною “багатших мов”.

Якщо у когось є бажання долати труднощі – долайте. Вийде (при успіху такої боротьби) може бути і краще в якихось аспектах, а, загалом, те ж саме, але дуже і дуже навіть не дешево. Тепер, повертаючись до першого підходу, можна відповісти на питання, чим Cache’-технологія краща за яку-небудь іншу для роботи з відкритими (тобто реальними) системами? Ось цією самою відсутністю необхідності долати труднощі і краща. Зокрема.

Поняття основної об’єднаної тріади, динамічно розкриваного об’єкта і сам хід реалізації повністю відкритих систем типу qWord однозначно ведуть до розуміння – системи цього класу за своєю суттю мультиоб’єктні і мультипроцесні, та ще, додатково, і з “плаваючими ієрархіями”. Значить, і будувати їх треба відповідними засобами.

“Розкриття” інструментальної суті ІС дозволяє будувати системи, здатні “вижити” і успішно працювати у дуже динамічній проблемній галузі. Є сенс розповсюдити цей підхід і далі – у бік структури операційних систем і команд. Або ще далі – в галузь апаратних засобів, що приведе нас до концепції “Вертикальної машини” (див. р.14), трохи схожої на те, що пропонують “нейрокомп’ютерщики”, але що суттєво відрізняється тим, що її реально можна побудувати доступними засобами.

8.4. Третій підхід. Спеціалізована виробнича операційна система

Наприкінці 70-х початку 80-х років на тій же основі і “в одній школі” з qWord була почата розробка прикладної системи Текрам [6,7] із розряду “дуже великих систем” {114. Розробка ґрунтувалася на використанні мало відомої тоді ОС MUMPS – попередниці нинішньої Cache’-технології. З погляду реалізації це був ризикований, але такий, що позитивно завершився експеримент – проектування крупної інформаційної системи на базі тоді “теорії відкритих систем”, що ще не сформувалася, в умовах формування самій цій теорії в процесі створення системи.}. Це твердження справедливе, якщо узяти в розрахунок унікальну динаміку предметної галузі – конструкторсько-технологічна підготовка виробництва найбільшого підприємства, що виготовляє поодинокі примірники продукції вищого рівня складності і технології.

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

Все це привело до несподіваного ефекту – система виявилася настільки відкритою, що без яких-небудь зусиль всмоктувала в себе будь-які CAD-CAM комплекси, що спочатку не передбачалося і, здавалося б, для таких систем “не належить”. Навіть одна живучість і пристосовність цього підходу повинні і зараз наводити на цікаві роздуми.

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

Інформаційно - допоміжні документи (зокрема – креслення) були винесені в другу чергу автоматизації. Зрозуміло, що це відбулося тому, що організаційно - первинна інформація (специфікації, технологічні маршрутні карти) і похідні із неї відомості (вторинні, зведені документи) є суттєво важливішими для організації першого етапу

Рис. 8.2. Структурна схема організації основ інтелектуального керування в автоматизованій виробничій системі

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

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

• інформація про плановані роботи (портфель замовлень);

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

• інформація про використовувані матеріали і покупні вироби;

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

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

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

Як випливає з теорії, необхідною умовою рішення цієї задачі є така організація робіт, при якій комплексна система не лише забезпечує інструментальну можливість проведення робіт, передачу і зберігання інформації, але і розуміє її, проводить не лише синтаксичний, але і семантичний контроль першого і другого рівня. Тільки в цьому випадку об’єднання підсистем могло бути проведене на рівні обміну “інформацією, а не даними” {115. Вираз “обмін інформацією, а не даними” багато років використовувався практиками як твердження про вищий ступінь аналізу повідомлення, збереження його семантичної начинки. Звичайно, без скільки-небудь конструктивного визначення інформації придумати що-небудь зрозуміліше було просто неможливо. Ми розглядаємо це питання в частині III.}.

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

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

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

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

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

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

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

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

• видачу і облік номерів документів, що розробляються, за класифікатором ЄСКД із збереженням необхідного обсягу відомостей про всі розроблені документи і забезпеченням ведення власне класифікатора ЄСКД;

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

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

• нормоконтроль виконаних документів відповідно до приписів на роботу служби нормоконтролю;

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

• облік фактичної трудомісткості всіх видів виконуваних робіт для створення нормативної бази чи корекції тієї, що наявна;

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

Спроектована СРВОС виконувала цілий ряд функцій, які можна розділити на функції організації ведення власне робіт і інформаційної бази на робочих місцях користувачів Текрам (так звані зовнішні функції) і функції підтримки працездатності самого комплексу (так звані внутрішні функції).

СРВОС була реалізована так, щоби зовнішні функції виконувалися за участю користувачів із застосуванням різних форм діалогу (людина включена до складу підсистем як необхідний виконавський елемент), а внутрішні функції виконувалися з мінімальною участю користувачів, аж до автоматичної роботи системи в межах згенерованої конфігурації технічних засобів і необхідних можливостей за умови забезпечення керованості всіх процедур від програмного адміністратора Текрама (людина виключена з управління – фактичний “управитель” план і портфель замовлень).

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

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

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

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

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

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

• бібліотечні програми реалізують універсальні алгоритми проектування і послідовностей, що часто повторюються, еквівалентні підпрограмам чи макросам і зберігаються в БД тривалий час.

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

На етапі генерації системи при встановленні взаємозв’язків всіх підсистем виконувалася статична настройка.

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

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

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

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

Внутрішні функції СРВОС можна подати у вигляді основних класів завдань:

• забезпечення роботи комп’ютерів і обчислювальної мережі комплексу Текрам;

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

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

• власне управління як вироблення інформації, що управляє.

Підкреслимо, що як прообраз системи з ІСУ, Текрам зовсім не був орієнтований на рішення повної задачі автоматичного управління. Проте, на його основі були отримані (як би “автоматично”, просто за рахунок дотримання “незамкненості” його підсистем) всі необхідні рішення для створення ІСУ об’єктами класу “суспільного інституту”.

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

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

“Смертельною” обставиною для Текрама стала його зупинка за обставинами “перебудовного характеру”. Системи такого рівня зупиняти “в отриманні інформаційного забезпечення робіт із зовнішнього світу неможливо” – вони негайно закінчують цикл свого існування.

На закінчення “повісті про Текрам”, серед множини його особливостей відзначимо ще одну – унікальну, як з’ясувалося в процесі експлуатації, пристосовність до змін проблемного середовища здатність до самовдосконалення {116. Як показав досвід, пристосуватися не можна тільки при припиненні потреби в системі (при припиненні процесу інформаційного обміну), оскільки це відбулося із Текрамом під час перебудови – не зміна економічної формації страшна, а розвал економіки. І це однаково погано для всіх інтелектуальних систем усіх рівнів, і навіть для таких, як Текрам, що тільки наближаються до інтелектуальності.}. Але зробимо це вже стосовно узагальненого поняття ІСУ, просто використовуючи досвід експерименту зі створення системи Текрам.