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

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

Это мы видим на примере СТО и ОТО, превратившихся в своеобразный вид религии, управляющей наукой и общественным мнением. Никакое количество фактов, противоречащих им, не может преодолеть формулу Эйнштейна: "Если факт не соответствует теории - измените факт" (В другом варианте " - Факт не соответствует теории? - Тем хуже для факта").

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

Эксперимент на то и эксперимент, что он есть не изощрение мысли, а проверка мысли. Непротиворечивая внутри себя мысль не может сама себя проверить. Это доказано Куртом Гёделем.

Эталонная модель OSI являет собой 7-уровневую сетевую иерархию созданную международной организацией по стандартам (ISO). Представленная модель на рис.1 имеет 2 различных модели:

• горизонтальная модель на основе протоколов, реализующую взаимодействие процессов и ПО на разных машинах
• вертикальную модель на основе услуг, реализуемых соседними уровнями друг другу на одной машине

В вертикальной — соседние уровни меняются информацией с помощью интерфейсов API. Горизонтальная модель требует общий протокол для обмена информацией на одном уровне.

Рисунок — 1

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

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

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

• тип разъемов и кабелей
• разводка контактов в разъемах
• схема кодирования сигналов 0 и 1

Самые распространенные виды спецификаций на этом уровне:

• — параметры несбалансированного последовательного интерфейса
• — параметры сбалансированного последовательного интерфейса
• IEEE 802.3 —
• IEEE 802.5 —

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

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

На этом канале реализована транспортировка и прием кадров данных. Уровень реализует запросы сетевого уровня и использует физический уровень для приема и передачи. Спецификации IEEE 802.x делят этот уровень на два подуровня управление логическим каналом (LLC) и управление доступом к среде (MAC). Самые распространенные протоколы на этом уровне:

• IEEE 802.2 LLC и MAC
• Ethernet
• Token Ring

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

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

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

Рисунок — 2

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

На этом уровне потоки информации делятся на пакеты для передачи их на сетевом уровне. Самые распространенные протоколы этого уровня:

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

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

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

Уровень представления

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

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

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

• FTP/TFTP — протокол передачи файлов
• X 400 — электронная почта
• Telnet
• CMIP — управление информацией
• SNMP — управление сетью
• NFS — сетевая файловая система
• FTAM — метод доступа для переноса файлов

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

• Эталонная модель (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/

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

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

В 1984 году с целью упорядочения описания принципов взаимодействия устройств в сетях Международная организация по стандартизации(ISO) предложила семиуровневую эталонную модель «Взаимодействие Открытых Систем». Модель OSI является основой для разработки стандартов на взаимодействие систем. Существует 7 основных уровней модели OSI:

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

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

Эталонная модель определяет назначение каждого уровня и правила взаимодействия уровней (таблица ниже)

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

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

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

ПРОЦЕСС ПРЕОБРАЗОВАНИЯ ИНФОРМАЦИИ:

Протоколы и интерфейсы

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

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

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

В модели OSI различается два основных типа протоколов. В протоколах с установлением соединения (Connectionless- Oriented Network Service, CONS) перед обменом данными отправитель и получатель должны сначала установить соединение и, возможно, выбрать протокол, который они будут использовать. После завершения диалога они должны разорвать соединение.

Протоколы без предварительного установления соединения (Connectionless Network Service, CLNS) или диаграммные протоколы. Отправитель просто передает сообщения, когда оно готово.

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

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

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

Единственным типом оборудования, которое работает только на физическом уровне, являются повторители.

Fast Ethernet- является эволюционным развитием Ethernet. Данная таблица показывает, что основные отличия Fast Ethernet от Ethernet сосредоточены на физическом уровне.

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

Для технологии Fast Ethernet разработаны различные варианты физического уровня. Физический уровень состоит из трех подуровней: согласования, интерфейса, MII(Media Independent Interface-интерфейса, независящего от среды) и физического уровня. Физ.уровень обеспечивает кодирование данных, поступающих от подуровня МАС, для передачи их по физической среде определенного типа, синхронизацию передаваемых данных, а так же их прием и декодирование. Интерфейс MII поддерживает независимый от используемой физической среды способ обмена данными между подуровнем MAC и подуровнем PHY.Подуровень согласования нужен для того, чтобы согласовать работу подуровня MAC с интерфейсом MII.

Дальнейшее развитием стало Gigabit Ethernet, который обеспечивает взаимодействие между уровнем МАС и физическим уровнем. Этот интерфейс является расширением интерфейса MII и может поддерживать скорости передачи 10,100 и 1000 Мбит/c

Физический уровень разделен на 2 подуровня: независящий от среды(PHY) и зависящий от среды (PMD). Работу всех уровней контролирует протокол управления станцией STM (Station Management). Подуровень PMD обеспечивает передачу данных от одной станции к другой по конкретной физической среде, а подуровень PHY выполняет кодирование и декодирование данных, циркулирующих между подуровнем МАС и подуровнем PMD, а также обеспечивает тактирование информационных сигналов.

Физический уровень делиться на два подуровня: подуровень согласования с системой передачи (Transmission Convergence,TC) и подуровень физической среды (Physical Medium- PM). Подуровень ТС выполняет упаковку ячеек, поступающих с верхнего уровня модели АТМ, в передаваемые транспортные кадры. Подуровень физической среды регламентирует скорость передачи данных и отвечает за синхронизацию между передачей и приемом.

Существуют 3 организации, определяющие физический уровень технологии АТМ: ANSI, ITU/CCITT и форум АТМ.

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

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

1. физическую адресацию передаваемых сообщений

2. соблюдение правил использования физического канала

3. выявление неисправностей

4. управление потоками информации.

Вместо прямой адресации по мере прохождения ячеек с информацией через коммутаторы АТМ в заголовках ячеек происходит преобразование индетификаторов виртуальных путей и каналов. Добавляется также новая функция: мультиплексирование и демультиплексирование ячеек.

Для доступа к среде в локальных сетях используются два метода:

1.метод случайного доступа

2. метод маркерного доступа

1.Любая станция сети пытается получить доступ к каналу передачи в необходимый для нее момент времени. Если канал занят, станция повторяет попытки доступа до его освобождения(Ethernet)

2. Применяется в сетях Token Ring, ArcNet, FDDI и 100VG-AnyLan.Основан на передаче от одной станции к другой маркера доступа. При получении маркера станция имеет право передать свою информацию.

Особенность в том, что все станции участвуют в передаче на равных основаниях.

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

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

Эти устройства должны: формировать кадры, а анализировать и обрабатывать кадры, принимать кадры из сети и отправлять кадры в сеть.

IEE(Institute of Electrical and Electronics Engineers) предложил другой вариант,где канальный уровень подразделяется на 2 подуровня:

1.уровень управления логическим каналом (LLC)

2. уровень доступа к среде (МАС)

1.Отвечает за достоверную передачу кадров между станциями сети и взаимодействие с сетевым уровнем. МАС уровень лежит ниже LLC-уровня и обеспечивает доступ к каналу передачи данных. Уровень LLC дает более высоким уровням возможность управлять качеством услуг. LLC обеспечивает сервис трех типов:

1. Сервис без подтверждения доставки и установления соединения

2. Сервис с установлением соединения

3. Сервис без установления соединения с подтверждением доставки

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

МАС-уровень должен согласовывать дуплексный режим работы уровня LLC с физическим уровнем. Для этого он буферезует кадры для передачи их по назначению в момент получения доступа к среде.

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

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

Примерами протоколов канального уровня для локальных сетей являются Token Ring, Ethernet, Fast Ethernet, 100-VG-AnyLan,FDDI

В глобальных сетях, которые редко обладают регулярной топологией, канальный уровень обеспечивает обмен сообщениями между двумя соседними ПК. К таким протоколам типа «точка-точка» относятся PPP,SLIP, LAP-B,LAP-D.

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

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

При объединении сетей в кадры канального уровня добавляется заголовок сетевого уровня. Этот заголовок позволяет находить адресата в сети с любой топологией.

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

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

Ряд преимуществ при коммутации передачи маленьких блоков, а не файлов:

1) она напрямую отображается в базовое сетевое оборудование

2) она разделяет процессы передачи данных от прикладных программ

3) она делает систему гибкой

4)она позволяет администраторам сетей вводить новые сетевые технологии

2 метода назначения сетевого адреса:

1)в первом методе сетевой и канальный адреса не совпадают, что обеспечивает гибкость за счет независимости от формата адреса канального уровня

2)во втором методе используется адрес канального уровня. Это избавляет администратора от присваивания адресов вручную и установления соответствия между сетевыми адресами одного и того же абонента в сети.

Сетевой уровень предоставляет средства:

1)доставки пакетов в сетях с произвольной топологией

2) структуризации сети методом локализации широковещательного трафика

3) согласования канальных уровней

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

Маршрутизация- она и является главной задачей сетевого уровня.

На сетевом уровне действуют 2 вида протоколов:

1) относится к определению правил передачи пакетов от конечных узлов к маршрутизаторами и между маршрутизаторами

2) протоколы обмена информацией о маршрутах

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

Уровень адаптации состоит из 2 подуровней: подуровень схождения (CS) и подуровня сегментации и сборки (SAR).

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

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

сеть интерфейс локализация пакет

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

Выбор класса сервиса определяется умением приложения проверять данные и надежностью всей системы транспортировки в сети.

пример транспортного протокола: TCP и UDP стека TCP/IP и протокол SPX Novell

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

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

Уровень представления

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

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

Служит пользовательским интерфейсом с сетью. Этот уровень непосредственно взаимодействует с пользовательским прикладными программами, предоставляя им доступ в сеть. Находятся сетевые приложения: электронная почта, передача файлов в сети, совместная подготовка документов и тп. В качестве протокола прикладного уровня можно отнести: Novell NetWare, NFS,FTP,TFTP

Размещено на Allbest.ru

Подобные документы

Взаимодействие уровней в процессе связи, его эталонная модель для открытых систем. Функции уровней модели OSI. Сетезависимые протоколы, а также протоколы, ориентированные на приложениях, их сравнительное описание и использование в современных сетях.

реферат , добавлен 16.04.2015


Беспроводные стандарты IEEE 802.х; модель взаимодействия открытых систем. Методы локализации абонентских устройств в стандарте IEEE 802.11 (Wlan): технология "снятия радиоотпечатков"; локализация на базе радиочастотной идентификации RFID в сетях Wi-Fi.

курсовая работа , добавлен 04.06.2014


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

контрольная работа , добавлен 10.04.2013


Требования, предъявляемые к техническому обеспечению систем автоматизированного проектирования. Вычислительные сети; эталонная модель взаимосвязи открытых систем. Сетевое оборудование рабочих мест в САПР. Методы доступа в локальных вычислительных сетях.

презентация , добавлен 26.12.2013


Активные и пассивные устройства физического уровня. Основные схемы взаимодействия устройств. Архитектура физического уровня. Базовая эталонная модель взаимодействия открытых систем. Параметры сред передачи данных. Характеристики сетевых концентраторов.

курсовая работа , добавлен 02.02.2014


Основные концепции объединения вычислительных сетей. Базовая эталонная модель взаимодействия открытых систем. Обработка сообщений по уровням модели OSI: иерархическая связь; форматы информации; проблемы совместимости. Методы доступа в ЛВС; протоколы.

презентация , добавлен 13.08.2013


Официальные международные организации, выполняющие работы по стандартизации информационных сетей, протоколы IP, ARP, RARP, семиуровневая модель OSI. TCP/IP, распределение протоколов по уровням ISO в локальных и в глобальных сетях, разделение IP-сетей.

шпаргалка , добавлен 24.06.2010


Теоретические основы организации локальных сетей. Общие сведения о сетях. Топология сетей. Основные протоколы обмена в компьютерных сетях. Обзор программных средств. Аутентификация и авторизация. Система Kerberos. Установка и настройка протоколов сети.

курсовая работа , добавлен 15.05.2007


Определение эффективности методов RSS и TOA, их сравнение в позиционировании абонентских станций внутри помещений и на открытых пространствах. Принципы локализации абонентов в стандарте IEEE 802.11. Использование систем локализации объектов в сетях Wi-Fi.

курсовая работа , добавлен 07.12.2013


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

Предлагаемая эталонная модель 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 в России и СНГ (Москва).