Эталонная модель открытых систем osi. Эталонная модель OSI

Предлагаемая эталонная модель BPM (Business Process Management) основывается на цепочке следующих предпосылок:

Повышение производительности предприятия как сложной системы требует ее рационального построения, а процессное управление является наиболее современной концепцией для такого построения;

BPM (как дисциплина) предлагает системный подход к реализации процессного управления;

На каждом процессно-управляемом предприятии есть своя BPM-система - портфолио всех бизнес-процессов, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио;

Гибкость BPM-системы предприятия является основным фактором ее успеха;

Специализированная программная платформа (BPM suite) для реализации BPM-системы предприятия необходима, но недостаточна, так как BPM занимает особое место в архитектуре предприятия.

Цель: повышение производительности предприятия

Для управления своей производительностью большинство предприятий используют принцип обратной связи (рис. 1), позволяющий адаптироваться к внешней бизнес-экосистеме путем выполнения определенной последовательности действий:

Измерение хода исполнения производственно-хозяйственной деятельности (обычно такие измерения представлены в форме различных метрик или индикаторов, например, процент возвращающихся клиентов);

Вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка);

Определение стратегии развития бизнеса предприятия;

Реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).

В соответствии с классической рекомендацией Эдварда Деминга, автора многочисленных работ в области управления качеством, в том числе известной книги «Выход из кризиса», все усовершенствования должны проводиться циклично, непрерывно и с проверкой на каждом цикле. Степень и частота этих усовершенствований зависят от конкретной ситуации, но рекомендуется делать такие циклы достаточно компактными. Различные усовершенствования могут затрагивать различные аспекты работы предприятия. Вопрос в том, как предприятие может достигнуть наилучших результатов в каждом конкретном случае? Существуют две объективные предпосылки для оптимизации деятельности предприятия как единого целого:

Обеспечение руководства надлежащей информацией и инструментами для принятия решения;

Гарантия того, что бизнес-система предприятия способна к осуществлению необходимых изменений в необходимом темпе.

Наиболее современная концепция организации работы предприятия - процессное управление, при котором процессы и службы становятся явными.

Процессное управление

Мир бизнеса давно понял (см. такие методики, как TQM, BPR, Six Sigma, Lean, ISO 9000, и др.), что службы и процессы - это основа функционирования большинства предприятий. Множество предприятий используют процессное управление для организации своей производственно-хозяйственной деятельности, как портфолио бизнес-процессов и методов управления ими.

Процессное управление, как управленческая концепция, постулирует целесообразность координации деятельности отдельных служб предприятия с целью получения определенного результата при помощи явно и формально определенных бизнес-процессов. При этом службы - это операционно независимые функциональные единицы; у предприятия может быть много элементарных нанослужб, которые организованы в мегаслужбу (собственно предприятие).

Использование явного определения координации позволяет формализовать взаимозависимости между службами. Наличие такой формализации дает возможность использовать различные методы (моделирование, автоматизированная проверка, контроль за версиями, автоматизированное выполнение и т.д.) для улучшения понимания бизнеса (для принятия более правильных решений) и повышения скорости развития бизнес-систем (для более быстрой реализации изменений).

Кроме процессов и служб, бизнес-системы предприятий работают с событиями, правилами, данными, индикаторами работы, ролями, документами и т.д.

Для реализации процессного управления предприятия используют три популярные дисциплины постоянного усовершенствования бизнес-процессов: ISO 9000, Six Sigma и «бережливое», или «экономное», производство (Lean production). Они воздействуют на различные области бизнес-системы предприятия, однако всегда предусматривается сбор данных о фактически проделанной работе и использование некой модели бизнес-процессов для принятия решений (хотя иногда эта модель находится только в чьей-то голове). В то же самое время они предлагают различные и взаимодополняющие методы для того, чтобы определить, какие именно изменения необходимы для улучшения функционирования бизнес-системы предприятия.

Что моделируете, то и выполняете

На рис. 2 приведена обобщенная модель процессно-управляемого предприятия.

В чем основная трудность оптимизации деятельности такого предприятия? Различные части бизнес-системы используют разные описания одного и того же бизнес-процесса. Обычно эти описания существуют отдельно и разработаны разными людьми, обновляются различными темпами, не обмениваются информацией, а некоторых из них просто нет в явном виде. Наличие единого описания бизнес-процессов предприятия позволяет устранить этот недостаток. Это описание должно быть явно и формально определено, чтобы одновременно служить моделью для моделирования, исполняемой программой и документацией, легко понимаемой всеми вовлеченными в бизнес-процесс сотрудниками.

Такое описание - основа дисциплины BPM, позволяющей моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое (рис. 3).

На данный момент в индустрии BPM еще не сложилась надлежащая система стандартов на форматы формального описания бизнес-процессов. Три наиболее популярных формата: BPMN (Business Process Modelling Notation , графическое представление моделей бизнес-процессов), BPEL (Business Process Execution Language , формализация исполнения взаимодействия между Web-сервисами) и XPDL (XML Process Description Language, www.wfmc.org, спецификация по обмену моделями бизнес-процессов между различными приложениями) были разработаны различными группами и для различных целей и, к сожалению, адекватно не взаимодополняют друг друга.

Ситуация усугубляется тем, что за различными форматами стоят различные производители и каждый старается «протолкнуть» на рынок свое решение. Как это неоднократно повторялось, в подобной борьбе интересы конечного потребителя мало принимаются во внимание - сегодня нет достаточно мощной организации, представляющей интересы конечного потребителя BPM (по аналогии с группой стандартов для HTML , успех которой объясняется принятием всеми разработчиками Web-браузеров единого теста ACID3 для сравнения своих продуктов). Идеальной ситуацией в BPM было бы стандартное определение семантики исполнения для BPMN-подобного описания бизнес-процессов. Именно стандартная семантика исполнения гарантировала бы одинаковую интерпретацию бизнес-процессов любым ПО. Дополнительно такое описание должно позволять адаптацию степени описания бизнес-процессов для нужд конкретного потребителя (например, пользователь видит грубую диаграмму, аналитик - более подробную и т.п.).

Все это не означает, что BPEL или XPDL станут ненужными - их использование будет скрыто, как это происходит в сфере подготовки электронных документов. Один и тот же электронный документ может одновременно существовать в XML, PDF, PostScript и т.п., но только один основной формат (XML) используется для модификации документа.

Дисциплина BPM в культуре предприятия

Кроме процессов и служб, бизнес-системы предприятия работают с такими дополнительными артефактами, как:

события (events) - явления, происшедшие в пределах и вне границ предприятия, на которые возможна некая реакция бизнес-системы, например, при получении заказа от клиента необходимо начать бизнес-процесс обслуживания;

объекты (data and documents objects) - формальные информационные описания реальных вещей и людей, образующих бизнес; это информация на входе и выходе бизнес-процесса, например, бизнес-процесс обслуживания заказа получает на входе собственно формуляр заказа и информацию о клиенте, а на выходе формирует отчет о выполнении заказа;

деятельности (activities) - мелкие работы, преобразующие объекты, например автоматические деятельности типа проверки кредитной карты клиента или деятельности, осуществляемые человеком, такие как визирование документа руководством;

правила (rules) - ограничения и условия, при которых функционирует предприятие, например, выдача кредита на определенную сумму должна утверждаться генеральным директором банка;

роли (roles) - понятия, представляющие соответствующие навыки или обязанности, требуемые для выполнения определенных действий, например, только менеджер высшего звена может подписать конкретный документ;

аудиторские следы (audit trails) - информация о выполнении конкретного бизнес-процесса, например, кто сделал, что и с каким результатом;

основные индикаторы производительности (Key Performance Indicator, KPI) - ограниченное число показателей, измеряющих степень достижения поставленных целей.

Рис. 4 иллюстрирует распределение артефактов между различными частями бизнес-системы предприятия. Выражение «процессы (как шаблоны)» означает абстрактные описания (модели или планы) процессов;

выражение «процессы (как экземпляры)» означает фактические результаты выполнения этих шаблонов. Обычно шаблон используется для создания многих экземпляров (подобно незаполненному бланку, который многократно копируется для заполнения разными людьми). Выражение «службы (как интерфейсы)» означает формальные описания служб, которые доступны для их потребителей; выражение «службы (как программы)» означает средства выполнения служб - такие средства обеспечиваются поставщиками служб.

Для успешной работы со всей сложной совокупностью взаимозависимых артефактов у любого процессно-управляемого предприятия есть своя собственная BPM-система - это портфолио всех бизнес-процессов предприятия, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио. Другими словами, BPM-система предприятия ответственна за синергетическое функционирование различных частей бизнес-системы предприятия.

BPM-система, как правило, не идеальна (например, некоторые процессы могут существовать лишь на бумаге, а некоторые детали «живут» только в умах определенных людей), но она существует. Например, любую реализацию ISO 9000 можно рассматривать как пример BPM-системы.

Улучшение BPM-системы предприятия, помимо чисто технических аспектов, должно учитывать социо-технические вопросы. У BPM-системы предприятия есть много заинтересованных лиц, каждое из которых решает свои задачи, воспринимает BPM-дисциплину своим образом и работает со своими артефактами. Для успешного развития BPM-системы предприятия необходимо обратить особое внимание на проблемы всех заинтересованных лиц и заранее объяснить им, как улучшение BPM-системы предприятия изменит их работу к лучшему. Крайне важно достигнуть единого понимания всех артефактов среди всех заинтересованных лиц.

Специализированное ПО для реализации BPM-систем

Растущая популярность и большой потенциал BPM вызвали появление нового класса корпоративного ПО - BPM suite, или BPMS, содержащего следующие типичные компоненты (рис. 5):

Инструмент моделирования (Process modelling tool) - графическая программа для манипулирования такими артефактами, как события, правила, процессы, активности, службы и т.д.;

Инструмент тестирования (Process testing tool) - среда функционального тестирования, которое позволяет «исполнять» процесс по различным сценариям;

Хранилище шаблонов (Process template repository) - база данных шаблонов бизнес-процессов с поддержкой различных версий одного и того же шаблона;

Исполнитель процессов (Process execution engine);

Хранилище экземпляров (Process instance repository) - база данных для выполняемых и уже выполненных экземпляров бизнес-процессов;

Список работ (Work list) - интерфейс между BPM suite и пользователем, выполняющим некоторые активности в рамках одного или нескольких бизнес-процессов;

Приборная панель (Dashboard) - интерфейс оперативного контроля за исполнением бизнес-процессов;

Инструмент анализа (Process analysis tool) - среда для изучения тенденции исполнения бизнес-процессов;

Инструмент имитационного моделирования (Process simulation tool) - среда для тестирования производительности бизнес-процессов.

Необходимость взаимодействия между BPM suite и корпоративным ПО, которое поддерживает другие артефакты, вызвала появление нового класса корпоративного ПО - Business Process Platform (BPP). Типичные технологии BPP (рис. 6):

Business Event Management (BEM) - анализ бизнес-событий в режиме реального времени и запуск соответствующих бизнес-процессов (BEM связан с Complex Event Processing (CEP) и Event Driven Architecture (EDA));

Business Rules Management (BRM) - явное и формальное кодирование бизнес-правил, которые могут модифицироваться пользователями;

Master Data Management (MDM) - упрощение работы со структурированными данными за счет устранения хаоса при использовании одних и тех же данных;

Enterprise Content Management (ECM) - управление корпоративной информацией, предназначенной для человека (обобщение понятия документ);

Configuration Management Data Base (CMDB) - централизованное описание всей информационно-вычислительной среды предприятия, используемое для привязки BPM к информационно-вычислительным ресурсам предприятия;

Role-Based Access Control (RBAC) - управления доступом к информации с целью эффективного разделения контрольных и исполнительских полномочий (separation of duty);

Business Activity Monitoring (BAM) - оперативный контроль функционирования предприятия;

Business Intelligence (BI) - анализ характеристик и тенденций работы предприятия;

Service-Oriented Architecture (SOA) - архитектурный стиль для построения сложных программных систем в виде набора универсально доступных и взаимозависимых служб, который используется для реализации, выполнения и управления службами;

Enterprise Service Bus (ESB) - среда коммуникаций между службами в рамках SOA.

Таким образом, дисциплина BPM способна обеспечить единое, формальное и выполнимое описание бизнес-процессов, которое может использоваться в различных инструментах BPM suite, причем реальные данные собираются во время выполнения бизнес-процессов. Вместе с тем высокая гибкость BPM-системы предприятия не гарантируется автоматически после покупки BPM suite или BPP - способность конкретной BPM-системы развиться в необходимом темпе должна проектироваться, реализовываться и постоянно контролироваться. Как и здоровье человека, все это нельзя купить.

BPM в архитектуре предприятия

Необходимость вовлечения практически всего корпоративного ПО в единую логику улучшения BPM-системы предприятия поднимает вопрос о роли и месте BPM в архитектуре предприятия (Enterprise Architecture, EA). EA является на сегодня устоявшейся практикой ИТ-департаментов по упорядочению информационно-вычислительной среды предприятия. В основе EA лежат следующие правила:

Текущая ситуация с информационно-вычислительной средой предприятия тщательно документируется как исходная точка as-is;

Желаемая ситуация документируется как конечная точка to-be;

Строится и исполняется долгосрочный план по переводу информационно-вычислительной среды предприятия из одной точки в другую.

Все это, казалась бы, вполне разумно, но сразу видна разница с подходом, предусматривающим небольшие улучшения, который лежит в основе процессного управления. Как совместить эти два противоположных подхода?

Дисциплина BPM может решить основную проблему EA - дать объективную оценку производственно-хозяйственных возможностей (а не только информационно-вычислительных) того, что будет в точке to-be. Несмотря на то что EA описывает полную номенклатуру артефактов предприятия (его генотип), она не может достоверно сказать, какие изменения в этом генотипе влияют на конкретные производственно-хозяйственные характеристики предприятия, то есть на фенотип предприятия (cовокупность характеристик, присущих индивиду на определенной стадии развития).

Со своей стороны, дисциплина BPM структурирует взаимозависимости между артефактами в виде явных и исполняемых моделей (бизнес-процесс - это пример взаимозависимости между такими артефактами, как события, роли, правила и т.п.). Наличие таких исполняемых моделей позволяет с некоторой степенью достоверности оценить производственно-хозяйственные характеристики предприятия при изменении генотипа предприятия.

Естественно, чем больше взаимозависимостей между артефактами смоделировано и чем достовернее эти модели, тем точнее такие оценки. Потенциально симбиоз номенклатуры артефактов предприятия и формально определенных взаимозависимостей между ними дает исполняемую модель предприятия на конкретный момент времени. Если строить такие исполняемые модели на единых принципах (например, krislawrence.com), то появляется возможность для сравнения эффекта от применения различных стратегий развития предприятия и появления более систематических и предсказуемых технологий по преобразованию одних исполняемых моделей в другие.

В некотором смысле комбинация EA+BPM может стать своего рода навигатором, который обеспечивает руководство и практическую помощь в развитии бизнеса и ИТ при реализации генеральной линии предприятия.

Не секрет, что сегодня производители ПО определяют и развивают BPM по-разному. Однако, более перспективный путь развития BPM - это BPM, ориентированный на нужды конечных потребителей, и эталонная модель BPM - первый шаг по созданию единого понимания BPM среди всех заинтересованных лиц.

Предлагаемая в статье эталонная модель основана на практическом опыте автора по проектированию, разработке и сопровождению различных корпоративных решений. В частности, эта модель использовалась для автоматизации ежегодного производства более 3 тыс. сложных электронных продуктов со средним временем подготовки продукта в несколько лет. В результате обслуживание и развитие этой производственной системы потребовали в несколько раз меньше ресурсов, чем при традиционном подходе. n

Александр Самарин ([email protected]) - корпоративный архитектор ИТ-департамента правительства кантона Женева (Швейцария).

Process Frameworks для BPM

Подход к реализации технологий управления бизнес-процессами, упрощающий внедрение BPM-систем, подразумевает четкое определение бизнес-задачи и соответствующих ей бизнес-процессов; реализацию этих процессов за срок не более трех месяцев с целью демонстрации ценности данного подхода; дальнейшее расширение реализации на основные бизнес-задачи. Однако главная трудность на этом пути - недопонимание и отсутствие согласованности между бизнес- и ИТ-подразделениями. Значительно упростить проект внедрения и сократить затраты позволяют специализированные референсные модели (Process Frameworks).

Референсная модель - пакет аналитических и программных ресурсов, состоящий из описания и рекомендаций по организации высокоуровневой структуры бизнес-процесса, набора атрибутов и метрик оценки эффективности выполнения, а также программных модулей, созданных для быстрого построения прототипа бизнес-процесса для последующей его адаптации под специфику конкретной компании.

Референсные модели помогают в определении и установке требований и позволяют наладить бизнес-процессы, они основаны на отраслевых стандартах и включают в себя отраслевой опыт. Для типовых процессов референсные модели способны помочь при выборе и моделировании основных последовательностей работы, определении ключевых показателей эффективности (КPI) и параметров, позволяющих оценить результативность в ключевых областях, а также при управлении деятельностью и решением задач, анализе исходных причин и обработке исключительных случаев.

В структуру типичной референсной модели входят: рекомендации и описание предметной области; элементы композитных пользовательский интерфейсов (экранные формы и логически связные в цепочки портлеты); оболочки сервисов для быстрой реализации доступа к бизнес данным; примеры типовых бизнес-правил; ключевые показатели эффективности и элементы для их анализа; исполняемые модели процессов; модели данных и атрибуты процесса; адаптации к законодательной базе и специфике бизнеса в конкретной стране; рекомендации по этапам развертывания и реализации процессов. Такой набор ресурсов позволят быстрее адаптироваться к реализации процессного подхода в рамках конкретной системы управления бизнес-процессами, сократить время итераций цикла разработки, тестового исполнения и анализа процессов. При этом достигается максимальное соответствие технической реализации и существующей бизнес-задачи.

Однако, как отмечают аналитики AMR Research, «технологии и методы сами по себе не способны обеспечить каких-либо преимуществ - «больше» не всегда значит «лучше». Некоторые компании применяют множество различных решений, однако эффективность от этого только падает. Важна грамотность применения таких технологий». В референсных моделях в качестве основы используются принятые в отрасли стандарты и опыт компании Software AG по созданию эталонной модели для определения требований клиентов. На практике эта модель становится отправной точкой, с помощью которой клиенты могут создать нужную модель.

Process Framework, например, для бизнес-процесса обработки заказов, включает в себя базовую модель процесса со схемами действий для различных пользователей и ролей, избранные KPI из модели SCOR (The Supply-Chain Operations Reference-model) для процесса в целом и отдельных этапов, правила поддержки разных последовательностей обработки, например с учетом сегмента клиентов, целевые показатели для различных сегментов клиентов, типов продукции и регионов, а также панели индикации, помогающие контролировать особые ситуации.

Process Framework позволяет акцентировать внимание на необходимости и возможности коррекции KPI для конкретных групп клиентов и их конфигурирования с учетом появления новых товаров, выхода на новые регионы или сегменты рынка. Подобная информация позволит руководителям, отвечающим за цепочки поставок, торговые операции, логистику и производство, улучшить контроль над конкретной деятельностью, а руководителям ИТ-отделов быстро оценить реальную работоспособность ИТ-систем, поддерживающих обработку заказов.

Владимир Аленцев ([email protected]) - консультант по BPM и SOA , представительство Software AG в России и СНГ (Москва).

Только начали работать сетевым администратором? Не хотите оказаться сбитым с толку? Наша статья вам пригодится. Слышали, как проверенный временем администратор говорит о сетевых неполадках и упоминает какие-то уровни? Может вас когда-нибудь спрашивали на работе, какие уровни защищены и работают, если вы используете старый брандмауэр? Чтобы разобраться с основами информационной безопасности, нужно понять принцип иерархии модели OSI. Попробуем увидеть возможности данной модели.

Уважающий себя системный администратор должен хорошо разбираться в сетевых терминах

В переводе с английского - базовая эталонная модель взаимодействия открытых систем. Точнее, сетевая модель стека сетевых протоколов OSI/ISO. Введена в 1984 году в качестве концептуальной основы, разделившей процесс отправки данных во всемирной паутине на семь несложных этапов. Она не является самой популярной, так как затянулась разработка спецификации OSI. Стек протоколов TCP/IP выгоднее и считается основной используемой моделью. Впрочем, у вас есть огромный шанс столкнуться с моделью OSI на должности системного администратора или в IT-сфере.

Создано множество спецификаций и технологий для сетевых устройств. В таком разнообразии легко запутаться. Именно модель взаимодействия открытых систем помогает понимать друг друга сетевым устройствам, использующим различные методы общения. Заметим, что наиболее полезна OSI для производителей программного и аппаратного обеспечения, занимающихся проектированием совместимой продукции.

Спросите, какая же в этом польза для вас? Знание многоуровневой модели даст вам возможность свободного общения с сотрудниками IT-компаний, обсуждение сетевых неполадок уже не будет гнетущей скукой. А когда вы научитесь понимать, на каком этапе произошёл сбой, сможете легко находить причины и значительно сокращать диапазон своей работы.

Уровни OSI

Модель содержит в себе семь упрощённых этапов:

• Физический.
• Канальный.
• Сетевой.
• Транспортный.
• Сеансовый.
• Представительский.
• Прикладной.

Почему разложение на шаги упрощает жизнь? Каждый из уровней соответствует определённому этапу отправки сетевого сообщения . Все шаги последовательны, значит, функции выполняются независимо, нет необходимости в информации о работе на предыдущем уровне. Единственная необходимая составляющая - способ получения данных с предшествующего шага, и каким образом пересылается информация на последующий шаг.

Перейдём к непосредственному знакомству с уровнями.

Физический уровень

Главная задача первого этапа - пересылка битов через физические каналы связи. Физические каналы связи - устройства, созданные для передачи и приёма информационных сигналов. К примеру, оптоволокно, коаксиальный кабель или витая пара. Пересылка может проходить и через беспроводную связь. Первый этап характеризуется средой передачи данных: защитой от помех, полосой пропускания, волновым сопротивлением. Так же задаются качества электрических конечных сигналов (вид кодирования, уровни напряжения и скорость передачи сигнала) и подводятся к стандартным типам разъёмов, назначаются контактные соединения.

Функции физического этапа осуществляются абсолютно на каждом устройстве, подключённом к сети. Например, сетевой адаптер реализовывает эти функции со стороны компьютера. Вы могли уже столкнуться с протоколами первого шага: RS -232, DSL и 10Base-T, определяющими физические характеристики канала связи.

Канальный уровень

На втором этапе связываются абстрактный адрес устройства с физическим устройством, проверяется доступность среды передачи. Биты сформировываются в наборы - кадры. Основная задача канального уровня - выявление и правка ошибок. Для корректной пересылки перед и после кадра вставляются специализированные последовательности битов и добавляется высчитанная контрольная сумма . Когда кадр достигает адресата, вновь высчитывается контрольная сумма, уже прибывших данных, если она совпадает с контрольной суммой в кадре, кадр признаётся правильным. В ином случае появляется ошибка, исправляемая через повторную передачу информации.

Канальный этап делает возможным передачу информации, благодаря специальной структуре связей. В частности, через протоколы канального уровня работают шины, мосты, коммутаторы. В спецификации второго шага входят: Ethernet, Token Ring и PPP. Функции канального этапа в компьютере исполняют сетевые адаптеры и драйверы к ним.

Сетевой уровень

В стандартных ситуациях функций канального этапа не хватает для высококачественной передачи информации. Спецификации второго шага могут передавать данные лишь между узлами с одинаковой топологией, к примеру, дерева. Появляется необходимость в третьем этапе. Нужно образовать объединённую транспортную систему с разветвлённой структурой для нескольких сетей, обладающих произвольной структурой и различающихся методом пересылки данных.

Если объяснить по-другому, то третий шаг обрабатывает интернет-протокол и исполняет функцию маршрутизатора: поиск наилучшего пути для информации. Маршрутизатор - устройство, собирающее данные о структуре межсетевых соединений и передающее пакеты в сеть назначения (транзитные передачи - хопы). Если вы сталкиваетесь с ошибкой в IP-адресе, то это проблема, возникшая на сетевом уровне. Протоколы третьего этапа разбиваются на сетевые, маршрутизации или разрешения адресов: ICMP, IPSec, ARP и BGP.

Транспортный уровень

Чтобы данные дошли до приложений и верхних уровней стека, необходим четвёртый этап. Он предоставляет нужную степень надёжности передачи информации. Значатся пять классов услуг транспортного этапа. Их отличие заключается в срочности, осуществимости восстановления прерванной связи, способности обнаружить и исправить ошибки передачи. К примеру, потеря или дублирование пакетов.

Как выбрать класс услуг транспортного этапа? Когда качество каналов транспортировки связи высокое, адекватным выбором окажется облегчённый сервис. Если каналы связи в самом начале работают небезопасно, целесообразно прибегнуть к развитому сервису, который обеспечит максимальные возможности для поиска и решения проблем (контроль поставки данных, тайм-ауты доставки). Спецификации четвёртого этапа: TCP и UDP стека TCP/IP, SPX стека Novell.

Объединение первых четырёх уровней называется транспортной подсистемой. Она сполна предоставляет выбранный уровень качества.

Сеансовый уровень

Пятый этап помогает в регулировании диалогов. Нельзя, чтобы собеседники прерывали друг друга или говорили синхронно. Сеансовый уровень запоминает активную сторону в конкретный момент и синхронизирует информацию, согласуя и поддерживая соединения между устройствами. Его функции позволяют возвратиться к контрольной точке во время длинной пересылки и не начинать всё заново. Также на пятом этапе можно прекратить соединение, когда завершается обмен информацией. Спецификации сеансового уровня: NetBIOS.

Представительский уровень

Шестой этап участвует в трансформации данных в универсальный распознаваемый формат без изменения содержания. Так как в разных устройствах утилизируются различные форматы, информация, обработанная на представительском уровне, даёт возможность системам понимать друг друга, преодолевая синтаксические и кодовые различия. Кроме того, на шестом этапе появляется возможность шифровки и дешифровки данных, что обеспечивает секретность. Примеры протоколов: ASCII и MIDI, SSL.

Прикладной уровень

Седьмой этап в нашем списке и первый, если программа отправляет данные через сеть. Состоит из наборов спецификаций, через которые юзер , Web-страницам. Например, при отправке сообщений по почте именно на прикладном уровне выбирается удобный протокол. Состав спецификаций седьмого этапа очень разнообразен. К примеру, SMTP и HTTP, FTP, TFTP или SMB.

Вы можете услышать где-нибудь о восьмом уровне модели ISO. Официально, его не существует, но среди работников IT-сферы появился шуточный восьмой этап. Всё из-за того, что проблемы могут возникнуть по вине пользователя, а как известно, человек находится у вершины эволюции, вот и появился восьмой уровень.

Рассмотрев модель OSI, вы смогли разобраться со сложной структурой работы сети и теперь понимаете суть вашей работы. Всё становится довольно просто, когда процесс разбивается на части!

Понятие эталонной модели широко используется в связи и информатике.

• Эталонная модель (Reference model, master model) в системной и программной области — это модель чего-то, что объединяет основная цель или идея, и может рассматриваться в качестве эталона для различных целей [Википедия-англ].

• Эталонная модель — это абстрактное представление понятий и отношений между ними в некоторой проблемной области. На основе эталонной строятся более конкретные и детально описываемые модели, в итоге воплощенные в реально существующие объекты и механизмы [Википедия-рус].
  

• Эталонная модель (Reference Model) — это абстрактная структура (framework) для понимания существенных связей между объектами некоторого окружения, что в дальнейшем позволяет разрабатывать конкретные архитектуры, используя определенные стандарты или спецификации, поддерживаемые этим окружением. Эталонная модель содержит минимальный набор унифицированных концепций, аксиом и связей, относящихся к конкретной области проблем, и независима от определенных стандартов, технологий, реализации или других конкретных деталей .

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

  Есть много применений эталонной модели. Один из вариантов использования заключается в создании стандартов для объектов, которые содержатся в модели, и их взаимодействия друг с другом. При разработке конкретных прикладных стандартов связи и систем производится сравнение их архитектуры с стандартной моделью. При таком подходе работа специалистов, которым нужно создавать или анализировать объекты систем связи, которые ведут себя в соответствии со стандартом, осуществляется намного проще.
  

• В качестве примера стандарта эталонной модели можно назвать сетевую эталонную модель взаимодействия открытых систем (ЭМВОС) OSI (Open Systems Interconnection Basic Reference Model ) Международной организации по стандартизации ISO – основную модель архитектур для систем передачи данных, котора является хорошим средством для анализа и изучения современной стандартов и технологий связи.
  

Семиуровневая модель OSI

Универсальный характер классической сетевой семиуровневой эталонной модели OSI дает возможность создавать на ее основе модели для конкретных стандартов, которые также называют эталонными. Например, на рис…. приведена эталонная модель DECT, ключевые функции которой структуированы только на трех нижних уровнях модели OSI: сетевом, канальном и физическом.

Эталонная модель DECT

1. Reference Model for Service Oriented. Architecture 1.0. Committee Specification 1, 2 August 2006. http://www.oasis-open.org/

Для согласования работы устройств сети от разных производителей, обеспечения взаимодействия сетей, которые используют различную среду распространения сигнала создана эталонная модель взаимодействия открытых систем (ВОС). Эталонная модель построена по иерархическому принципу. Каждый уровень обеспечивает сервис вышестоящему уровню и пользуется услугами нижестоящего уровня.

Обработка данных начинается с прикладного уровня. После этого, данные проходят через все уровни эталонной модели, и через физический уровень отправляются в канал связи. На приеме происходит обратная обработка данных.

В эталонной модели OSI вводятся два понятия: протокол и интерфейс .

Протокол – это набор правил, на основе которых взаимодействуют уровни различных открытых систем.

Интерфейс – это совокупность средств и методов взаимодействия между элементами открытой системы.

Протокол определяет правила взаимодействия модулей одного уровня в разных узлах, а интерфейс – модулей соседних уровней в одном узле.

Всего существует семь уровней эталонной модели OSI. Стоит отметить, что в реальных стеках используется меньше уровней. Например, в популярном TCP/IP используется всего четыре уровня. Почему так? Объясним чуть позже. А сейчас рассмотрим каждый из семи уровней в отдельности.

Уровни модели OSI:

• Физический уровень. Определяет вид среды передачи данных, физические и электрические характеристики интерфейсов, вид сигнала. Этот уровень имеет дело с битами информации. Примеры протоколов физического уровня: Ethernet, ISDN, Wi-Fi.
• Канальный уровень. Отвечает за доступ к среде передачи, исправление ошибок, надежную передачу данных. На приеме полученные с физического уровня данные упаковываются в кадры после чего проверяется их целостность. Если ошибок нет, то данные передаются на сетевой уровень. Если ошибки есть, то кадр отбрасывается и формируется запрос на повторную передачу. Канальный уровень подразделяется на два подуровня: MAC (Media Access Control) и LLC (Locical Link Control). MAC регулирует доступ к разделяемой физической среде. LLC обеспечивает обслуживание сетевого уровня. На канальном уровне работают коммутаторы. Примеры протоколов: Ethernet, PPP.
• Сетевой уровень. Его основными задачами являются маршрутизация – определение оптимального пути передачи данных, логическая адресация узлов. Кроме того, на этот уровень могут быть возложены задачи по поиску неполадок в сети (протокол ICMP). Сетевой уровень работает с пакетами. Примеры протоколов: IP, ICMP, IGMP, BGP, OSPF).
• Транспортный уровень. Предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. Выполняет сквозной контроль передачи данных от отправителя до получателя. Примеры протоколов: TCP, UDP.
• Сеансовый уровень. Управляет созданием/поддержанием/завершением сеанса связи. Примеры протоколов: L2TP, RTCP.
• Представительский уровень. Осуществляет преобразование данных в нужную форму, шифрование/кодирование, сжатие.
• Прикладной уровень. Осуществляет взаимодействие между пользователем и сетью. Взаимодействует с приложениями на стороне клиента. Примеры протоколов: HTTP, FTP, Telnet, SSH, SNMP.

После знакомства со эталонной моделью, рассмотрим стек протоколов TCP/IP.

В модели TCP/IP определено четыре уровня. Как видно из рисунка выше – один уровень TCP/IP может соответствовать нескольким уровням модели OSI.

Уровни модели TCP/IP:

• Уровень сетевых интерфейсов. Соответствует двум нижним уровням модели OSI: канальному и физическому. Исходя из этого, понятно, что данный уровень определяет характеристики среды передачи (витая пара, оптическое волокно, радиоэфир), вид сигнала, способ кодирования, доступ к среде передачи, исправление ошибок, физическую адресацию (MAC-адреса). В модели TCP/IP на этом уровне работает протокол Ethrnet и его производные (Fast Ethernet, Gigabit Ethernet).
• Уровень межсетевого взаимодействия. Соответствует сетевому уровню модели OSI. Берет на себя все его функции: маршрутизацию, логическую адресация (IP-адреса). На данном уровне работает протокол IP.
• Транспортный уровень. Соответствует транспортному уровню модели OSI. Отвечает за доставку пакетов от источника до получателя. На данному уровне задействуется два протокола: TCP и UDP. TCP является более надежным, чем UDP за счет создания предварительного соединения, запросов на повторную передачу при возникновении ошибок. Однако, в то же время, TCP более медленный, чем UDP.
• Прикладной уровень. Его главная задача – взаимодействие с приложениями и процессами на хостах. Примеры протоколов: HTTP, FTP, POP3, SNMP, NTP, DNS, DHCP.

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

Рассмотрим на конкретном примере. Пусть мы хотим попасть с компьютера на сайт. Для этого наш компьютер должен подготовить http-запрос на получение ресурсов веб-сервера, на котором хранится нужная нам страница сайта. На прикладном уровне к данным (Data) браузера добавляется HTTP-заголовок. Далее на транспортном уровне к нашему пакету прибавляется TCP-заголовок, содержащий номера портов отправителя и получателя (80 порт – для HTTP). На сетевом уровне формируется IP-заголовок, содержащий IP-адреса отправителя и получателя. Непосредственно перед передачей, на канальном уровне добавляется Ethrnet-заголовок, который содержит физические (MAC-адреса) отправителя и получателя. После всех этих процедур пакет в виде битов информации передается по сети. На приеме происходит обратная процедура. Web-сервер на каждом уровне будет проверять соответствующий заголовок. Если проверка прошла удачно, то заголовок отбрасывается и пакет переходит на верхний уровень. В противном случае весь пакет отбрасывается.

Подписывайтесь на нашу

Эталонная модель OSI

Это описательная схема сети; ее стандарты гарантируют высокую совместимость и способность к взаимодействию различных типов сетевых технологий. Кроме того, она иллюстрирует процесс перемещения информации по сетям. Модель OSI описывает, каким образом информация проделывает путь через сетевую среду (например, провода) от одной прикладной программы (например, программы обработки таблиц) к другой прикладной программе, находящейся в другом подключенном к сети компьютере.

Эталонная модель OSI делит задачу перемещения информации между компьютерами через сетевую среду на семь менее крупных и, следовательно, более легко разрешимых подзадач. Каждая из этих семи подзадач выбрана потому, что она относительно автономна и, следовательно, ее легче решить без чрезмерной опоры на внешнюю информацию. Такое разделение на уровни называется иерархическим представлением. Каждый уровень соответствует одной из семи подзадач...

Поскольку нижние уровни (с 1 по 3) модели OSI управляют физической доставкой сообщений по сети, их часто называют уровнями среды передачи данных (media layers). Верхние уровни (с 4 по 7) модели OSI обеспечивают точную доставку данных между компьютерами в сети, поэтому их часто называют уровнями хост-машины (host layers).

Прикладной уровень (уровень 7) - это самый близкий к пользователю уровень OSI. Он отличается от других уровней тем, что не обеспечивает услуг ни одному из других уровней OSI. Он обеспечивает услугами прикладные процессы, лежащие за пределами масштаба модели OSI. Примерами таких прикладных процессов могут служить процессы передачи речевых сигналов, базы данных, текстовые процессоры и т.д.

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

Проще говоря этот уровень отвечает за доступ приложений в сеть. Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью.

К числу наиболее распространенных протоколов верхних уровней относятся:

FTP - протокол переноса файлов

TFTP - упрощенный протокол переноса файлов

X.400 - электронная почта

SMTP - простой протокол почтового обмена

CMIP - общий протокол управления информацией

SNMP - простой протокол управления сетью

NFS - сетевая файловая система

FTAM - метод доступа для переноса файлов

Представительный уровень (уровень 6) отвечает за то, чтобы информация, посылаемая из прикладного уровня одной системы, была читаемой для прикладного уровня другой системы. При необходимости представительный уровень осуществляет трансляцию между множеством форматов представления информации путем использования общего формата представления информации.

Этот уровень занят не только форматом и представлением фактических данных пользователя, но также структурами данных, которые используют программы. Поэтому кроме трансформации формата фактических данных (если она необходима), представительный уровень согласует синтаксис передачи данных для прикладного уровня.

Сеансовый уровень (уровень 5) устанавливает, управляет и завершает сеансы взаимодействия между прикладными задачами. Сеансы состоят из диалога между двумя или более объектами представления. Сеансовый уровень синхронизирует диалог между объектами представительного уровня и управляет обменом информации между ними.

Кроме того, предоставляет средства для отправки информации, класса услуг и уведомления в исключительных ситуациях о проблемах сеансового, представительного и прикладного уровней.

Транспортный уровень (уровень 4) Граница между сеансовым и транспортным уровнями может быть представлена как граница между протоколами высших (прикладных) уровней и протоколами низших уровней. В то время как прикладной, представительный и сеансовый уровни заняты прикладными вопросами, четыре низших уровня решают проблемы транспортировки данных.

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

Проще говоря транспортный уровень делит потоки информации на достаточно малые фрагменты (пакеты) для передачи их на сетевой уровень.

Наиболее распространенные протоколы транспортного уровня включают:

TCP - протокол управления передачей

NCP - Netware Core Protocol

SPX - упорядоченный обмен пакетами

TP4 - протокол передачи класса 4

Сетевой уровень (уровень 3) - это комплексный уровень, который обеспечивает возможность соединения и выбор маршрута между двумя конечными системами.

Поскольку две конечные системы, желающие организовать связь, может разделять значительное географическое расстояние и множество подсетей, сетевой уровень является доменом маршрутизации. Протоколы маршрутизации выбирают оптимальные маршруты через последовательность соединенных между собой подсетей. Традиционные протоколы сетевого уровня передают информацию вдоль этих маршрутов.

Другими словами сетевой уровень отвечает за деление пользователей на группы. На этом уровне происходит маршрутизация пакетов на основе преобразования MAC-адресов в сетевые адреса. Сетевой уровень обеспечивает также прозрачную передачу пакетов на транспортный уровень.

Наиболее часто на сетевом уровне используются протоколы:

IP - протокол Internet

IPX - протокол межсетевого обмена

X.25 (частично этот протокол реализован на уровне 2)

CLNP - сетевой протокол без организации соединений

Канальный уровень (уровень 2) (формально называемый информационно-канальным уровнем) обеспечивает надежный транзит данных через физический канал. Выполняя эту задачу, канальный уровень решает вопросы физической адресации (в противоположность сетевой или логической адресации), топологии сети, линейной дисциплины (каким образом конечной системе использовать сетевой канал), уведомления об ошибках, упорядоченной доставки блоков данных и управления потоком информации.

Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде. (Он же IEEE 802.1 - задает стандарты управления сетью на MAC-уровне, включая алгоритм Spanning Tree. Этот алгоритм используется для обеспечения единственности пути (отсутствия петель) в многосвязных сетях на основе мостов и коммутаторов с возможностью его замены альтернативным путем в случае выхода из строя.)

Наиболее часто используемые на уровне 2 протоколы включают:

HDLC для последовательных соединений

IEEE 802.2 LLC (тип I и тип II) обеспечивают MAC для сред 802.x

Физический уровень (уровень 1) определяет электротехнические, механические, процедурные и функциональные характеристики установления, поддержания и разъединения физического канала между конечными системами. Спецификации физического уровня определяют такие характеристики, как величины напряжений, параметры синхронизации, скорость передачи физической информации, максимальные расстояния передачи информации, физические соединители и другие аналогичные характеристики.

Этот уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включаютя:

Тип кабелей и разъемов

Разводку контактов в разъемах

Схему кодирования сигналов для значений 0 и 1

К числу наиболее распространенных спецификаций физического уровня относятся:

EIA-RS-232-C, CCITT V.24/V.28 - механические/электрические характеристики несбалансированного последовательного интерфейса.

EIA-RS-422/449, CCITT V.10 - механические, электрические и оптические характеристики сбалансированного последовательного интерфейса.

IEEE 802.3 -- Ethernet

IEEE 802.5 -- Token ring

Физической средой в различных телекоммуникационных системах могут быть самые разнообразные средства от простейшей пары проводов до сложной системы передачи синхронной цифровой иерархии.

Чтобы понять структуру и принципы функционирования сети, необходимо уяснить, что любой обмен данными в сети осуществляется от источника к получателю. Информацию, посланную в сеть, называют данными, или пакетами данных. Если один компьютер (источник) хочет послать данные другому компьютеру (получателю), то данные

сначала должны быть собраны в пакеты в процессе инкапсуляции; который перед отправкой в сеть погружает их в заголовок конкретного протокола. Этот процесс можно сравнить с подготовкой бандероли к отправке - обернуть содержимое бумагой, вложить в транспортный конверт, указать адрес отправителя и получателя, наклеить марки и бросить в почтовый ящик.

При выполнении сетями услуг пользователям, поток и вид упаковки информации изменяются.

Например..пять этапов преобразования:

1. Формирование данных. Когда пользователь посылает сообщение электронной почтой, алфавитно-цифровые символы сообщения преобразовываются в данные, которые могут перемещаться в сетевом комплексе.

2. Упаковка данных для сквозной транспортировки. Для передачи через сетевой комплекс данные соответствующим образом упаковываются. Благодаря использованию сегментов, транспортная функция гарантирует надежное соединение участвующих в обмене