Одна з найважливіших проблем, що виникають в АСУ ТП, при автоматизації вимірів та інших областях, полягає у різкому збільшенні вартості системи зі зростанням її складності. Об'єктивна причина цього явища полягає в тому, що складні системи часто виготовляються в поодиноких екземплярах, а це не дозволяє зробити їх дешевими.
Поширений метод вирішення зазначеної проблемиполягає в розподілі системи на модулітаким чином, щоб кожен з них ставав комерційно ефективним виробом і міг виготовлятися кількома виробниками, що конкурують, у великих кількостях. Однак при цьому виникає проблема апаратної та програмної сумісностімодулів. Для досягнення сумісності інтерфейс, конструктив та функції таких модулів, що виконуються, повинні бути стандартизовані.
Відкритоюназивається модульна система, яка допускає заміну будь-якого модуля на аналогічний модуль іншого виробника, наявний у вільному продажуза конкурентними цінами, а інтеграція системи з іншими системами (зокрема з користувачем) виконується без подолання надмірних проблем. Поняття відкритості обговорюється на веб-сайтах OMAC ( Open Modular Architecture Controls, www.omac.org), і на роботах [Helei , Business - Wang ].
Масштабованість (нарощуваність)
Масштабованість дозволяє застосовувати одні й самі апаратні і програмні засоби як великих, так малих систем у межах однієї організації. Прикладом масштабованих програмних систем є сучасні SCADA-пакети TraceMode і MasterSCADA, які продаються як єдиний пакет, але має градації в залежності від кількості тегів.
До появи відкритих систем забезпечення масштабування досягалося шляхом проектування системи з великим запасом за габаритами, кількістю слотів, інтерфейсів. Наращиваемость відкритої системи передбачає інший шлях, який вимагає запасу ресурсів (і пов'язаних із нею надлишкових фінансових вливань). Зокрема, система, що має властивість платформної незалежності та інтероперабельності, вже є розширюваною, оскільки вона дозволяє додавати нове обладнання або замінювати старе новими модифікаціями, в тому числі обладнанням інших виробників.
Стандартність інтерфейсу користувача
Відкриті системи повинні мати стандартний інтерфейс користувача, щоб виконати вимогу про можливість інтеграції з іншими системами (у даному випадкупід "іншою системою" розуміється людина). Стандартизація інтерфейсу користувача знімає необхідність навчання операторів при переході від однієї відкритої системи до іншої.
1.3.2. Засоби досягнення відкритості
Для забезпечення можливості побудови відкритих систем ринок має бути наповнений програмними та апаратними засобами, які є взаємозамінними, виробляються незалежними підприємствами та задовольняють вимоги загальноприйнятих стандартів. Нижче ми коротко опишемо такі продукти.
Промислові мережі та протоколи
Найбільш поширеними в Росії є мережі Modbus, Profibus, CAN, Ethernet. Обладнання, сумісне з ними, випускається сотнями конкуруючих підприємств у різних країнах світу, що забезпечує відсутність монопольних цін.
Інтерфейси
Найбільша частина засобів промислової автоматизації, представлених на Російському ринку, має інтерфейси RS-232, RS-485, RS-422, CAN, Ethernet, USB. Велике значення для підвищення ступеня відкритості мають перетворювачі інтерфейсів та міжмережевих шлюзів, які дозволяють об'єднувати в єдину систему несумісне за інтерфейсами та протоколами обладнання.
Програмні інтерфейси
Для взаємодії відкритих систем на програмному рівні найбільшого поширення набула DCOM-технологія фірми Microsoft, втілена в промисловий стандарт OPC (OLE for Process Control) [Iwanitz], який прийшов на зміну застарілій технології DDE (Dynamic Data Exchange). Стандарт ОРС забезпечив можливість застосування обладнання різних виробників практично з будь-якими SCADA, що є на ринку, оскільки більшість із них підтримує стандарт OPC.
Аналогічна задача може бути вирішена також за допомогою технології Jini фірми SUN та CORBAфірми OMG[Feldmann], однак втілення в міжнародний стандарт OPC отримала лише технологія DCOM, орієнтована на Windows-платформи (докладніше див. "OPC-сервер").
Інтерфейс користувача
Інтерфейс між SCADA та користувачем в даний час виконується приблизно одними й тими ж візуальними засобами, які стали стандартом де-факто: кнопки пуск/стоп, цифрове табло, лінійний або радіальний індикатор рівня, колірна сигналізація, вікна з текстовими повідомленнями, вікна введення даних, графіки тощо. Такий інтерфейс легко засвоюється операторами АСУ ТП.
Програмування контролерів підтримується трьома міжнародними стандартами: стандартом МЕК 61131-3 [Lewis] на мови програмування та стандартами МЕК 61499 [First Edition, 2005-01. - International Electro...">International , Гулько ] та МЕК 61804 на функціональні блоки. Стандарти підтримуються більшістю виробників програмного забезпечення. Прикладом можуть бути системи ISaGRAF фірми ICS Triplex та CoDeSys фірми 3S. Підтримку відкритості забезпечують також конвертори блоків UML(Unifid Modeling Language [Буч]) у функціональні блоки стандарту IEC 61499, а також UML у XML (eXtended Markup Language).
В останні роки з'явилося багато SCADA систем, які підтримують веб-технологію, коли користувальницький інтерфейс SCADA виконується у вигляді веб-сторінки та розташовується на сервері локальної мережі. При цьому будь-який користувач, який має достатні права доступу, за допомогою стандартного веб-браузера (наприклад, Internet Explorer) може керувати технологічним процесом. Такий підхід є значним прогресом у напрямку відкритості пакетів SCADA, оскільки надає користувачеві широкий вибір добре валідованих веб-браузерів за досить низькою ціною і забезпечує застосування практично будь-якої апаратно-програмної платформи для спілкування зі SCADA.
Програмна сумісність
Важливим достоїнством пакетів SCADA, що підвищує ступінь їх відкритості, є зв'язок з програмами Microsoft Office(Word, Excel, Access), яка знижує витрати на навчання персоналу та розширює можливості подання та обробки результатів вимірювань.
Сумісність баз даних із SCADA забезпечує широко поширену мову запитів SQL , що відповідає міжнародному стандарту і підтримується кількома СУБД (системами управління базами даних), наприклад, Informix, Sybase, Ingres, MS SQL Server. Інтерфейс ODBC(Open Data Base Connectivity ) дозволяє підключати до однієї SCADA різні СУБД, що підвищує ступінь її відкритості.
Забезпечення в деяких пакетах SCADA можливості програмування мовою Visual Basic, а також можливість вбудовування ActiveX та COM об'єктів сторонніх виробників дозволяє адаптувати SCADA до апаратури, що не підтримує стандарт ОРС, а також застосувати принцип повторного використання програмного коду, написаного для інших програм.
1.3.3. Гідності й недоліки
Основною перевагою систем з відкритою архітектурою є низька вартість їх життєвого циклу[Business]. Життєвий цикл АСУ ТП складається з наступних фаз:
- розробка концепції та ескізне проектування;
- проектування та виготовлення системи;
- монтаж та пуско-налагодження;
- експлуатація системи;
- обслуговування;
- реконфігурація, модернізація, розбирання, утилізація.
[White paper version 1.0. - Users ...">Business ] докладно розглянуто вартість кожного з перерахованих етапів.
Вигодою від застосування відкритих систем є:
- знижені вкладення проектування системи та передпроектні дослідження - завдяки наявності над ринком великого вибору готових компонентів відкритих систем. Особливо великий економічний ефект досягається під час створення великих систем у поодиноких екземплярах. І тут економія пропорційна розміру системи;
- спрощення процесу інтеграції - відкритість має на увазі можливість простої інтеграції різнорідних систем;
- економія фінансових коштів - завдяки низькій вартості життєвого циклу (переважно внаслідок конкуренції незалежних виробників та відсутності диктату цін монопольним постачальником);
- збільшений час безвідмовної роботи - завдяки вибору найбільш надійних модулів із наявних на ринку;
- мінімізований час вимушеного простою – завдяки великому вибору взаємозамінних модулів завжди можна знайти постачальника, що має потрібні модулі на складі;
- мінімальні зусилля на введення в дію як апаратури, так і програмного забезпечення завдяки усуненню часу на додаткове навчання як монтажної організації, так і експлуатуючого персоналу;
- проста зміна конфігурації системи для роботи з новими технологічними процесами - випливає з властивостей модульності та розширюваності відкритих систем;
- мінімальний обсяг додаткового навчання персоналу та, як наслідок, простота обслуговування;
- застосування новітніх технологійта технічних рішень - завдяки широкому вибору найкращих рішеньта спеціалізації виробників;
- збільшення часу життя системи - завдяки взаємозамінності відпрацьованого ресурсу та нового обладнання, а також можливості нарощування функціональних можливостей.
У роботі [Pizzica] описані конкретні переваги, отримані під час створення відкритої системи для тестування військового авіаційного обладнання:
- зниження вартості розробки та виготовлення системи. Економія при цьому можна порівняти з економією в серійному виробництві;
- зменшення термінів створення системи завдяки застосуванню наявних у продажу компонентів;
- зменшення ризику отримання системи, що не задовольняє технічним завданням, оскільки великий вибір сумісних між собою виробів, що у продажу, завжди дозволяє підібрати компоненти з потрібними характеристиками.
До появи компонентів відкритих систем створення такого обладнання вимагало розробки спеціалізованих друкованих плат, що було надмірно дорого та довго. Крім того, деякі необхідні функції при цьому не могли бути реалізовані ніколи через жорсткі обмеження на терміни створення системи.
Недоліки відкритих системвидно не відразу. І все-таки вони є:
- при створенні автоматизованої системина базі відкритих рішеньвідповідальність за працездатність системи загалом лягає на системного інтегратора, а чи не на виробника системи. Тому при появі в системі невідтворюваних відмов немає кому пред'явити претензії, оскільки постачальників багато, а системний інтеграторвідповідає тільки за монтаж та пусконалагодження системи;
- універсальність завжди перебуває у суперечності з простотою. Універсальні протоколи, інтерфейси, мережі та програмне забезпечення, щоб бути універсальними, мають бути досить складними, отже, дорогими та ненадійними. Хоча зниження надійності, викликане складністю, компенсується підвищенням надійності завдяки великому тиражу і, отже, продовженням налагодження після початку продажу;
- ефект зниження надійності програмного забезпечення, частини якого пишуться різними виробниками Коли ПЗ пишеться всередині однієї фірми, можна передбачити майже всі ситуації, які можуть виникнути на межі між ПЗ та користувачем або апаратурою. Якщо ж у цьому беруть участь кілька різних команд у різних фірмах, між якими немає взаємодії, стає незрозуміло, хто відповідає за надійність всього комплексу. Крім того, зі зростанням кількості програмістів, що беруть участь у створенні програмного забезпечення, за законами статистики збільшується ймовірність того, що з'явиться хоча б один програміст, який не вміє писати надійні програми. А цього достатньо, щоби зробити всю систему ненадійною. Надійність та безпека відкритих систем залишаються темами, що потребують вирішення [Wang];
- іноді до ознак відкритості відносять відкритість вихідних кодів. Однак наявність відкритих кодів знижує надійність програмної системи, оскільки порушується принцип інкапсуляції, необхідність якого обґрунтована в ідеології об'єктно-орієнтованого програмування;
- як і будь-яка стандартизація, відкритість накладає обмеження на діапазон можливих технічних рішень, ускладнюючи творчість та знижуючи ймовірність появи нових та плідних технічних рішень.
Зазначимо, що проблема надійності належить не всім компонентам відкритих систем. Наприклад, такі компоненти, як бази даних, комп'ютери або мережі Ethernet, мають високу надійність завдяки величезному тиражу і, як наслідок, якісній цих компонентів та оптимізації процесів виготовлення. Крім того, вище перераховані лише фактори, що знижують надійність відкритих систем. Однак одночасно є фактори, що її підвищують - це збільшений тираж модулів відкритих систем порівняно з низьким тиражем повністю замовних систем. Тому висновок про надійність відкритої системи може бути як позитивним, і негативним, залежно від конкретного складу її елементів.
1.4. Висновок до глави "Архітектура автоматизованих систем"
Синтез архітектури є відповідальним етапом, у якому закладаються основні властивості майбутньої системи. Тому архітектор повинен однаково добре знати як об'єкт автоматизації, так і технічні та програмні засоби автоматизації.
Найбільшого поширення в АСУ ТП набули розподілені системи, елементи яких (контролери, модулі введення-виводу) рознесені у просторі, незалежні друг від друга, але взаємодіють між собою виконання загального завдання. Система зазвичай має кілька рівнів ієрархії, які різняться типами промислових мереж, технічними засобамиі навколо розв'язуваних завдань. Перспективною тенденцією є застосування інтернет та інтранет технологій, які забезпечують можливість побудови глобальних систем, коли відстань перестає мати значення, а для роботи із системою використовується будь-який інтернет-браузер.
В останнє десятиліття на ринку засобів автоматизації переважають відкриті модульні системи, які відповідають загальновизнаним стандартам і складаються з компонентів, що випускаються серійно декількома конкуруючими виробниками.
Огляд публікацій
У роботі [Basso] описана добре випробувана технологія для керування в реальному часі через інтернет на основі Linux-сервера. Компоненти системи, що знаходяться на сервері, надають свої властивості та методи клієнтам через інтернет, використовуючи віддалений виклик процедур та мову XML. У [Groza] запропонована архітектура розподіленої системи управління, заснована на інтернеті та Java. У [Kapsalis,]. Запропоновано відкриту архітектуру інтелектуального датчика, з ідеологією "Plug&Play", засновану на інтернет-технології. Такий датчик може працювати з будь-якою апаратно-програмною платформою. У [Neag] описана відкрита архітектура комерційної системи автоматизованого тестування та діагностики складної апаратури. Система здатна до розширення шляхом застосування апаратури інших виробників: блоків діагностики, обладнання для виконання тестів, обладнання для відображення інформації, систем накопичення результатів тестування та ін. функціональні блоки для забезпечення інтероперабельності підсистем.
Ти балда, Коломбе, - скажу по честі. Щодо мене, то я б особисто – я б Америку закрив, злегка почистив, а потім знову відкрив – вдруге. В.В. Маяковський "Христофор Коломб" (ПСС у 13-ти т., т. 7, с. 38)Що таке "відкриті системи", кожен, зрозуміло, розуміє по-своєму. Проте багато хто погодиться, що однією з проголошених цілей цього напряму було приборкання гетерогенності як апаратної, так і програмної. Тут отримані найпомітніші результати, дозволили, наприклад, вирішити у досить загальної постановці завдання організації розподілених обчислень у неоднорідному середовищі. Проте загальне захоплення гетерогенністю має і зворотний бік: довгий часзалишилися без належної уваги однорідні програмні конструкції, хоча саме вони є відправною точкою для подальшого просування у бік відкритості.
Головне, а можливо і єдине відоме сьогодні засіб "відкриття" систем - це стандартизація. Оформлені відповідно до вимог стандартів матеріали набувають необхідного запасу однорідності, що дозволяє вільно маніпулювати ними, успішно долаючи ворожу гетерогенність середовища. Іншими словами, гетерогенні системи відкриті рівно настільки, наскільки вони гомогенізовані.
Але уявімо, що всі цікаві для нас програмні компоненти успішно стандартизовані, і спробуємо простежити їх подальшу долю. Перш за все, кожен новий однорідний компонент повинен бути "прийнятий на роботу" операційною системою або системою програмування. І на цьому кроці, коли, здавалося б, всі труднощі позаду, виникають досить серйозні проблеми.
Відкритість операційної системи
Візьмемо, наприклад, поширену операційну систему MS DOS та її оболонку Windows 3.11, і спробуємо проаналізувати, як там поставлено справу в частині підключення та відключення додатків. Інакше кажучи, очевидно розширимо тлумачення відкритості системи, включивши в нього також легкість переміщення програми в обох напрямках: нехай тепер відкрита система повинна забезпечувати і свободу додавання нових додатків, і свободу виключення існуючих. Виявляється, що з таким кутом зору аналізовані системи виглядають недостатньо відкритими; більше, справи тут з рук геть погано.
Якщо в організації процедури додавання (інсталяції) додатки ще можна не розглянути певних недоробок, то деінсталяція буквально кричить. Кожен, кому випало хоч раз викорінювати глибоко засів у незліченних системних файлах(config.sys, autoexec.bat, win.ini, system.ini, ...) додаток, не може без тремтіння згадувати про ці кілька болісних годинника свого програмістського буття. Найприкріше, що ця боротьба, як правило, приречена на безславну поразку: зазвичай так і не вдається повністю виявити і знищити всі гаки, якими складний додаток зчепився з операційною системою.
Проблему цю давно помічено. В результаті багато додатків, що інсталюються в MS Windows, постають тепер перед поглядом здивованого користувача у вигляді двох іконок: одна для постійного використання, що обслуговує повсякденне звернення до додатка, та інша - одноразова, для його деінсталяції. Якщо спеціальної процедури деінсталяції в деякому додатку не передбачено, на допомогу можуть прийти універсальні деінсталятори - неймовірно складні програми, за створення яких, схоже, незабаром почнуть присуджувати премії Тьюринга.
У той самий час, уважніше придивившись до організації господарства DOS і Windows, виявляєш, що існує тривіальний вихід із становища. Досить трохи ускладнити апарат роботи з файлами, ввівши файл спеціального типу – паспорт програми. У цьому файлі програма розміщує всю цікаву для операційної системи інформацію. При своєму перезавантаженні, а також при появі на постійному диску нових файлів-паспортів операційна система аналізує їх вміст, видає, де визнає за потрібне, діагностичні повідомлення про виявлені помилки і розтягує отримані відомості про додатки за своїми таблицями.
Проблему вирішено. Тепер для видалення програми достатньо лише видалити його файл-паспорт. Не так важливо, що при цьому робитиме операційна система: чи збере всі свої таблиці заново, або прицільно виключить відповідні їх елементи, для чого їй потрібно буде зберігати початкові відомості про походження кожного елемента кожної таблиці. Головне, що в будь-якому випадку програма видаляється гранично просто і зникає абсолютно безслідно.
Нову схему інсталяції має сенс оснастити деяким сервісом для підготовленого користувача. Добре було б дозволити заглядати в системні таблиці, побудовані з матеріалу файлів-паспортів, де про кожен елемент можна дізнатися, які програми зажадали його включення. Іноді це могло б допомогти при спробі вручну вирішити конфлікт додатків. Маючи в своєму розпорядженні подібний сервіс, користувач виявляється в середовищі в усіх відношеннях значно більш доброзичливим, ніж існуюче операційне середовище MS DOS - Windows. Крім радикального спрощення процесів увімкнення та виключення додатків, він не тільки має зручний доступ до інформації, яку раніше доводилося розшукувати в системних файлах, але й отримує відомості про походження кожного елемента цієї інформації, що раніше було абсолютно недоступним.
Деяке наближення до описаної схеми можна знайти в Windows 95. Що ж завадило розробникам Microsoft із самого початку застосувати таке рішення? Причин можна назвати кілька, але лише одна з них є досить вагомою, хоч і далеко не очевидною.
Очевидно, розробниками рухало бажання наблизити створювані засоби опису додатків до загальновідомих мов програмування. Це прагнення, багато в чому виправдане, мало й негативний бік: засоби опису успадкували від мов їхню серйозну ваду - відсутність підтримки однорідних розширюваних наборів. Через відносну складність мов класу Сі або Паскаль сумні наслідки нехтування однорідними наборами не такі помітні; у нашому випадку, на тлі простенького синтаксису системних файлів, ці наслідки виявилися досить-таки рельєфно. Інформація, що збирається в системних файлах, має виражену двовимірну структуру: вертикальні шари-додатки і горизонтальні шари-списки однорідних системних ресурсів. Кожному з двох вимірів необхідно надати конструктивне оформлення, однак зробити це, не виходячи за межі поширених мовних засобів, не вдається.
Сама по собі ідея зосередження всіх відомостей про апаратну та програмну конфігурацію даного комп'ютеранад асоціативно формованих таблицях, а кількох текстових системних файлах цілком дієздатна. Користувачеві зручно переглядати або редагувати ці файли за допомогою свого улюбленого універсального текстового редактора. Однак біда в тому, що такі редактори створюються з огляду на запити існуючих мов програмування, і за мовами в редакторах традиційно відсутні асоціативні конструкції, що обслуговують однорідні набори, що розширюються. Але це означає, що фірма Microsoft, поклавшись у ранніх версіях операційної системи на системні текстові файли, фактично підписала вирок надійної організації додавання або виключення однорідних додатків.
Через відсутність асоціативних конструкцій інсталяція нової програми, зазвичай, вимагає редагування текстів системних файлів. Тут легко помітити одразу два джерела неприємностей. По-перше, будь-яке редагування тексту, що знаходиться в експлуатації, і особливо чужого тексту, - процедура надзвичайно делікатна. Далеко не кожен додаток успішно з нею справляється, і допущені помилки редагування невблаганно роблять свою чорну справу: після недбалої інсталяції нерідко не тільки не викликається новий додаток, але й перестають працювати його сусіди, інформація про яких, безпосередньо записана в текстових файлах, що редагуються, дуже вразлива і легко може бути пошкоджено. По-друге, редагування знеособлює додатки, що вносяться, породжуючи зазначені вище складності деінсталяції.
Навпаки, якщо редактор підтримує асоціативні конструкції, ці проблеми знаходять акуратне рішення. Там системного текстового файлу, куди кожен додаток повинен був вписати, скажімо, відомості про драйвери певного класу, що додаються їм, тепер розташовується асоціативна конструкція з наступною семантикою: "Сюди включити оголошення драйверів даного класуз усіх файлів-паспортів додатків, що зберігаються на постійному диску". Від редактора потрібно лише забезпечити перегляд та видачу системного файлу у двох режимах: або у формі вихідного тексту, або з підставленими на місце асоціативних конструкцій однорідними оголошеннями. Таким чином, вихідна двовимірність інформації отримує конструктивне оформлення: вертикальні шари-додатки відображаються у файли-паспорти, а горизонтальні шари-списки однорідних ресурсів - у сукупності оголошень драйверів, що пред'являються редактором у точках розміщення асоціативних конструкцій.
Обидва запропоновані рішення задачі, і табличні, і текстові, мають свої плюси і мінуси і виглядають приблизно рівноцінно. На користь табличного рішення говорить можливість застосування спеціалізованого редактора, здатного, зокрема, більш оперативно реагувати на помилки у значеннях параметрів, що вводяться, і надає широкий діапазон різноманітних засобів перегляду таблиць. Головна перевага текстового рішення - єдине уявлення всіх вихідних матеріалів програми, основний обсяг якого зазвичай становлять алгоритми, представлені у текстовій формі.
Оформлення табличного рішення досить очевидне; один із його можливих варіантівЯк уже згадувалося, можна знайти в Windows 95. Текстове рішення вимагає асоціативних конструкцій. Дві конструкції такого роду вже зналися на . Для нашого випадку буде потрібна ще одна асоціативна конструкція, розосереджений набір. Детальний його опис міститься в . Тут же, не вдаючись у деталі і не намагаючись охопити всі нюанси відносин між операційною системою та додатками, обмежимося побіжним розглядом порівняно простого, але досить показового прикладу застосування розосередженого набору в суміжній області для відомого завдання про діагностичні повідомлення. Використовувана там схема легко проектується і обслуговування додатків.
Розосереджений набір
Більшість розробників великих програм колись стикалися з наступною проблемою. Нехай програма повинна здійснювати ретельний аналіз вхідних даних, результатом якого є, зокрема, значна кількість діагностичних повідомлень, що видаються нею. Питання полягає в тому, де слід розмістити тексти повідомлень: записати їх безпосередньо в тих точках програми, в яких виявляються ситуації, що діагностуються, або ж звести в єдиний список. Кожна з альтернатив має свої сильні та слабкі сторони.
Безпосереднє розміщення має цілу низку переваг. Текст повідомлення, записаний безпосередньо у програмі, є, як правило, найкращим поясненням до фрагмента алгоритму, що аналізує ситуацію, що діагностується. При кодуванні алгоритму значно зручніше одразу розмістити повідомлення у створюваній програмі, ніж включити його до списку, що формується на окремому аркуші паперу або на будь-якому його екранному аналогу, доповнивши алгоритм посиланням на знову записаний рядок списку. Спискове рішення вимагає постійної уваги до цілісності програми: додаючи або виключаючи деякий фрагмент алгоритму, необхідно суворо стежити за тим, щоб тексти діагностичних повідомлень, що видаються там, були додані до списку або, відповідно, виключені з нього. При безпосередньому розміщенні про цілісність дбати не треба.
Водночас аргументи на користь списку також є досить вагомими. 30 років тому розміри оперативної пам'ятізазвичай не дозволяли розмістити тексти повідомлень безпосередньо у програмі, що змушувало виносити ці тексти у файл на зовнішньої пам'ятідля формування вмісту якого був потрібний зведений список повідомлень. Але й у наші дні такий список у багатьох випадках дуже доречний. Він є корисним доповненням до будь-якої інструкції з експлуатації програмного продукту. При вивченні алгоритму список дає змогу побачити текст програми у новому цікавому ракурсі. Аналізуючи та коригуючи зведений список, легше досягти стилістичної єдності повідомлень. Нарешті, спискове уявлення дозволяє уникнути пошуку розкиданих за програмою текстів за необхідності створення версії програми, що видає повідомлення іншою мовою.
Проблема розміщення текстів повідомлень є досить серйозною, тому для її вирішення іноді навіть пропонують застосовувати спеціалізовані системні засоби підтримки. Така вузька спеціалізація системних засобіввсе ж таки представляється нераціональною. Адже якщо витратити трохи більше зусиль, то замість вузьконаправленого інструменту можна отримати засоби підтримки значно потужнішого механізму - так званого розосередженого набору, - здатні охопити також безліч інших практичних завдань, зокрема розглянуту вище завдання обслуговування додатків. (Під час обговорення обслуговування додатків йшлося про два рішення, табличний і текстовий, проте в нашому випадку таблиці абсолютно непридатні, оскільки через таку дрібницю, як діагностичні повідомлення, не варто ламати міцну плідну традицію текстового представлення алгоритмів.)
Схема розв'язання проблеми розміщення повідомлень за допомогою механізму розосередженого набору проілюстровано малюнку1. Тексти повідомлень записуються розосереджено - безпосередньо у програмі, але оформляються у вигляді параметрів так званих експортних заявок. Якщо у збираному вихідному текстіпрограми зустрічається така заявка, то зазначений у ній параметр включається як елемент формується таким чином розосереджений набір. Шуканий зведений список повідомлень у цьому випадку будується на основі набірного гнізда , В якому автоматично збираються всі елементи розосередженого набору - всі повідомлення, що експортуються зі складових програм модулів. На місці експортних заявок при складанні програми формуються звернення до побудованого списку. Неважко бачити, що дана схема успішно справляється з усіма перерахованими труднощами розміщення повідомлень.
Малюнок 1.
Розосереджений набір.
Рішення проблеми обслуговування додатків, що нас цікавило, тепер легко отримати, якщо замість модулів програми розглядати файли-паспорти, а в експортних заявках розмістити не тексти повідомлень, а запити на ресурси операційної системи. Вочевидь, тут потрібно сформувати кілька розосереджених наборів, які обслуговують окремі класи ресурсів.
Розвиваючи розпочату паралель, можна заявити, що програма, що використовує механізм розосередженого набору, відкрита для увімкнення або виключення модулів, що містять діагностичні повідомлення. Справді, розробник такої програми повністю позбавлений всіх технічних турбот щодо синхронної корекції зведеного списку. Далі закономірно постає питання: а що ще можна було б зробити для полегшення розвитку програми? Таким чином, ми впритул підійшли до обговорення відкритості систем програмування та алгоритмічних мов.
Відкритість системи програмування
Нагадаємо, що відкритість операційної системи ми інтерпретували як її здатність до вільного додавання нових та виключення існуючих додатків. Аналогічне визначення відкритості застосовно і до системи програмування, тільки тут як додані та виключені виступають елементи програми, модулі. Цікаво, що таке визначення зазвичай є досить природним і не викликає заперечень у програмістів, проте подальші аналогії між мовами програмування та відкритими системами сприймаються важко і вимагають аргументації. Якщо у відкритих системах гасло "систему відкриває стандартизація її компонентів" із самого початку було накреслено на прапорі, то твердження "відкритість програми для подальшого розвитку визначається ступенем стандартизованості або гомогенізації її модулів" зустрінеш нечасто.
Точніше, загальновизнано, що розчленування програми на модулі – перевірений засіб полегшення її подальшого розвитку. Ще в 70-х роках Парнас пропонував: оформляйте у вигляді модуля кожне рішення, яке приймається у процесі проектування програми, і тоді наступні зміни будуть суворо локалізовані, оскільки їх причина – саме перегляд проектних рішень. Але яке відношення до відкритості має стандартизація і однорідність модулів, що випливає з неї?
Виявляється, між однорідністю модулів та відкритістю програми існує прямий зв'язок, простежити який порівняно нескладно. Наприклад, виділення модуля за Парнасом означає, взагалі кажучи, що закладається перша цегла в основу майбутнього однорідного набору. Якщо переглядаються під час розвитку програми рішення не відкидаються назавжди (оскільки до них, можливо, доведеться будь-коли повернутися), то набір однорідних модулів-реалізацій рішень безпосередньо у базі даних проекту. Але нехай навіть нові варіанти модуля ніколи не є сусідами зі старими, нехай нові модифікації просто приходять на зміну застарілим - і в цьому випадку однорідний набір відбудеться; щоправда, видно буде лише за ретроспективному аналізі розвитку програми.
Однорідні модулі можуть не замінювати один одного, як варіантні модулі за Парнасом, а одночасно бути присутніми у виконуваній програмі. Наприклад, якщо у трансляторі стандартизовано оформлення модулів, що відносяться до реалізації окремих конструкцій вхідної мови, то у виконанні трансляції одночасно беруть участь усі ці модулі. Тут також із однорідності випливає відкритість: чим глибше продумана уніфікація модулів, чим чіткіше окреслено їх зв'язок із зовнішнім світом, тим легше пройде підключення до чинної програми нового модуля, відповідального за нову конструкцію, що розширює вхідну мову.
Якщо в систему включені засоби підтримки однорідних наборів, вона виходить на новий технологічний рівень відкритості: з'являється можливість безболісного включення нових та видалення існуючих однорідних модулів. Безболісність включення і видалення означає, що тут не потрібно будь-якого редагування текстів програм, що знаходяться в експлуатації. Тим самим усувається головна небезпека, головне гальмо вільного маніпулювання модульним матеріалом, оскільки тепер ніякі раніше налагоджені частини не можуть бути пошкоджені при додаванні нових або видаленні існуючих модулів.
Характерний приклад безболісного підключення - розібране рішення задачі обслуговування додатків. Якщо передбачені засоби системної підтримки однорідних наборів, що складаються з запитуваних додатками ресурсів, то додаток, що з'явився, всього лише записує на диск свій файл-паспорт, і при такій технології тексти вже наявних на диску файлів-паспортів не піддаються жодній загрозі. Якщо ж однорідний набір не підтриманий, ми закономірно приходимо до проблем Windows 3.11, де шматки текстів, що стосуються різним додаткам, реально сусідять в одних і тих же системних файлах, додавання або видалення додатків вимагають енергійного редагування цих файлів, а при редагуванні важко не "зачепити" рядки, що відносяться до сусідніх додатків.
На жаль, тенденції програмістської моди зараз спрямовані у бік відкритих однорідних конструкцій. Занадто багато уваги взяло на себе об'єктно-орієнтоване програмування. В результаті при проектуванні структури програми розробник захоплений виключно вичленуванням взаємодіючих об'єктів і рідко замислюється про їх уніфікацію, про уніфікацію методів їх обробки, і взагалі про цілеспрямований пошук однорідностей, а об'єкти і однорідність - два рівноправні, що доповнюють один одного орієнтири проектування. Однорідність забута, однорідність немає системної підтримки, але без однорідності немає відкритості, та розвитку програми із задоволення перетворюється на небезпечну, болісну процедуру.
Модний термін "масштабованість", що говорить про потенціал нарощування потужності апаратури, чомусь мало кому спадає на думку застосувати і до програмних структур. Що трапилося б із будівництвом, якби всі архітектори працювали лише над унікальними спорудами, відмовившись і від типових проектів, і від типових будівельних блоків?! А в програмуванні нерідко проектують унікальний, але консервативний зоопарк там, де потрібен лише серійний, але масштабований корівник або свинарник.
Навіть очевидні однорідні конструкції в мовах програмування зазвичай опиняються на задвірках. Типовий приклад – опис запису в Паскалі. Дев'ять із десяти розробників намагаються підкреслити однорідність полів запису, виділяючи під кожен із них окремий рядок своєї програми. Однак синтаксис Паскаля руйнує гармонію, що намічається таким чином, наказуючи однорідним полям неоднорідне оформлення: описи перших полів повинні завершуватися крапкою з комою, опис останнього - ні. Але будь-яка однорідність у програмі – потенційна точка розвитку. І дійсно, розробник досить часто додає або виключає поля запису, і щоразу він змушений замислюватися: а чи не останнє поле виключається, - адже в цьому випадку треба знищити не тільки рядок тексту, але й крапку з комою у попередньому рядку. Таким чином, відкритість опису полів запису принесена в жертву сумнівним синтаксичним вишукуванням. Цікаво, що у Сі проставлення крапки з комою в аналогічній позиції дозволено – і нічого, небо не обрушилося на землю.
Менш очевидний приклад – оформлення однорідного набору гілок програми, що допускають паралельне виконання. Конструкція, що обслуговує це завдання, зараз нерідко надбудовується над мовою, коли створюються спеціалізовані засоби для ефективного завантаження паралельно працюючого обладнання. Розробник сприймає її як неминуче зло, з яким доводиться миритись, якщо хочеш освоювати нову техніку. Насправді можливість паралельного виконання підкреслює однорідність гілок, і тому її має сенс оформляти, навіть якщо перехід до паралельного обладнання не планується. Тим самим не тільки проявиться важлива особливість алгоритму, а й буде утворена нова точка зростання програми, надалі її не сплутаєш із послідовними частинами і не доведеться ламати голову над тим, де розмістити ще одну додаткову паралельну гілку. Допустимі паралельне виконання гілки зустрічаються в реальних програмах на кожному кроці, проте конструкції, що їх відображають, на жаль, відсутні в масових алгоритмічних мовах.
Недалекоглядну традицію ігнорування потреб однорідних конструкцій продовжують і нові течії у програмуванні, зокрема візуальне програмування. Спробуйте в Delphi побудувати лінійку, що складається з щільно притиснутих один до одного однорідних швидких кнопок і відкриту для модифікації - що підтримує очевидні дії: додавання нової кнопки довільне місце лінійки з автоматичним розсуненням її сусідів і видалення довільної кнопки, що супроводжується "змиканням ряду" . І ви швидко відчуєте, що такі проекти знаходилися на периферії уваги творців Delphi. Але візуальний стиль частково виправдовує його дитячий вік, він навіть не увійшов ще в сучасні підручники, а ось проникнення великих однорідних конструкцій у поширені мови програмування пояснити дійсно важко.
Ситуація, що склалася, виглядає вдвічі неприродно, якщо помітити, що в сусідніх областях, наприклад в системах управління базами даних, панує відносне благополуччя. Неможливо уявити, що користувачеві бази даних для включення до однієї з таблиць нового рядка пропонують звернутися до загальноцільового текстовому редактору. Всім очевидно, що при такій постановці справи користувач страждає не лише через необхідність виконувати безліч зайвих допоміжних дій, а й, головне, через постійну небезпеку руйнування існуючих даних за помилки, допущеної під час редагування.
Але текст програми представляє, взагалі кажучи, не меншу цінність, ніж рядки таблиці бази даних. І модифікувати програми доводиться досить часто. І кошти, необхідні організації безболісних змін, негаразд складні у реалізації. Проте досі переважна більшість модифікацій програми, що виконуються, проводиться варварськими методами, із залученням загальноцільового редактора для корекції дорогоцінних налагоджених раніше текстів.
Безрадісно виглядають і перспективи. Якщо озирнутися на багаторічну історію операційних систем, систем програмування та алгоритмічних мов, ставати ясно, що не доводиться всерйоз розраховувати на те, що має місце, але дуже млявий поточний стихійний рух до відкритості. Тут потрібна радикальна ломка уявлень. Треба сформувати атмосферу, де кожен, заявляючи, що його програмна система відкрита, вважав би своїм обов'язком не тільки пред'явити зведення стандартів на її модулі, а й продемонструвати засоби системної підтримки, що обслуговують вільне маніпулювання однорідними елементами програми, що виникають в результаті цієї стандартизації.
Література
. Горбунов-Посад М.М. Безболісний розвиток програми // Відкриті системи. – 1996. – # 4(18). – С.65-70.
. Горбунов-Посад М.М. Налаштування програм. Рецепти безболісних змін. - 2-ге вид., испр. та дод. - М: Маліп, 1994. - 272 с.
. Parnas D.L. На критерії для використання в комплексних системах в modules // Comm.ACM. – 1972. – V.15, # 12. – P.1053-1058.
. Ben-Ari M. Understanding programming languages. – Chichester: John Wiley & Sons, 1996. – 360 p.
Робота виконана за фінансової підтримки Російського фонду фундаментальних досліджень.
Модель OSI, як це випливає з її назви (Open System Interconnection), визначає взаємозв'язки відкритих систем. Що таке відкрита система?
В широкому сенсі відкритою системоюможе бути названа будь-яка система (комп'ютер, обчислювальна мережа, ОС, програмний пакет, інші апаратні та програмні продукти), яка побудована відповідно до відкритих специфікацій.
Нагадаємо, що під терміном «специфікація» (у обчислювальній техніці) розуміють формалізоване опис апаратних або програмних компонентів, способів їх функціонування, взаємодії з іншими компонентами, умов експлуатації, обмежень та особливих характеристик. Зрозуміло, що всяка специфікація є стандартом. У свою чергу, під відкритими специфікаціями розуміються опубліковані загальнодоступні специфікації, що відповідають стандартам і прийняті в результаті досягнення згоди після всебічного обговорення всіма зацікавленими сторонами.
Використання розробки систем відкритих специфікацій дозволяє третім сторонам розробляти цих систем різні апаратні чи програмні засоби розширення і модифікації, і навіть створювати програмно-апаратні комплекси із продуктів різних виробників.
Для реальних систем повна відвертість є недосяжним ідеалом. Як правило, навіть у системах, які називають відкритими, цьому визначенню відповідають лише деякі частини, що підтримують зовнішні інтерфейси. Наприклад, відкритість сімейства операційних систем Unix полягає, крім усього іншого, в наявності стандартизованого програмного інтерфейсу між ядром і додатками, що дозволяє легко переносити програми серед однієї версії Unix в середовище іншої версії. Ще одним прикладом часткової відкритості є застосування в закритій операційній системі Novell NetWare відкритого інтерфейсу Open Driver Interface (ODI) для включення в систему драйверів мережевих адаптерівнезалежних виробників. Чим більше відкритих специфікацій використано розробки системи, тим більш відкритої вона є.
Модель OSI стосується лише одного аспекту відкритості, а саме відкритості засобів взаємодії пристроїв, пов'язаних з обчислювальною мережею. Тут під відкритою системою розуміється мережевий пристрій, готове взаємодіяти з іншими мережевими пристроями з використанням стандартних правил, що визначають формат, зміст і значення повідомлень, що приймаються і надсилаються.
Якщо дві мережі побудовані з дотриманням принципів відкритості, це дає такі переваги:
Можливість побудови мережі з апаратних та програмних засобіврізних виробників, які дотримуються одного й того самого стандарту;
Можливість безболісної заміни окремих компонентів мережі іншими, досконалішими, що дозволяє мережі розвиватися з мінімальними витратами;
Можливість легкого сполучення однієї мережі з іншою;
Простота освоєння та обслуговування мережі.
Яскравим прикладом відкритої системи є мережа Internet. Ця мережа розвивалася у повній відповідності до вимог, що висуваються до відкритих систем. У розробці її стандартів брали участь тисячі фахівців-користувачів цієї мережі з різних університетів, наукових організацій та фірм-виробників обчислювальної апаратури та програмного забезпечення, що працюють у різних країнах. Сама назва стандартів, що визначають роботу мережі Internet - Request For Comments (RFC), що можна перекласти як "запит на коментарі", - показує голосний і відкритий характер стандартів, що приймаються. Через війну мережа Internet зуміла об'єднати у собі найрізноманітніше устаткування й програмне забезпечення величезної кількості мереж, розкиданих у світі.
1.3.5. Модульність та стандартизація
Модульність - це одна з невід'ємних та природних властивостей обчислювальних мереж. Модульність проявляється у багаторівневому представленні комунікаційних протоколів у кінцевих вузлах мережі, хоча це, безумовно, важлива і важлива особливість мережевий архітектури. Мережа складається з величезної кількості різних модулів - комп'ютерів, мережевих адаптерів, мостів, маршрутизаторів, модемів, операційних систем та модулів додатків. Різноманітні вимоги, що пред'являються підприємствами до комп'ютерних мереж, призвели до такої ж різноманітності пристроїв і програм, що випускаються для побудови мережі. Ці продукти
відрізняються не тільки основними функціями (маються на увазі функції, що виконуються, наприклад, повторювачами, мостами або програмними редиректорами), але і численними допоміжними функціями, що надають користувачам або адміністраторам додаткові зручності, такі як автоматизоване конфігурування параметрів пристрою, автоматичне виявлення та усунення деяких несправностей можливість програмної зміни зв'язків у мережі тощо. Різноманітність збільшується також тому, що багато пристроїв та програм відрізняються поєднаннями тих чи інших основних та додаткових функцій - існують, наприклад, пристрої, що поєднують основні можливості комутаторів та маршрутизаторів, до яких додається ще й набір Деякі додаткові функції характерні лише для даного продукту.
В результаті не існує компанії, яка б змогла забезпечити виробництво повного набору всіх типів і підтипів обладнання та програмного забезпечення, необхідного для побудови мережі. Але, оскільки всі компоненти мережі повинні працювати узгоджено, абсолютно необхідним виявилося прийняття численних стандартів, які, якщо не у всіх, то хоча б у більшості випадків, гарантували сумісність обладнання та програм різних фірм-виробників. Таким чином, поняття модульності та стандартизації в мережах нерозривно пов'язані, і модульний підхід лише тоді дає переваги, коли він супроводжується дотриманням стандартів.
В результаті відкритий характер стандартів та специфікацій важливий не тільки для комунікаційних протоколів, але і для всіх численних функцій різноманітних пристроїв та програм, що випускаються для створення мережі. Слід зазначити, більшість стандартів, прийнятих сьогодні, мають відкритий характер. Час закритих систем, точні специфікації на які були відомі тільки фірмі-виробнику, пішло. Всі усвідомили, що можливість легкої взаємодії з продуктами конкурентів не знижує, а навпаки, підвищує цінність виробу, оскільки його можна застосувати у більшій кількості працюючих мереж, побудованих на продуктах різних виробників. Тому навіть фірми, які раніше випускали дуже закриті системи - такі як IBM, Novell або Microsoft, - сьогодні беруть активну участь у розробці відкритих стандартів і застосовують їх у своїх продуктах.
Сьогодні в секторі мережного обладнання та програм із сумісністю продуктів різних виробників склалася така ситуація. Майже всі продукти, як програмні, так і апаратні, сумісні за функціями та властивостями, які були впроваджені в практику вже досить давно і стандарти на які вже розроблені та прийняті принаймні 3-4 роки тому. У той же час дуже часто принципово нові пристрої, протоколи та якості виявляються несумісними навіть у провідних виробників. Така ситуація спостерігається не тільки для тих пристроїв або функцій, стандарти на які ще не встигли прийняти (це природно), але й для пристроїв, стандарти на які існують кілька років. Сумісність досягається лише після того, як усі виробники реалізують цей стандарт у своїх виробах, причому однаковим чином.
1.3.6. Джерела стандартів
Роботи зі стандартизації обчислювальних мереж ведуться великою кількістю організацій. Залежно від статусу організацій розрізняють такі види стандартів:
стандарти окремих фірм(наприклад, стек протоколів DECnet фірми Digital Equipment або графічний інтерфейс OPEN LOOK для Unix-систем фірми Sun);
стандарти спеціальних комітетів та об'єднань,створюваних декількома фірмами, наприклад стандарти технології АТМ, що розробляються спеціально створеним об'єднанням АТМ Forum, що налічує близько 100 колективних учасників, або стандарти спілки Fast Ethernet Alliance з розробки стандартів 100 Мбіт Ethernet;
національні стандарти,наприклад, стандарт FDDI, що представляє один із численних стандартів, розроблених Американським національним інститутом стандартів (ANSI), або стандарти безпеки для операційних систем, розроблені Національним центром комп'ютерної безпеки (NCSC) Міністерства оборони США;
міжнародні стандарти,наприклад, модель та стек комунікаційних протоколів Міжнародної організації зі стандартів (ISO), численні
стандарти Міжнародного союзу електрозв'язку (ITU), зокрема стандарти
на мережі з комутацією пакетів Х.25, мережі frame relay, ISDN, модеми та багато
Деякі стандарти, безперервно розвиваючись, можуть переходити з однієї категорії до іншої. Зокрема, фірмові стандарти на продукцію, що набула широкого поширення, зазвичай стають міжнародними стандартами де-факто, оскільки змушують виробників з різних країн дотримуватися фірмових стандартів, щоб забезпечити сумісність своїх виробів із цими популярними продуктами. Наприклад, через феноменальний успіх персонального комп'ютера IBM фірмовий стандарт на архітектуру IBM PC став міжнародним стандартом де-факто.
Більше того, через широке поширення деякі фірмові стандарти стають основою для національних та міжнародних стандартів де-юре. Наприклад, стандарт Ethernet, спочатку розроблений компаніями Digital Equipment, Intel та Xerox, через деякий час і в дещо зміненому вигляді був прийнятий як національний стандарт IEEE 802.3, а потім організація ISO затвердила його як міжнародний стандарт ISO 8802.3.
Міжнародна організація зі стандартизації (International Organization/ or Standardization, ISO, часто звана також International Standards Organization) є асоціацією провідних національних організацій зі стандартизації різних країн. Головним досягненням ISO стала модель взаємодії відкритих систем OSI, яка є концептуальною основою стандартизації в області обчислювальних мереж. Відповідно до моделі OSI цією організацією був розроблений стандартний стек комунікаційних протоколів OSI.
Міжнародний союз електрозв'язку (International Telecommunications Union, ITU) - організація, що є нині спеціалізованим органом Організації Об'єднаних Націй. Найбільш значну роль у стандартизації обчислювальних мереж відіграє Міжнародний консультативний комітет з телефонії та телеграфії (МККТТ) (Consultative Committee on International Telegraphy and Telephony, CCITT), що постійно діє в рамках цієї організації. В результаті проведеної в 1993 році реорганізації ITU CCITT дещо змінив напрямок своєї діяльності та змінив назву - тепер він називається сектором телекомунікаційної стандартизації ITU (ITU Telecommunication Standardization Sector, ITU-T). Основу діяльності ITU-T складає розробка міжнародних стандартів у галузі телефонії, телематичних служб (електронної пошти, факсимільного зв'язку, телетексту, телексу тощо), передачі даних, аудіо- та відеосигналів. За роки своєї діяльності ITU-T випустив величезну кількість рекомендацій-стандартів. Свою роботу ITU-T будує на вивченні досвіду сторонніх організацій, а також результати власних досліджень. Раз на чотири роки видаються праці ITU-T у вигляді так званої «Книги», яка насправді є цілим набором звичайних книг, згрупованих у випуски, які, у свою чергу, об'єднуються в томи. Кожен том та випуск містять логічно взаємопов'язані рекомендації. Наприклад, том III Синьої книги містить рекомендації для цифрових мереж з інтеграцією послуг (ISDN), а весь том VIII (за винятком випуску VIII.1, який містить рекомендації серії V для передачі даних по телефонній мережі) присвячений рекомендаціям серії X: Х.25 для мереж із комутацією пакетів, Х.400 для систем електронної пошти, Х.500 для глобальної довідкової службита багатьом іншим.
Інститут інженерів з електротехніки та радіоелектроніки -Institute of Electrical and Electronics Engineers, IEEE) - національна організація США, що визначає мережеві стандарти. У 1981 робоча група 802 цього інституту сформулювала основні вимоги, яким повинні задовольняти локальні обчислювальні мережі. Група 802 визначила безліч стандартів, з них найвідомішими є стандарти 802.1,802.2, 802.3 та 802.5, які описують загальні поняття, що використовуються в області локальних мереж, а також стандарти на два нижніх рівня мереж Ethernet та Token Ring.
Європейська асоціація виробників комп'ютерів (European Комп'ютер Manu facturers Association, ЕСМА) -некомерційна організація, що активно співпрацює з ITU-T та ISO, займається розробкою стандартів та технічних оглядів, що належать до комп'ютерної та комунікаційної технологій. Відома своїм стандартом ЕСМА-101, який використовується при передачі відформатованого тексту та графічних зображень із збереженням оригінального формату.
Асоціація виробників комп'ютерів та оргтехніки (Комп'ютер and Business Equipment Manufacturers Association, CBEMA) - організація американських фірм-виробників апаратного забезпечення; аналогічна європейській асоціації ЕКМА; бере участь у розробці стандартів на обробку інформації та відповідне обладнання.
Асоціація електронної промисловості (Electronic Industries Association, EIA) - промислово-торгівельна група виробників електронного та мережевого обладнання; є національною комерційною асоціацією США; виявляє значну активність у розробці стандартів для проводів, конекторів та інших мережевих компонентів. Її найвідоміший стандарт – RS-232C.
Міністерство оборони США (Department of Defense, DoD) має численні підрозділи, що займаються створенням стандартів комп'ютерних систем. Однією з найвідоміших розробок DoD є стек транспортних протоколів TCP/IP.
Американський національний інститут стандартів (American National Standards Institute, ANSI) - ця організація представляє США у Міжнародній організації зі стандартизації ISO. Комітети ANSI ведуть роботу з розробки стандартів різних областяхобчислювальної техніки. Так, комітет ANSI ХЗТ9.5 разом із фірмою IBM займається стандартизацією локальних мереж великих ЕОМ (архітектура мереж SNA). Відомий стандарт FDDI є результатом діяльності цього комітету ANSI. В області мікрокомп'ютерів ANSI розробляє стандарти мови програмування, інтерфейс SCSI. ANSI розробив рекомендації щодо переносимості для мов С, FORTRAN, COBOL.
Особливу роль виробленні міжнародних відкритих стандартів грають стандарти Internet. Зважаючи на велику і постійну зростаючу популярність Internet, ці стандарти стають міжнародними стандартами «де-факто», багато з яких потім набувають статусу офіційних міжнародних стандартів за рахунок їх затвердження однією з перерахованих вище організацій, у тому числі ISO і ITU-T. Існує кілька організаційних підрозділів, відповідальних розвиток Internet і, зокрема, за стандартизацію коштів Internet.
Основним із них є Internet Society (ISOC) - професійне співтовариство, яке займається спільними питаннями еволюції та зростання Internet як глобальної комунікаційної інфраструктури. Під керівництвом ISOC працює Internet Architecture Board (IAB) - організація, у веденні якої перебуває технічний контроль та координація робіт для Internet. IAB координує напрямок досліджень та нових розробок для стека TCP/IP і є кінцевою інстанцією щодо нових стандартів Internet.
В IAB входять дві основні групи: Internet Engineering Task Force (IETF) та Internet Research Task Force (IRTF). IETF - це інженерна група, яка займається вирішенням найближчих технічних проблем Internet. Саме IETF визначає специфікації, які потім стають стандартами Інтернету. У свою чергу, IRTF координує довгострокові дослідні проекти з протоколів TCP/IP.
У будь-якій організації, що займається стандартизацією, процес вироблення та прийняття стандарту складається з низки обов'язкових етапів, які, власне, складають процедуру стандартизації. Розглянемо цю процедуру з прикладу розробки стандартів Internet.
Спочатку в IETF представляється так званий робочий проект (draft) у вигляді, доступному для коментарів. Він публікується в Internet, після чого широке коло зацікавлених осіб включається до обговорення цього документа, до нього вносяться виправлення, і нарешті настає момент, коли можна зафіксувати зміст документа. На цьому етапі проекту надається номер RFC (можливий «. інший варіант розвитку подій - після обговорення робочий проект відкидається та видаляється з Internet).
Після присвоєння номера проект набуває статусу запропонованого стандарту.Протягом 6 місяців цей пропонований стандарт проходить перевірку практикою, у результаті до нього вносяться зміни.
Якщо результати практичних досліджень показують ефективність запропонованого стандарту, йому, з усіма внесеними змінами, надається статус проекту стандарту.Потім протягом щонайменше 4-х місяців проходять його, подальші випробування «на міцність», у яких входить створення щонайменше двох програмних реалізації.
Якщо під час перебування в ранзі проекту стандарту в документ не було внесено жодних виправлень, то йому може бути надано статус офіційного стандарту Internet. Список затверджених офіційних стандартів Internet публікується як документа RFC і доступний Internet. Слід зазначити, що це стандарти Internet звуться RFC з відповідним порядковим номером, але далеко ще не все RFC є стандартами Internet - часто ці документи є коментарі до якогось стандарту чи навіть описи деякої проблеми Internet.
1.3.7. Стандартні стеки комунікаційних протоколів
Найважливішим напрямом стандартизації у сфері обчислювальних мереж є стандартизація комунікаційних протоколів. В даний час у мережах використовується велика кількість стеків комунікаційних протоколів. Найбільш популярними є стеки: TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA та OSLBce ці стеки, крім SNA на нижніх рівнях - фізичному та канальному, - використовують одні й ті ж добре стандартизовані протоколи Ethernet, Token;
Ring, FDDI та деякі інші, які дозволяють використовувати у всіх мережах одну й ту саму апаратуру. Зате на верхніх рівнях усі стеки працюють за своїми! власним протоколам. Ці протоколи часто не відповідають рекомендованому! моделлю OSI розбиття на рівні. Зокрема, функції сеансового і представницького рівня, як правило, об'єднані з прикладним рівнем. Така невідповідність пов'язана з тим, що модель OSI з'явилася як результат узагальнення існуючих і реально використовуваних стеків, а не навпаки.
Слід чітко розрізняти модель OSI та стек OSI. У той час як модель OSI є| ється концептуальною схемою взаємодії відкритих систем, стек OSI | є набір цілком конкретних специфікацій протоколів. На відміну від інших стеків протоколів стек OSI повністю відповідає моделі OSI, він включає специфікації протоколів для всіх семи рівнів взаємодії, визначених цієї моделі. На нижніх рівнях стек OSI підтримує Ethernet, Token Ring FDDI, протоколи глобальних мереж, Х.25 та ISDN, - тобто використовує розроблені поза стеком протоколи нижніх рівнів, як і всі інші стеки. Протоколу мережного, транспортного та сеансового рівнів стека OSI специфіковані та реалізовані різними виробниками, але поширені поки що мало. Найбільш популярними протоколами стека OSI є прикладні протоколи. До них відносяться: протокол передачі файлів FTAM, протокол емуляції терміналу VTPJ протоколи довідкової служби Х.500, електронної пошти Х.400 та інших. :
Протоколи стеку OSI відрізняє велика складність та неоднозначність специфікацій. Ці якості з'явилися результатом загальної політики розробників стека, які прагнули врахувати у своїх протоколах всі випадки життя і всі існуючі технології. До цього потрібно ще додати й наслідки великої кількості політичних компромісів, неминучих при прийнятті міжнародних стандартів з такого злободенного питання, як побудова відкритих обчислювальних мереж.
Через свою складність протоколи OSI вимагають великих витрат обчислювальної потужності центрального процесора, що робить їх найбільш підходящими для потужних машин, а не для персональних комп'ютерів.
Стек OSI – міжнародний, незалежний від виробників стандарт. Його підтримує уряд США у своїй програмі GOSIP, згідно з якою всі комп'ютерні мережі, що встановлюються в урядових установах США після 1990 року, повинні або безпосередньо підтримувати стек OSI, або забезпечувати засоби для переходу на цей стек у майбутньому. Проте стек OSI більш популярний у Європі, ніж у США, тому що в Європі залишилося менше старих мереж, що працюють за власними протоколами. Більшість організацій поки що планують перехід до стеку OSI, і дуже мало хто приступив до створення пілотних проектів. З тих, хто працює в цьому напрямку, можна назвати Військово-морське відомство США та мережу NFSNET. Одним із найбільших виробників, що підтримують OSI, є компанія AT&T, її мережа Stargroup повністю базується на цьому стеку.
Стек TCP/IP був розроблений з ініціативи Міністерства оборони США понад 20 років тому для зв'язку експериментальної мережі ARPAnet з іншими мережами як набір загальних протоколів для різнорідного обчислювального середовища. Великий внесок у розвиток стека TCP/IP, який отримав свою назву за популярними протоколами IP та TCP, зробив університет Берклі, реалізувавши протоколи стека у своїй версії ОС UNIX. Популярність цієї операційної системи призвела до поширення протоколів TCP, IP та інших протоколів стека. Сьогодні цей стек використовується для зв'язку комп'ютерів всесвітнього інформаційної мережі Internet, а також у величезній кількості корпоративних мереж.
Стек TCP/IP на нижньому рівні підтримує всі популярні стандарти фізичного та канального рівнів: для локальних мереж - це Ethernet, Token Ring, FDDI, для глобальних - протоколи роботи на аналогових комутованих та виділених лініях SLIP, РРР, протоколи територіальних мереж Х.25 та ISDN.
Основними протоколами стека, що дали назву, є протоколи IP і TCP. Ці протоколи в термінології моделі OSI відносяться до мережного та транспортного рівня відповідно. IP забезпечує просування пакету складової мережі, a TCP гарантує надійність його доставки.
За довгі роки використання в мережах різних країн та організацій стек TCP/IP увібрав у себе велику кількість протоколів прикладного рівня. До них відносяться такі популярні протоколи, як протокол пересилання файлів FTP, протокол емуляції терміналу telnet, поштовий протокол SMTP, що використовується в електронній поштімережі Internet, гіпертекстові послуги служби WWW та багато інших.
Сьогодні стек TCP/IP є одним із найпоширеніших стеків транспортних протоколів обчислювальних мереж. Справді, лише у мережі Internet об'єднано близько 10 мільйонів комп'ютерів у світі, які взаємодіють друг з одним з допомогою стека протоколів TCP/IP.
Стрімке зростання популярності Internet привело і до змін у розстановці сил у світі комунікаційних протоколів - протоколи TCP/IP, на яких побудований Internet, стали швидко тіснити безперечного лідера минулих років - стек IPX/SPX компанії Novell. Сьогодні у світі загальна кількість комп'ютерів, на яких встановлено стек TCP/IP, зрівнялася із загальною кількістю комп'ютерів, на яких працює стек IPX/SPX, і це говорить про різкий перелом щодо адміністраторів локальних мереж до протоколів, які використовуються на настільних комп'ютерах, оскільки саме вони становлять переважну кількість світового комп'ютерного парку і саме на них раніше майже всюди працювали протоколи компанії Novell, необхідні для доступу до файлових серверів NetWare. Процес становлення стека TCP/IP як стека номер один у будь-яких типах мереж триває, і зараз будь-яка промислова операційна система обов'язково включає програмну реалізацію цього стека у своєму комплекті постачання.
Хоча протоколи TCP/IP нерозривно пов'язані з Internet і кожен з багатомільйонної армади комп'ютерів Internet працює на основі цього стека, існує велика кількість локальних, корпоративних та територіальних мереж, які безпосередньо не є частинами Internet, в яких також використовують
протоколи TCP/IP. Щоб відрізняти їхню відмінність від Internet, ці мережі називають мережами TCP/IP, чи навіть IP-мережами.
Оскільки стек TCP/IP спочатку створювався для глобальної мережі Internet він має багато особливостей, що дають йому перевагу перед іншими протоколами, коли йдеться про побудову мереж, що включають глобальні зв'язки. Зокрема, дуже корисною властивістю, що уможливлює застосування цього протоколу у великих мережах, є його здатність фрагментувати пакети. Дійсно, велика складова мережа часто складається з мереж, побудованих абсолютно різних принципах. У кожній з цих мереж можливо встановити власна величина максимальної довжини одиниці переданих даних (в ра). У такому разі при переході з однієї мережі, що має велику максимали довжину, в мережу з меншою максимальною довжиною може виникнути необхідно поділу кадру, що передається, на кілька частин. Протокол IP стека TCP/IP ефективно вирішує це завдання.
Іншою особливістю технології TCP/IP є гнучка система адресації, що дозволяє більш просто в порівнянні з іншими протоколами аналогічного призначення включати мережі мережі інших технологій. Це властивостей також сприяє застосуванню стека TCP/IP для побудови великих гетер» генних мереж.
У стеку TCP/IP дуже економно використовуються можливості широкомовних розсилок. Ця властивість абсолютно необхідна під час роботи на повільних каналах зв'язку, притаманних територіальних мереж.
Однак, як і завжди, за переваги треба платити, і платою тут виявляються високі вимоги до ресурсів і складність адміністрування IP-мереж. Потужні функціональні можливості протоколів стека TCP/IP вимагають реалізації високих обчислювальних витрат. Гнучка система адресації! і відмова від широкомовних розсилок призводять до наявності в IP-мережі різних централізованих служб типу DNS, DHCP тощо. пильної уваги з боку адміністраторів.
Можна наводити й інші доводи за і проти стека протоколів Internet, проте факт залишається фактом - сьогодні це найпопулярніший стек протоколів, що широко використовується як у глобальних, так і локальних мережах.
Стек IPX/SPX
Цей стек є оригінальним стеком протоколів фірми Novell, розробленим для мережі операційної системи NetWare ще на початку 80-х років. Протоколи мережного та сеансового рівнів Internetwork Packet Exchange (IPX) та Sequenced Packet Exchange (SPX), які дали назву стеку, є прямою адаптацією протоколів XNS фірми Xerox, поширених значно меншою мірою, ніж стек IPX/SPX. Популярність стека IPX/SPX безпосередньо пов'язана з операційною системою Novell NetWare, яка ще зберігає світове лідерство за кількістю встановлених систем, хоча останнім часом її популярність трохи знизилася і за темпами зростання вона відстає від Microsoft Windows NT.
Багато особливостей стека IPX/SPX обумовлені орієнтацією ранніх версій ОС NetWare (до версії 4.0) працювати у локальних мережах невеликих розмірів, які з персональних комп'ютерів зі скромними ресурсами. Зрозуміло, що для таких комп'ютерів компанії Novell потрібні були протоколи, на реалізацію яких була б потрібна мінімальна кількість оперативної пам'яті (обмеженої в IBM-сумісних комп'ютерах під управлінням MS-DOS об'ємом 640 Кбайт) і які швидко працювали на процесорах невеликої обчислювальної потужності. В результаті протоколи стека IPX/SPX донедавна добре працювали в локальних мережах і не дуже - у великих корпоративних мережах, тому що вони надто перевантажували повільні глобальні зв'язки широкомовними пакетами, які інтенсивно використовуються декількома протоколами цього стеку (наприклад, для встановлення зв'язку між клієнтами та серверами). Ця обставина, а також той факт, що стек IPX/SPX є власністю фірми Novell і на його реалізацію потрібно отримувати ліцензію (тобто відкриті специфікації не підтримувалися) тривалий час обмежували поширеність його лише мережами NetWare. Однак з моменту випуску версії NetWare 4.0 Novell внесла та продовжує вносити у свої протоколи серйозні зміни, спрямовані на їхню адаптацію для роботи в корпоративних мережах. Зараз стек IPX/SPX реалізований у NetWare, а й у кількох інших популярних мережевих ОС, наприклад SCO UNIX, Sun Solaris, Microsoft Windows NT.
Стек NetBIOS/SMB
Цей стек широко використовується у продуктах компаній IBM та Microsoft. На фізичному та канальному рівнях цього стека використовуються всі найпоширеніші протоколи Ethernet, Token Ring, FDDI та інші. На верхніх рівнях працюють протоколи NetBEUI та SMB.
Протокол NetBIOS (Network Basic Input/Output System) виник 1984 року як мережне розширення стандартних функцій базової системи введення/виводу (BIOS) IBM PC для мережевої програми PC Network фірми IBM. Надалі цей протокол був замінений так званим протоколом розширеного інтерфейсу користувача NetBEUI - NetBIOS Extended User Interface. Для сумісності програм як інтерфейс до протоколу NetBEUI було збережено інтерфейс NetBIOS. Протокол NetBEUI розроблявся як ефективний протокол, що споживає небагато ресурсів і призначений для мереж, що налічують не більше 200 робочих станцій. Цей протокол містить багато корисних мережевих функцій, які можна віднести до мережного, транспортного та сеансового рівнів моделі OSI, однак за його допомогою неможлива маршрутизація пакетів. Це обмежує застосування протоколу NetBEUI локальними мережами, не розділеними на підмережі, і унеможливлює його використання в складових мережах. Деякі обмеження NetBEUI знімаються реалізацією цього протоколу NBF (NetBEUI Frame), який включено до операційної системи Microsoft Windows NT.
Протокол SMB (Server Message Block) виконує функції сеансового, представницького та прикладного рівнів. На основі SMB реалізується файлова служба, а також служби друку та надсилання повідомлень між програмами.
Стеки протоколів SNA фірми IBM, DECnet корпорації Digital Equipment та AppleTalk/AFP фірми Apple застосовуються в основному в операційних системах та мережному обладнанніцих фірм.
Рис. 1.30. Відповідність популярних стеків протоколів моделі OSI
На рис. 1.30 показано відповідність деяких, найбільш популярних протоколіврівням моделі OSI. Часто це відповідність дуже умовно, оскільки модель OSI - це керівництво до дії, причому досить загальне, а конкретні протоколи розроблялися на вирішення специфічних завдань, причому багато хто з них з'явилися до розробки моделі OSI. У більшості випадків розробники стеків віддавали перевагу швидкості роботи мережі на шкоду модульності - жоден стек, крім стека OSI, не розбитий на сім рівнів. Найчастіше в стеку явно виділяються 3-4 рівня: рівень мережевих адаптерів, у якому реалізуються протоколи фізичного і канального рівнів, мережевий рівень, транспортний рівень і рівень служб, що включає функції сеансового, представницького і прикладного рівнів.
У комп'ютерних мережах ідеологічною основою стандартизації є багаторівневий підхід до розробки засобів взаємодії.
Формалізовані правила, що визначають послідовність і формат повідомлень, якими обмінюються мережеві компоненти, що лежать одному рівні, але у різних вузлах, називаються протоколом.
Формалізовані правила, що визначають взаємодію мережевих компонентів сусідніх рівнів одного вузла, називаються інтерфейсом. Інтерфейс визначає набір сервісів, що надається цим рівнем сусідньому рівню.
Ієрархічно організований набір протоколів, достатній в організацію взаємодії вузлів у мережі, називається стеком комунікаційних протоколів.
Відкритою системою може бути названа будь-яка система, яка побудована відповідно до загальнодоступних специфікацій, відповідних стандартів та прийнятих у результаті публічного обговорення всіма заінтересованими сторонами.
Модель OSI стандартизує взаємодію відкритих систем. Вона визначає 7 рівнів взаємодії: прикладний, представницький, сеансовий, транспортний, мережевий, канальний та фізичний.
Найважливішим напрямом стандартизації у сфері обчислювальних мереж є стандартизація комунікаційних протоколів. Найбільш популярними є стеки: TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA та OSI.
Система, що виділяється, відмінна від решти, не ізольована від навколишнього середовища. Навпаки, вони пов'язані та обмінюються між собою будь-якими видами ресурсів (речовиною, енергією, інформацією тощо).
Зазначимо, що зв'язки системи з середовищем мають спрямований характер: за одними середовище впливає на систему (їх називають входами системи), за іншими система впливає на середовище, щось робить у середовищі, щось видає в середу (такі зв'язки називають виходами системи) (рис. 2.2). Перелік входів та виходів системи називають моделлю чорної скриньки. У цій моделі відсутня інформація про внутрішні особливості системи. Незважаючи на (здається) простоту і бідність змісту моделі чорного ящика, ця модель часто цілком достатня для роботи із системою.
У багатьох випадках управління технікою (автомобілем, радіоапаратурою, комп'ютером, приладом) або людьми (наприклад, в менеджменті) інформація тільки про входи та виходи керованої системи дозволяє успішно досягати мети. Однак для цього модель має відповідати певним вимогам. Ви можете відчувати труднощі, якщо не знаєте, що у деяких моделей телевізорів кнопку включення треба не натискати, а витягувати, або що в деяких готелях вимикач у темному приміщенні поєднаний із засувкою, і взагалі зустрівшись із приладом, не всі входи якого вам відомі. Ясно, що для успішного керування системою модель чорної скриньки повинна містити всю інформацію, необхідну досягнення мети.
Відкритість систем та цілісність світу
Дуже важливим для системного аналізу наслідком відкритості систем є очевидність загального взаємозв'язку та взаємозалежності у природі. Цей закон діалектики, встановлений в інтелектуальних та експериментальних муках кількох поколінь, виявляється цілком простим результатом відкритості систем. Між будь-якими двома системами обов'язково існує, і її можна відшукати, довгий або короткий ланцюжок систем, що їх пов'язує: вихід кожної системи є входом іншої. У цьому пряма і зворотна ланцюга, зазвичай, різні, звідки виникає поняття несиметричної причинноследственного зв'язку.
Тарасенко Ф.П. Прикладний системний аналіз (наука та мистецтво вирішення проблем): Підручник. - Томськ; Видавництво Томського університету, 2004. ISBN 5-7511-1838-3
Класифікація за рівнем розподілу
Відкрита система- це система, що складається з компонентів, які взаємодіють між собою через стандартні інтерфейси.
Головною перевагою підходу відкритих систем є спрощення комплексування обчислювальних систем за рахунок міжнародної та національної стандартизації апаратних та програмних інтерфейсів, служб та підтримуваних форматів. Відкриті системи набувають особливого значення та масштабності у зв'язку з бурхливим розвитком технологій глобальних комунікацій.
Властивості відкритих систем:
Розширюваність / масштабованість;
Мобільність (переносимість) – простота перенесення інформаційної системи на будь-яку апаратно-програмну платформу, що відповідає стандартам;
інтероперабельність (здатність до взаємодії з іншими системами);
Дружність до користувача, у тому числі легка керованість.
Підхід відкритих систем забезпечує переваги для різноманітних ІТ-фахівців. Для користувача (замовника) відкриті системи забезпечують:
Можливість поступового нарощування обчислювальних, інформаційних та інших потужностей комп'ютерної системи(користувачі можуть поступово замінювати компоненти системи більш досконалі);
Звільнення від залежності від одного постачальника апаратних або програмних засобів; можливість вибору продуктів із запропонованих на ринку за умови дотримання постачальником відповідних стандартів відкритих систем;
Дружність середовища, в якому працює користувач, мобільність персоналу у процесі еволюції системи; можливість використання інформаційних ресурсів, що є в інших системах (організаціях).
Проектувальник інформаційних системотримує можливість використання різних апаратних платформ; можливість спільного використання прикладних програм, реалізованих у різних операційні системи; розвинені засоби інструментальних середовищ, які підтримують проектування; можливості використання готових програмних продуктів та інформаційних ресурсів. Розробники системних програмних засобів мають: нові можливості поділу праці завдяки повторному використанню програм; розвинені інструментальні середовища та системи програмування; Можливості модульної організації програмних комплексів завдяки стандартизації програмних інтерфейсів.
7.4.1.1. Модель взаємозв'язку відкритих систем (ISO/OSI)
Протокол- Набір угод, прийнятий двома взаємодіючими системами.
Інтерфейс- Набір угод, прийнятий двома (або більше) взаємодіючими елементами однієї системи.
Відкриті системи використовують стандартні протоколи та інтерфейси. Особливого значення підхід відкритих систем набуває у разі мережевої взаємодії.
Міжнародна організація зі стандартизації (ISO), ґрунтуючись на досвіді багатомашинних систем, накопичених у різних країнах, висунула концепцію архітектури відкритих систем OSI - еталонну модель, що використовується при розробці міжнародних стандартів. Модель визначає різні рівні взаємодії систем, дає їм стандартні імена та вказує, яку роботу має виконувати кожен рівень.
Модель складається із семи рівнів (рис. 1.).
