История lapd d канале. Общая структура протоколов GSM

В данной статье использовались материалы: ITIL(Information Technology Infrastructure Library); MOF (Microsoft Operations Framework); ITSM HP Reference Model; ITPM (IT Process Model); COBIT (Control Objectives for Information and related Technology).

Введение

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

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

Стандарты в области информационных технологий

Если говорить о существующих стандартах библиотеках, то наиболее известными являются следующие:

ITIL (Information Technology Infrastructure Library)

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

Фактически библиотека ITIL предлагает построение процессной модели для управления ИТ- подразделением, результатом деятельности которого являются ИТ- услуги для бизнеса с прозрачной стоимостью, качество которых гарантируется путем организации непрерывного контроля. Библиотека ITIL содержит лучший мировой опыт по построению единой комплексной системы управления ИТ- подразделением, который возможно применять к конкретной ситуации. Поскольку библиотека является свободно распространяемой, то она является наиболее применяемым сегодня подходом к управлению ИТ- услугами, который применим ко всем секторам и организациями любого размера. ITIL может быть внедрен как полностью, так и частично, и фактически, это некоторая система взглядов на управление информационными технологиями в компании. Владельцем проекта ITIL в настоящее время является OGC/CCTA (Офис правительственной коммерции / Центральное агентство по компьютерам и телекоммуникациям). Обобщение опыта управления ИТ на протяжении 20 лет под эгидой правительства Великобритании сделало книги ITIL по всем основным областям управления ИТ стандартом «де-факто».

COBIT (Control Objectives for Information and related Technology)

– стандарт управления и аудита в области информационных технологий. Основой стандарта COBIT являются 34 высокоуровневые цели контроля, по одной на каждый ИТ- процесс, которые сгруппированы в 4 домена: Планирование и Организация, Проектирование и Внедрение, Эксплуатация и Сопровождение, Мониторинг. Особенностью стандарта COBIT по отношению к другим стандартам в области ИТ является присутствие в нем модели зрелости разработанной в конце 80-х годов Институтом проектирования и разработки программного обеспечения (Software Engineering Institute’s). Maturity Models (MM) – не технология, не стандарт, для нее нет формальных описаний, в ней нет жестких требований, и она не привязана к конкретным информационным технологиям. Однако данная модель зрелости вводит понятие нескольких уровней зрелости процессов:

• Не существует. Полное отсутствие каких-либо процессов управления ИТ. Организация не признает существования проблем в ИТ, которые нужно решать, и, таким образом;
• Начало. Организация признает существование проблем управления ИТ и необходимость их решения. При этом не существует никаких стандартизованных решений;
• Повторение. Существует всеобщее осознание проблем управления ИТ. Показатели деятельности и ИТ-процессов находятся в развитии, охватывая процессы планирования, функционирования и мониторинга ИТ;
• Описание. Необходимость действовать в соответствии с принципами управления ИТ понимается и принимается. Процедуры стандартизованы и документированы;
• Управление. Существует полное понимание проблем управления ИТ на всех уровнях организации, постоянно происходит обучение сотрудников. Четко распределена ответственность, установлен уровень владения процессами;
• Оптимизация. В организации существует углубленное понимание управления ИТ, проблем и решений ИТ, а также перспектив. В результате непрерывного улучшения процессы соответствуют моделям зрелости, построенным на основании «лучшей практики».

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

MOF (Microsoft Operations Framework)

— Управление информационными технологиями эта тема, в которой компания Microsoft имеет свое видение. Система стандартов Microsoft Enterprise Services от компании Microsoft представляет собой три области:

• Первой областью является деятельность по подготовке к внедрению информационной системы где формализуются требования к ИТ и определяется объем проекта. Подготовка к внедрению информационной системы описана в стандарте Microsoft Readiness Framework (MRF);
• Второй областью является деятельность по внедрению информационной системы на предприятии, где определяются основные вопросы разработки и развертывания ИТ- решения. Построение и внедрение информационной системы описано в стандарте Microsoft Solutions Framework (MSF);
• Третьей областью является деятельность по поддержке информационной системы внедренной на предприятии. Вопросы эксплуатации информационной системы рассматриваются в стандарте Microsoft Operations Framework (MOF).

MOF состоит из набора статей (white papers), руководств (operations guides), обучающих курсов и включает в себя три основные модели:

• Модель процессов (MOF Process Model); o Модель команды (MOF Team Model);
• Модель управления рисками (MOF Risk Model).

Общая похожесть данного стандарта на ITIL и ориентация на продукты Microsoft делает данный стандарт менее используемым, относительно ITIL. Однако для пользователей технологий Microsoft использование данного стандарта оправдано, хотя нужно понимать, что большинство процессов в MOF перешло из библиотеки ITIL.

ITSM HP Reference Model

– это корпоративная модель, которая была разработана компанией HP на основе и в полном соответствии с библиотекой ITIL. Фактически данная модель является переработкой ITIL с учетом зрения компании HP и перечень процессов в обеих моделях одинаковый.

ITPM (IT Process Model)

– это стандарт, который был предложен компанией IBM в конце 70-х годов прошлого века для решения задач управления компьютерными системами. Была создана архитектура ISMA (Information Systems Management Architecture) и концепция (IT Process Model), возникшая из ISMA и принятая к использованию компанией IBM. Данный подход отличается от ITIL не только по способу деления процессов, но и в ряде терминологических моментов. Фактически IT Process Model — это 41 процесс, собранный в восемь групп по числу основных факторов, влияющих на успех ИТ- проектов:

• Взаимодействие с клиентами;
• Обеспечение управленческих систем корпоративной информацией;
• Управление ИТ с точки зрения бизнеса;
• Подготовка решений;
• Развертывание решений;
• Предоставление услуг и управление изменениями;
• Поддержка ИТ-услуг и решений;
• Управление ИТ-ресурсами и инфраструктурой.

Однако, если говорить о практике использования данной модели в России, то она используется достаточно редко. ISO 20000 – один из новых стандартов в области менеджмента качества, который вобрал в себя с незначительными изменениями большинство основных принципов и процессов ITIL. В настоящий момент времени производится сертификация ИТ – подразделений на соответствие сервис -ориентированному и процессному подходу в области управления ИТ с использованием данного стандарта.

Библиотека ITIL

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

Библиотека ITIL вводит понятие услуга/сервис ИТ под которым подразумевается решение определенной задачи в рамках бизнес-процессов или проектов организации средствами информационных технологий. Все услуги собираются в каталог услуг/сервисов ИТ и для каждой услуги определяются параметры услуг, такие как согласованное время обслуживания, доступность, надежность, конфиденциальность и др. Все услуги и их параметры фиксируются в Соглашениях об уровне услуг (SLA). Одним из основополагающих процессов ITIL является процесс предоставления сервисов (Service Delivery) в рамках которого определены следующие процессы:

• Управление уровнем сервиса (Service Management) – достижение ясных соглашений с Заказчиком об ИТ-услугах и реализация этих соглашений;
• Управление затратами (Cost Management) – определение, отнесение расходов, их прогноз и отслеживание;
• Управление мощностями (Capacity Management) – оптимизация расходов, времени приобретения и размещения ИТ-ресурсов;
• Управление доступностью (Availability Management) – оптимизация обслуживания и минимизация числа инцидентов;
• Управление непрерывностью (Continuity Management) – подготовка и планирование способов устранения чрезвычайных ситуаций;
• Управление безопасностью (Security Management) – обеспечение режима информационной безопасности.

Другим основополагающим процессом ITIL является процесс поддержки сервисов (Service Support) в рамках которого определены следующие процессы:

• Взаимодействие с пользователями (Service Desk) – точка контакта пользователя с ИТ – организацией;
• Управление инцидентами (Help Desk/ Incedent Management) –устранение инцидента и быстрое возобновление предоставления услуг;
• Управление проблемами (Problem Management) – предупреждение и устранение корневых проблем инцидентов;
• Управление конфигурациями (Configuration Management) – контроль изменяющейся ИТ-инфраструктуры;
• Управления изменениями (Change Management) – контроль проведения изменений в ИТ-инфраструктуре;
• Управление релизами (Software Control & Distribution) – обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранения.

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

• Изменяется роль ИТ, которые сейчас являются ключевым двигателем изменений и улучшений бизнес-процессов;
• Предоставление ИТ- услуг становится более ориентированным на бизнес- подразделения;
• Формируется основа для контроля качества и стоимости услуг;
• Становится понятной процессная модель и структура ИТ- департамента;
• Эффективная структура процессов создает основу для аутсорсинга ИТ- услуг;
• Следование передовому опыту ITIL способствует изменению корпоративной культуры в направлении осознания, что задачей ИТ- департамента является предоставление услуг;
• Библиотека ITIL предоставляет единую систему понятий для взаимодействия, как в компании, так и с поставщиками услуг;
• Осуществляется переход к рыночным отношениям бизнеса и ИТ;
• Внедряется процессный подход, обеспечивающий повышение эффективности и дополняющий функциональное управление;
• Внедряется упреждающий (плановый) подход к управлению ИТ в дополнение к традиционному реагирующему (пожарному);
• Формируется основа для расчета затрат в разрезе ИТ- услуг;
• Внедряется управление знаниями в области ИТ, включая базу данных известных ошибок, информацию об ИТ- инфраструктуре.

Стандарт MOF

Если сравнивать объем библиотеки ITIL c моделью процессов MOF, то модель MOF является некоторым расширением процессов, описанных в книгах «Предоставление ИТ-услуг» и «Поддержка ИТ-услуг» библиотеки ITIL. Фактически модель MOF Process Model представляет процессы управления обслуживанием информационных систем, которые представлены в виде функций управления услугами (Service Management Functions, SMF).

Вся модель MOF содержит в себе 20 сервисных функций разбитых на четыре квадранта:

• Изменение (Changing) — Внедрение изменений процессов, новых решений и технологий;
• Обслуживание (Operating) – Обеспечение выполнения каждодневных рутинных операций;
• Поддержка (Supporting) – Обеспечение скорейшего решения инцидентов, проблем, запросов;
• Оптимизация (Optimizing) — Оптимизация стоимости, производительности, доступности ИТ- услуг.

В рамках данных четырех квадрантов распределяются все 20 сервисных функций.

В квадранте «Изменение» собраны три следующих сервисных функции:

• Управление изменениями (Change Management). Планирование и регистрация всех требуемых изменений в информационной системе, оценка влияния, оказываемого этими изменениями, на другие компоненты информационной системы;
• Управление релизами (Release Management). Контроль над релизами и процессом их развертывания должен гарантировать, что все релизы хорошо спланированы и протестированы;
• Управление конфигурациями (Configuration Management). Регистрация и контроль сведений о конфигурационных элементах ИТ-инфраструктуры включает в себя процесс сбора информации обо всех конфигурационных элементах системы в единую базу данных и процессы аудита соответствия информации текущей ситуации.

В квадранте «Поддержка» собраны три следующих сервисных функции:

• ServiceDesk. Организация первой линии поддержки, регистрация обращений пользователей, запросов на информацию и запросов на изменения;
• Управление инцидентами (Incident Management). Управление процессом разрешения инцидентов и обеспечение скорейшего восстановления нормальной работы услуги;
• Управление проблемами (Problem Management). Обеспечение бесперебойной работы всех служб информационной системы путем анализа корневых причин появления инцидентов.

В квадранте «Оптимизация» собраны шесть следующих сервисных функций:

• Управление уровнем обслуживания (Service Level Management). Управление качеством ИТ- услуг путем определения и контроля параметров соглашения об уровне услуг (Service Level Agreement, SLA) между поставщиком и заказчиками;
• Управление финансами (Financial Management). Определение, оптимизация и контроль стоимости ИТ- услуг, что включает планирование и составление бюджетов, анализ стоимости услуг, а также мероприятия по оптимизации затрат на ИТ и оценке необходимости инвестиций;
• Управление непрерывностью услуг (Service Continuity Management). Восстановление ИТ- инфраструктуры в случае непредвиденных ситуаций. Включает разработку плана быстрого восстановления критически важных для бизнеса систем;
• Управление мощностями (Capacity Management). Контроль и обеспечение необходимой производительности ИТ- ресурсов в соответствии с определенным уровнем обслуживания в SLA;
• Управление доступностью (Availability Management). Управление доступностью информации и услуг с точки зрения использования имеющихся мощностей;
• Управление персоналом (Workforce Management). Выработка рекомендаций по набору, сохранению и мотивированию ИТ- персонала.

В квадранте «Обслуживание» собраны 8 следующих функций:

• Планирование работ (Job Scheduling). Организация процесса выполнения работ наиболее эффективным образом для выполнения требований соглашения об уровне услуг;
• Системное администрирование (System Administration). Выполнение ежедневных операций по администрированию информационной системы;
• Сетевое администрирование (Network Administration). Обеспечение бесперебойной работы сетевой инфраструктуры;
• Администрирование системы безопасности (Security Administration). Обеспечение безопасности информационной системы, определение и контроль параметров защиты корпоративной информации и ИТ- услуг;
• Администрирование служб каталога (Directory Services Administration). Обслуживание и поддержка корпоративной службы каталога;
• Управление хранением данных (Storage Management). Разработка плана архивации/восстановления данных, контроль над системами хранения;
• Мониторинг услуг (Service Monitoring and Control). Получение обслуживающим персоналом актуальной информации о состоянии ИТ- услуг. Наиболее типичными объектами мониторинга являются: состояние процессов, статусы запланированных заданий, параметры очередей, загрузка серверов, время отклика приложений;
• Управление результатами (Print and Output Management). Контроль над процессом печати данных и данными, предоставляемыми в отчетах.

Если сравнивать объем стандарта MOF с процессами ITIL по предоставлению и поддержке услуг, то видно, что MOF несколько шире, однако расширение связано с некоторой детализацией квадранта «Обслуживание», что с одной стороны дает определенную информацию, но с другой стороны данная деятельность присутствует в большинстве ИТ- служб и расширение модели в данном направлении не вносит большой новизны. Добавление сервисной функции Управление персоналом не несет специфических знаний для организации ИТ в компании и является вспомогательным процессом, который присутствует в любой компании и логика выполнения которого предельно понятна. В остальном, процессы ITIL и MOF полностью идентичны, включая одинаковые наименования и описания.

Однако, стандарт MOF помимо процессной модели содержит ролевую структуру для распределения полномочий и ответственности между сотрудниками ИТ — модель команды (MOF Team Model). Причем модель команды не предназначена для описания трудовых обязанностей и не является организационной схемой.
В модели команды MOF описаны шесть ролей, сгруппированных по жизненному циклу ИТ- услуги. Фактически данные роли являются некоторыми направлениями деятельности:

• Релиз (Release) — Планирование и выполнение изменений;
• Поддержка (Supporting) — Поддержка пользователей;
• Безопасность (Security) — Контроль над корпоративной политикой безопасности;
• Инфраструктура (Infrastructure) — Управление средствами работы с инфраструктурой;
• Обслуживание (Operations) — Выполнение ежедневных операций по обслуживанию ИС;
• Партнерство (Partner) — Установление взаимоотношений с бизнесом.

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

Помимо модели команды стандарт MOF содержит в себе модель управления рисками (MOF Risk Model), которая определяет основные этапы управления рисками:

• Идентификация рисков (Identify). Определение причин риска, условий его возникновения, последствий;
• Анализ рисков (Analyze). Оценка вероятности возникновения риска и ущерба для информационной системы и бизнеса;
• Планирование мероприятий (Plan). Определение мероприятий, позволяющих полностью избежать риска или уменьшить его влияние. Также на тут разрабатывается план действий в случае возникновения риска
• Отслеживание риска (Track). Сбор информации об изменениях с течением времени различных элементов риска. В случае, если риск считается с некоторого времени незначимым, его необходимо исключить из списка рисков. Если влияние риска изменилось, следует перейти к этапу анализа для переоценки этого влияния
• Контроль (Control). Выполнение запланированных действий в качестве реакции на возникновение рискового события. Фактически данные этапы управления рисками связываются в жизненный цикл управления рисками от идентификации до непрерывного контроля.

Однако если рассмотреть модель управления рисками в отрыве от стандарта ITIL и MOF, то можно увидеть неглубокое представление модели управления рисками. Например, такая методика как CRAMM, содержит более подробные указания по механизмам оценки рисков, а BASEL II – подробнее описывает вопросы организации системы управления рисками в компании. Поэтому для развертывания системы управления рисками более эффективно использовать другие методики, содержащие более полную информацию. По причине схожести методологии ITIL и MOF преимущества от использования данных моделей фактически идентичны.

Вывод

В результате сравнения ITIL и MOF мы увидели, что MOF обладает рядом существенных особенностей по сравнению со стандартом ITIL, однако если рассмотреть данные особенности, то они не носят ключевого характера: o Процессы, не включенные в ITIL, являются интуитивно понятными и принятыми в оперативной деятельности; o Модель процессов дополнена моделями команды и управления рисками, но применение данных моделей осложнено из-за слабой их детализации; o В противовес документам чисто описательного характера, свойственным ITIL, в MOF предоставлены прикладные материалы, такие как документы серий Windows Operations Guide, Exchange Operations Guide и т.д. Однако данные документы имеют привязку к определенной операционной системе и в принципе не относятся к организации процессов. Если делать вывод о применимости рассмотренных стандартов в области ИТ для оптимизации деятельности, то можно с уверенностью сказать что все они содержат «зерно истины», поэтому применение их в совокупности наиболее предпочтительно, поскольку в определенных областях они имеют новшества относительно друг друга.

В данной статье использовались материалы: MOF (Microsoft Operations Framework); ITSM HP Reference Model; ITPM (IT Process Model); COBIT (Control Objectives for Information and related Technology).

Мы продолжаем цикл публикаций, знакомящих читателей с методологией COBIT® 5. Мы уже описывали принципы и процессную модель COBIT 5. Пришло время сказать еще об одной ключевой составляющей COBIT 5 – модели оценки процессов (COBIT Process Assessment Model, PAM).

В этой статье мы расскажем о том, что это за модель, как она устроена и зачем она нужна аудиторам, руководителям и сотрудникам ИТ.

Что такое оценка процессов

Сначала скажем несколько слов об оценке процессов вообще.

В международном стандарте ISO/IEC 15504 оценка процессов определена как деятельность, которая выполняется либо в составе программы совершенствования процессов, либо как часть подхода к определению возможностей процессов.

Назначение совершенствования процессов – постоянное повышение результативности и рациональности организации.

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

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

Какими же бывают оценки процессов? Сразу оговоримся, что примитивные модели «Хорошо или плохо» нас как практиков процессного управления устроить не могут:

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

Модель зрелости COBIT 4.1

Методология COBIT 4.1 предлагала подобную систему оценки процессов, называя ее «Моделью зрелости» (COBIT 4.1 Maturity Model). В основе системы лежала шкала оценки и модель зрелости способностей (Capability Maturity Model, CMM) Института разработки программного обеспечения (the Software Engineering Institute, SEI), широко известная как «Интегрированная модель зрелости» (Capability Maturity Model Integration, CMMI). Оценка процессу выставлялась по принципу: «насколько вероятно, что процесс в заданных условиях приведет к ожидаемому результату?» .

Названия уровней зрелости отвечали на этот вопрос, практически не нуждаясь в дополнительных объяснениях:

• «0»: Не существующий процесс
• «1»: Начальный процесс
• «2»: Интуитивно повторяющийся
• «3»: Определенный (документированный) процесс
• «4»: Измеряемый и управляемый
• «5»: Оптимизируемый

• Шесть атрибутов зрелости:
  1. Осведомленность и коммуникации
  2. Политики, планы и процедуры
  3. Инструменты и автоматизация
  4. Навыки и квалификация
  5. Ответственность и подотчетность
  6. Цели и измерение

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

• Модель зрелости каждого процесса. В описании каждого процесса приводилась модель зрелости, то есть описание процесса, функционирующего на заданном уровне зрелости.

К примеру, процесс управления изменениями (AI6) описывался в COBIT 4.1 такой моделью зрелости:

Уровень «0»: не существует определенного процесса управления изменениями, и изменения производятся практически бесконтрольно. Нет осведомленности о негативном влиянии изменений на ИТ и на бизнес, и нет осведомленности о выгодах правильного управления изменениями.

Уровень «5»: Процесс управления изменениями регулярно пересматривается и обновляется для того, чтобы соответствовать общепринятым практическим рекомендациям. Оценка изменений отражает результаты мониторинга. Конфигурационная информация автоматизирована и позволяет контролировать версии. Изменения отслеживаются комплексно, в том числе с помощью инструментов обнаружения неавторизованного и нелицензированного ПО. Управление изменениями в ИТ интегрировано с управлением бизнес-изменениями, для того обеспечить повышение производительности и создание новых возможностей для предприятия.

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

Таким образом, оценка и аудит процессов на основе COBIT 4.1 могут производиться с практически произвольными результатами, так как

• COBIT 4.1 не предлагает объективных характеристик уровней зрелости;
• COBIT 4.1 не предлагает категоричного разделения между уровнями зрелости.

В итоге оценка процесса с применением модели зрелости COBIT 4.1 зависела от субъективного мнения оценщика о том, насколько значимыми для процесса являются те или иные атрибуты зрелости, а также о том, насколько оцениваемый процесс соответствует приведенному выше описанию модели зрелости (попробуйте, например, объективно оценить «комплексность отслеживания изменений»).

ISO/IEC 15504 и ISACA

Годы применения модели зрелости COBIT 4.1 на практике показали, что требования к методологии оценки процессов, которые мы привели в начале, в этой модели не выполняются. Естественно, аудиторы и консультанты обзавелись собственными инструментами оценки, в которых все двусмысленности подхода устранялись, и поэтому можно было надеяться, что оценки двух одинаковых процессов на двух схожих предприятиях, выставленные одним и тем же аудитором, правдиво говорили об успехах этих двух процессов. Во всех остальных случаях «зрелость процессов» оказывалась слишком абстрактной для того, чтобы «судить» процессы и их владельцев или для того, чтобы ставить достижение того или иного уровня зрелости в качестве задачи проекта по совершенствованию.

Рынку требовалась более строгая, гибкая и повторяемая методология оценки процессов.

Ассоциация ISACA в 2011 году решила в качестве такой методологии использовать международный стандарт ISO/IEC 15504 «Информационные технологии – оценка процесса». Идея стандартизации того, как оцениваются процессы, зародилась в 1990-х годах у разработчиков программного обеспечения . История развития этого стандарта находится за рамками нашей публикации; существенно лишь то, что сегодня правила и подход к проведению оценки процессов, изложенные в новейшей редакции стандарта, не привязаны к конкретным процессным областям, и могут применяться для оценки любых производственных или вспомогательных процессов .

В том числе и процессов управления и руководства ИТ на предприятии. ISACA утвердила наметившийся вектор соответствия собственных разработок в области контроля и аудита и продукции международной организации по стандартизации ISO, выпустив книгу «COBIT Process Assessment Model: Using COBIT 4.1». В этой книге процессы COBIT 4.1 были «переписаны» так, чтобы быть совместимыми с моделью оценки возможностей ISO/IEC 15504, а также были добавлены некоторые компоненты контроля и управления, которых методология не содержала раньше.

В COBIT 5 процессная модель изложена в книге «COBIT 5: Enabling Processes» изначально совместимым со стандартом образом, так, чтобы максимально упростить оценку.

Так как же оцениваются возможности процессов?

Оценка возможностей процессов по PAM

Формально модель оценки процессов выглядит так:

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

При сравнении этой методики с моделью зрелости сразу бросается в глаза слово «возможность» (Capability). Теперь речь идет не о зрелости системы управления, но о том, насколько «возможно», что процессы будут приводить к ожидаемым и запланированным результатам в любых обстоятельствах. В этом состоит идеологическое отличие модели ISO 15504 от модели CMMI, где, как мы уже говорили, ценность процесса оценивалась исходя из стабильности ограничений.

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

COBIT 5 PAM:

Уровень 0: Неполный (Incomplete) процесс – Такой процесс еще не внедрен или не способен соответствовать своему назначению. На этом уровне отсутствуют свидетельства систематического достижения процессом своих целей, или таких свидетельств мало.

Неполный процесс не достигает всех поставленных целей (Outcomes) полностью.

Уровень 1: Выполняемый (Performed) процесс – Процесс внедрен и соответствует своему назначению. В случае если результаты процесса не достигаются, то такой процесс будет оценен на 0 (ноль) по шкале ISO/IEC 15504.

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

Уровень 2: Управляемый (Managed) процесс – Выполняемый процесс предыдущего уровня теперь управляем (то есть планируется, отслеживается и корректируется). Создаются, контролируются и поддерживаются рабочие продукты (work products) процесса.

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

Уровень 3: Установленный (Established) процесс – Управляемый процесс теперь способен получать ожидаемые результаты (outcomes).

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

Уровень 4: Предсказуемый (Predictable) процесс – Установленный процесс теперь получает результаты в условиях заданных ограничений.

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

Уровень 5: Оптимизируемый (Optimizing) процесс – предсказуемый процесс теперь постоянно совершенствуется, чтобы достигать текущих и будущих целей предприятия.

Выявлены и точно сформулированы задачи совершенствования процесса. Более того, эти задачи выполняются, и рассчитывается их результативность.

Из такого описания следует ряд выводов, которые могут стать неожиданными для адептов оценки процессов по «зрелости»:

• Процесс, который не создает всех ожидаемых заинтересованными сторонами результатов, автоматически получает оценку «0». Это означает, что применять такую методику можно для достаточно «зрелых» процессов, во всяком случае, выше уровня 2.
• Процесс, который здесь и сейчас (то есть в заданных условиях) создает все ожидаемые результаты в полном объеме, получает оценку «1».
• Процесс может получить любую оценку выше «1», только если выполнены все требования нижележащих уровней возможностей.

Так что же требуется от уже работающего (а иногда в ITSM – и очень дорогостоящего) процесса, чтобы не получить «незачет» или «кол»? Ответ стандарта ISO 15504: выполнять и создавать свидетельства выполнения универсальных управленческих практик .

Словарь PAM

Для дальнейшего понимания модели возможностей необходимо точно ориентироваться в процессном словаре COBIT PAM. Традиционно, термины несколько неудобны для русскоязычного читателя и могут привести в заблуждение относительно сложности предлагаемых инструментов. Ради упрощения изложения, мы будем использовать далее устоявшиеся латинские аббревиатуры.

Процесс состоит из базовых практик (Base practices, BPs ). Привычный эквивалент – «виды деятельности» или «шаги». BPs процессов COBIT 5 могут быть хронологически связаны, а могут и повторяться относительно друг друга, что отличает их от производственных процессов. На уровне руководства и управления это позволяет рассматривать процессы как логические группы работ, которые выполняет ИТ-организация.

BPs формируют артефакты или рабочие продукты процесса (Work products, WPs ). Стандарт ISO 15504 выделяет три вида WP: это политики (правила игры), планы (документированные намерения) и записи (свидетельства о выполнении намерений). Именно эти документальные свидетельства и являются в практике аудита важнейшим источником информации для аудитора-оценщика. WP может быть выходом одного процесса и одновременно являться входом для других.

Пример. WP APO01.03 «Связанные с ИТ политики» формируется в процессе APO01, и является входом для всех остальных процессов домена APO.

Вместе BPs и WPs называются «индикаторами производительности процесса».

Выполняя BPs и формируя WPs, процесс приводит к ожидаемым результатам (Outcomes, O"s ). По смыслу O"s идентичны «целям и задачам» процесса.

Важно упомянуть о том, что референтная модель процессов COBIT 5 содержит два логических «скачка», унаследованных из стандарта ISO 15504. Во-первых, получение всех WPs означает достижение всех O"s процесса. Во-вторых, достижение O"s автоматически означает, что процесс соответствует своему назначению . И первое и второе более чем спорно не только для реальных ITSM-процессов, но для некоторых процессов COBIT 5. Тем не менее, это обязательные условия модели оценки возможностей, а также свидетельство по-настоящему качественной работы проектировщиков и методологов процесса. В референтной модели COBIT 5 связь «O-BP-WP» (результат – вид деятельности – выход) отражена в явном виде.

Чтобы процесс соответствовал своему назначению независимо от своего масштаба, организация должна управлять процессом, а значит, кто-то должен выполнять еще и управленческие практики , применительно к каждому процессу (generic management practices, GPs ) . Читатели ITIL® уже знают, что «кто-то» - это владелец и менеджер процесса.

При выполнении GP формируются универсальные рабочие продукты (Generic work products, GWPs ). Универсальные GWP применимы к любому оцениваемому процессу.

Вместе GP и GWP называются «индикаторами возможностей процесса».

Следуя приведенной выше терминологии, перефразируем принцип начисления «баллов» для выставления «оценки»: аудитор-оценщик ищет свидетельства выполнения BPs и GPs процесса. Свидетельства могут быть выражены в форме WPs и GWPs, а могут быть и мнением заинтересованных сторон о достижении процессом своих O"s.

Что же произойдет, если оценщик эти свидетельства обнаружит? Он распределит их по атрибутам возможностей процессов.

Строгая модель оценки на основе стандарта ISO 15504 разделяет все BPs и GPs на девять групп (атрибутов процесса). Каждому уровню возможностей процесса соответствует 1 или 2 таких атрибута. Разделение предельно простое:

• Неполный процесс не содержит атрибутов, так как существуют не все BP, и не формируются O"s.
• Выполняемый процесс содержит один атрибут, «Осуществление процесса». Этот атрибут будет реализован, если выполняемые BPs приводят к достижению O"s.
• Управляемый процесс содержит два атрибута: «Управление осуществлением» (шесть GPs) и «Управление рабочими продуктами» (четыре GPs).
• Установленный процесс содержит два атрибута: «Определение процесса» (пять GPs) и «Развертывание процесса» (шесть GPs)
• Предсказуемый процесс содержит два атрибута: «Измерение процесса» (шесть GPs) и «Контроль процесса» (пять GPs).
• Оптимизируемый процесс содержит два атрибута: «Инновации процесса» (пять GPs) и «Оптимизация процесса» (три GPs).

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

Оценщик, согласно стандарту, должен последовательно рассмотреть каждый из 9 атрибутов, начиная с первого, который касается практик самого процесса (BP) и далее, со второго, рассматривая свидетельства всех атрибутов возможностей процесса. Для того чтобы снизить беспокоившую всех субъективность, стандарт предлагает 4 рейтинга достижения каждого атрибута:

• N (not achieved, не достигается) . В оцениваемом процессе не существует, или существует мало свидетельств того, что определенный атрибут достигается (от 0 до 15% реализованных практик).
• P (partially, частично достигается) . В оцениваемом процессе существуют свидетельства того, что существует подход к достижению, и происходит частичное достижение заданных целей. Некоторые аспекты того, как достигается цель (атрибут) непредсказуемы (от 15% до 50% реализованных практик).
• L (largely, в основном достигается) . В оцениваемом процессе существуют свидетельства системного подхода и системного достижения заданных целей. Существуют некоторые недостатки достигаемых результатов (от 50% до 85% реализованных практик).
• F (fully, полностью достигается) . В оцениваемом процессе существуют свидетельства полного системного подхода и фактического достижения заданных целей. Значительных недостатков связанных с полученным результатом не выявлено (от 85% до 100% реализованных практик).

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

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

Книга содержит в себе ту же референтную модель, что описана в книге COBIT 5: Enabling processes, но с поправкой на требования стандарта к описанию процесса.

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

• Назначения (Purpose statement)
• Результатов (Outcomes)
• Базовых практик (Base practices)
• Входов и выходов (Work products)

Изюминка рассматриваемого подхода к оценке состоит в том, что эта референтная модель процессов в COBIT 5 нужна лишь для описания самого первого атрибута возможностей процессов, то есть, как мы уже говорили выше, для получения оценки «единица». Любые подробности о специфике процесса не будут интересовать оценщика, ведь они затруднят сравнение процесса с другими!

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

В качестве иллюстрации приведем несколько примеров универсальных управленческих практик (GPs), которые заявлены в стандарте ISO 15504 и продублированы в COBIT PAM:

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

О каждой GP, как уже было сказано выше, свидетельствуют универсальные рабочие продукты (GWPs). Их происхождение – это, пожалуй, единственное дополнение к стандарту ISO 15504, которое было изобретено авторами COBIT PAM. Список этих документов близок и менеджерам по качеству, и практикам процессов ITSM, их всего девять:

1. Процессная документация (диаграмма, охват, RACI-матрица и т.д.)
2. План процесса
3. План качества (содержание WP, критерии качества WP и т.д.)
4. Записи по качеству
5. Политики и стандарты
6. План совершенствования процесса
7. План измерения процесса
8. План контроля процесса
9. Записи о производительности процесса

Таким образом, книга COBIT PAM содержит:

• Общее описание подхода к оценке возможностей
• Референтную модель процессов COBIT 5 в формате ISO 15504
• Перечень и описание универсальных управленческих практик и распределение их по атрибутам возможностей
• Перечень и описание универсальных рабочих продуктов и распределение их по универсальным управленческим практикам

Кроме этого в состав программы COBIT по оценке процессов входят и дополнения:

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

Такой перечень дополнительных публикаций отражает двойное назначение COBIT PAM: проведение внешних и внутренних оценок.

Процесс оценки и требования к оценщику

COBIT PAM в более удобном, чем стандарт ISO 15504, виде описывает проведение оценки процессов.

ШАГ ПЕРВЫЙ Определение охвата

COBIT PAM приводит важный перечень шагов по выбору оцениваемых процессов. При проведении внутренней оценки ИТ-предприятие или служба вольны использовать любую процессную модель. В таком случае, из всего материала PAM потребуются только списки и трактовки GP и GWP, а вот описание процессов придется составить самостоятельно, соблюдая принципы, диктуемые стандартом.

При внешней оценке COBIT PAM становится инструментом аудита, так как результаты на основе общей процессной модели становятся повторяемыми и сравниваемыми. Дискуссионным остается совершенство предлагаемой процессной модели, однако, исходя из задач аудита, оцениваться может только часть важных и нужных предприятию ИТ-процессов. Более того в «Руководстве оценщика» COBIT требует создания «маппинга» - карты соответствия между действующими на предприятии терминами, формулировками и определениями и референтной моделью процессов COBIT 5.

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

1. Выявить стимулы для проведения оценки процессов. Иначе говоря, зачем нужна оценка?
2. Ранжировать процессы по степени поддержки движущих сил бизнеса (см. Романа Журавлева).
3. В соответствии с приоритетами, выбрать процессы, которые будут в оценке.
4. Согласовать предварительный охват оценки со спонсором проекта и ключевыми заинтересованными сторонами.
5. Утвердить список оцениваемых процессов.
6. Задокументировать методологию в записях проекта оценки.

ШАГ ВТОРОЙ Планирование оценки

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

ШАГ ТРЕТИЙ Брифинг

Лидер команды оценщиков рассказывает своей команде о том, что предстоит сделать, на основе каких данных и каким именно образом.

ШАГ ЧЕТВЕРТЫЙ Сбор данных

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

ШАГ ПЯТЫЙ Проверка данных

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

ШАГ ШЕСТОЙ Подсчет атрибутов

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

ШАГ СЕДЬМОЙ Отчет о результатах

Результаты оценки должны быть проанализированы и представлены в отчете.

• Сильные и слабые стороны
• Рейтинг атрибута, присвоенный процессу должен быть подтвержден объективными доказуемыми свидетельствами
• Высокие риски, то есть существенные отклонения выявленных возможностей от тех, которые были заявлены или проверялись.

Итог

Самой яркой прикладной пользой COBIT 5 PAM, на взгляд автора, являются описания универсальных рабочих продуктов (GWPs). Это практически полный перечень и детальное оглавление всей процессной документации. Набор этих документов довольно точно воспроизводит иерархию документов в ITIL (политики, описание, процедуры и инструкции процесса) и поможет любому методологу или проектировщику процесса: начинающему или опытному, работающему на предприятии или в консалтинге.

Ну, а в теории модель оценки возможностей процессов COBIT 5 PAM позволяет ответить на вопрос: насколько вероятно, что процесс сможет соответствовать своему назначению при разумных затратах в любых условиях? Иначе говоря, модель оценки позволяет проверить, насколько процесс управляем, а значит, гибок. При этом авторы честно признаются, что более высокая вероятность означает и более высокие затраты на управление процессом.

Кроме этого, каждый недостигнутый атрибут процесса означает вполне конкретные риски для организации. Это значит, что проведение оценки в соответствии с COBIT PAM может помочь ИТ-руководителю выбрать области для более жесткого контроля. А для владельцев и менеджеров предприятия, на котором используются информационные технологии, оценка даст понимание сильных и слабых сторон ИТ-процессов, а значит и уверенность в том, что ИТ-служба успешно (или наоборот) управляет важным активом – информацией.

Если говорить о перспективах применения COBIT 5 PAM в российских реалиях, то языковой барьер может стать существенным ограничителем. Язык стандарта середины 2000-х годов бюрократичен и поэтому трудно осмысливаем. Чего только стоят обороты при определении уровней возможностей:

Level 3 Established process (two attributes) - The previously described managed process is now implemented using a defined process that is capable of achieving its process outcomes. Увы, но ради универсальности всегда приходится жертвовать пониманием. Мы очень ждём от ISACA дополнительных публикаций, например, историй успеха, с помощью которых можно будет осознать уровни возможностей и причины именно такой их последовательности.

При этом COBIT PAM обладает рядом явных преимуществ, по сравнению с привычными моделями зрелости:

• Гибкий и удобный инструмент оценки, совместимый с международным стандартом ISO 15504
• Требования к конкретным процессам из процессной модели COBIT 5
• Возможность снабжать процессы атрибутами стандарта ISO 15504
• Требования к свидетельствам (в том числе для аудита)
• Требования к оценщику и его опыту

Всё это приведет к более точной, объективной и воспроизводимой оценке процессов, как внутри предприятия, так и в рамках всей отрасли управления информационными технологиями.

Руководители организации и практики ITSM могут использовать предложенную в COBIT PAM методику для того чтобы сравнить действующие у них процессы с эталонными процессами COBIT 5. А если на это упражнение нет ресурсов или у вас нет потребности демонстрировать соответствие своих процессов эталонной модели, то с помощью описания управленческих практики и продуктов, вы сможете честно ответить на вопрос: управляете вы процессами в вашей ИТ-организации или нет.

COBIT 5 PAM – замечательный, системный и весьма подробный инструмент для аудитора, руководителя, и практика процессного управления ИТ. Как и любой другой, его нужно применять одновременно разумно и творчески, не воспринимая эту модель в качестве строгой научной теории. Мы всё еще продолжаем говорить о «практических рекомендациях», и только здравый смысл и постоянная самопроверка («а зачем мне это нужно?») поможет извлечь реальную пользу из них.

Примечания

1. Занятно, что и модель зрелости CMM тоже с самого начала была заказана Министерством обороны США для того, чтобы объективно сравнивать между собой подрядчиков, которые выполняли разработку ПО.
2. Примеры применения стандарта в различных отраслях можно найти в Википедии: http://en.wikipedia.org/wiki/ISO/IEC_15504 .

3. Источники расходятся в том, что стоит за словами «назначение», «цель» и «задача». Мы не можем в рамках этой публикации вдаваться в этот семантический спор. Договоримся, что в COBIT 5 «Outcome – это утвердительное предложение, описывающее целевое состояние организации в абсолютных терминах». А Purpose – это утвердительное предложение, которое объясняет, зачем нужен этот процесс. К примеру, для процесса «BAI06 Управление изменениями» назначением (Purpose statement) является:

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

   А целями этого процесса являются:

   • Авторизованные изменения выполняются в срок и с минимальным количеством ошибок.
   • Проводимые оценки влияния описывают воздействие изменения на все затронутые компоненты
   • Все экстренные изменения оцениваются и авторизуются после изменения
   • Ключевые заинтересованные стороны информированы обо всех аспектах изменения
4. Отметим, что во избежание путаницы, авторы COBIT PAM убрали из этого термина стандарта ISO 15504 слово «management», так как эти практики применимы и к процессам домена руководства (Governance).
5. Такая модель наиболее ярко иллюстрируется любимой многими менеджерами по качеству цитатой из Л. Кэрролла: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!». Можно представить себе повышение уровня возможностей процессов как всё ускоряющийся «бег», позволяющий процессу не отставать от изменяющейся окружающей среды, и «попасть» в целевое состояние и результаты.

Ссылки и публикации

• COBIT® Process Assessment Model (PAM): Using COBIT® 4.1 ISBN 978-1-60420-188-8
• COBIT® Process Assessment Model (PAM): Using COBIT® 5 ISBN 978-1-60420-264-9
• COBIT® 5 A Business Framework for the Governance and Management of Enterprise IT ISBN 978-1-60420-256-4
• ГОСТ Р ИСО/МЭК 15504-1-2009 Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь
• ГОСТ Р ИСО/МЭК 15504-2-2009Информационная технология. Оценка процесса. Часть 2. Проведение оценки
• ГОСТ Р ИСО/МЭК 15504-3-2009 Информационная технология. Оценка процесса. Часть 3. Руководство по проведению оценки.
• http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-Assessment-Programme.aspx домашняя страница COBIT 5 PAM.
• http://www.isaca.org/Knowledge-Center/Research/Documents/Assessment-Programme-Introduction.pptx презентация программы оценки возможностей процессов, применительно для процессной модели COBIT 4.1 (английский, формат Microsoft PowerPoint presentation)

ITIL® - зарегистрированная торговая марка компании AXELOS Limited.
COBIT®, ISACA® - торговые марки ISACA.

Протокол, используемый для уровня 2 в D-канале при выполнении процедуры установления соединения, называется LAPD (L ink A ccess P rocedure on the D -channel). Данный протокол основывается на протоколе LAPB (рекомендация MKKTT X.25). Однако особенности LAPD дают ему ряд важных преимуществ. Прежде всего это мультиплексирование пакетов, имеющих собственные адреса 2-го уровня, позволяющее существовать множеству процедур доступа на одном физическом соединении. Это позволяет нескольким терминалам (до 8) "делить" сигнальный канал между собой. Формат D-канального сигнального сообщения представлен на рис.4

Flag

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

Address

Адресное поле состоит из двух байт. В нем определяется получатель управляющей сигнальной единицы и передатчик посланной единицы (см. рис. 5).

В адресное поле входят бит расширения (EA), индикатор команда/ответ (C/R), идентификатор пункта, обеспечивающего услуги звена передачи данных второго уровня (SAPI), индикатор терминального окончания (TEI).

Бит расширения адресного поля (EA)

"1" указывает на то, что байт - последний в адресном поле.

Индикатор команда/ответ (C/R)

Индикатор указывает, является ли данный пакет командой или ответом на команду. Если пользователь посылает команду, то C/R установлен в "0"; если ответ - в "1". Со стороны сети наоборот: "1" - команда, "0" - ответ.

Индикатор пункта, обеспечивающего услуги звена передачи данных (SAPI)

Указывает класс передаваемой информации. Эти классы информации используются для распознавания сигнальной информации, административной информации 2-го уровня и пакетов пользовательской информации.
Например, цифровые телефоны и терминалы X.25 могут быть подключены к одному стыку S0. Разные типы терминалов имеют разные типы доступа и могут иметь выход на различные сети. Пакеты, передаваемые разными типами терминалов (работающих по разным протоколам), идентифицируются с помощью индикатора SAPI. Шесть бит адресного поля, отведенные под SAPI, могут определить 64 класса информации:

Индикатор терминального окончания (TEI)

Ввиду того, что к одному блоку сетевого окочания может быть подключено несколько пользовательских устройств, станция ISDN присваивает каждой из них уникальный номер, который называется TEI (terminal equipment identifier).

Комбинация SAPI и TEI идентифицирует процедуры звена передачи данных и обеспечивает уникальность адреса для уровня 2. Терминал будет использовать этот адрес во всех передаваемых им пакетах и принимать только те пакеты, которые имеют соответствующий ему адрес.
Например, пакет, несущий информацию от процедур управления телефонным вызовом, помечается SAPI, как принадлежащий телефонии, и все телефонное оборудование пользователя будет проверять его, но только то терминальное оборудование, чей адрес (TEI) указан в данном пакете, примет его для обработки вторым и третьим уровнем.
Не должно существовать двух одинаковых TEI. Для этого сеть осуществляет специальное управление распределением TEI и следит за их правильным использованием. Семь бит адресного поля, используемые для TEI, позволяют назначить 128 идентификаторов терминальных окончаний:

Не автоматически присваемые TEI выбираются и распределяются пользователем. Автоматически присваемые TEI выбираются и распределяются сетью. Общие TEI всегда распределены и обычно называются как TEI для общего оповещения.
Терминалам, которые используют TEI из диапазона от 0 до 63, нет необходимости обмениваться информацией с сетью до начала установления соединения вторым уровнем. Однако правило, что все терминалы пользователя должны иметь различные TEI, действует и по отношению к ним. Пользователь должен сам следить, чтобы не было двух терминалов с одинаковыми, не автоматически присваемыми TEI.
Терминалы, использующие TEI из диапазона от 64 до 126, не могут установить соединение второго уровня до того, как запросят у сети TEI. В этом случае обязанность сети распределять TEI так, чтобы не было повторений.
Общие TEI используются для оповещения всех терминалов с одинаковыми SAPI. Например, оповещение всех телефонов о пришедшем вызове.

Control field (поле управления)

Поле управления определяет тип D-канального сообщения, которое может быть командой или ответом на команду. Оно может состоять из одного или двух байтов, размер его зависит от формата. Существует три типа форматов поля управления: передача информации о номере пакета (I-формат ), функции надзора (S-формат ), неномерованная информация и функции управления (U-формат ).

где:
N(S) - номер посланного сообщения; N(R) - номер принятого сообщения; P - указывает на подтверждение приема пакета уровнем 2 ("1" - пакет принят); S - бит функции супервизора; M - бит модификации; P/F - P используется как указатель подтверждения приема в командах, F используется как указатель передачи пакета в откликах (ответах); X - зарезервирован и установлен в "0".

Information transfer (I) format

I-формат используется при передаче информации между третьими уровнями.

Supervisory (S) format

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

Unnumbered (U) format

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

Information (информационное поле)

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

FCS (поле контрольных бит)

Ввиду того, что при передаче по сети пакеты могут искажаться шумами на первом уровне, в каждом из них присутствует поле контрольных битов (F rame C heck S equence field). Оно состоит из 16 проверочных битов и используется для проверки ошибок в принимаемом пакете. Если пакет принят с неправильной последовательностью проверочных битов, то он сбрасывается.

В ЦСИО обеспечен протокол канального уровня для логиче­ской связи данных, который позволяет ООД взаимодействовать друг с другом по каналу D. Этим протоколом является LAPD, подмножество HDLC. Протокол независим от скорости передачи и требует полнодуплексного прозрачного канала. Он описывается Рекомендацией I.440. В соответствии с этим протокол LAPD предназначен для выполнения многочис­ленных функций, связанных с управлением канала. Прежде всего он обеспечивает мультиплексирование и кодирование информации, контроль последовательности ее передачи, диагностирование каналов. Основными функциями этого протокола являются:

Обеспечение функционирования нескольких логических соединений в каждом канале;

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

Управление последовательностями передаваемых битов;

Обнаружение ошибок в кадрах и уничтожение кадров, содержащихошибки;

Восстановление соединений после сбоев и ошибок;

Передача без подтверждения ненумерованных кадров и с под­тверждением нумерованных кадров.

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

Канальный протокол LAPD во многом похож на LAPB, используемый в Рекомендации Х.25, и произошел от последнего. Более того, LAPD совместим с Х.25/3 - сетевым уровнем, описываемым Рекомендацией Х.25. Отличается LAPD от LAPВ главным образом тем, что может обслуживать не один (как LAP В), а одновременно группу параллельно идущих каналов. Для этого LAPD обеспечивает мультиплексирование передаваемой инфор­мации. С этой целью в канале прокладывается несколько соеди­нений для одновременной работы нескольких комплектов терми­нального оборудования. В этой схеме адрес кадра LAPD идентифицирует не только канал, но и номер адресата.

LAPD предусматривает два байта для адресного поля. Это особенно ценно для мультиплексирова­ния многих функций в канале D. Расширение адресного поля предназначено для обеспечения большего числа битов в этом поле.

Бит в поле указания команды/отклика (К/О) идентифициру­ет, чем является кадр -командой или откликом. Со стороны пользователя отсылаются команды с битом К/О, установленным в 0. Отклики с этой же стороны идут с битом К/О, равным 1. Сеть выполняет все обратным образом. Она отправляет коман­ды, указывая 1 в бите К/О, а отклики -указывая 0.

Через интегральную сеть передаются пакеты, которые упаковываются в кадры. При коммутации каналов образуется последовательность групп каналов, по которой направляются эти кадры. При коммутации пакетов в каждом узле коммутации пакеты переупаковываются в новые кадры, передаваемые по очередной группе каналов. Рекомендация I.440 определяет две формы передачи информации по каждому каналу: одно- и многокадровая. Абонентская система выбирает одну из этих форм либо использует поочередно обе формы. Соответственно передается подтверждение о получении без ошибок одного либо группы кадров. Для этого в LAPD введены две команды и отклики, которые не су­ществуют в множестве HDLC. Это последовательная информа­ция 0(SI0) и последовательная информация 1(SI1). Команды SI0/SI1 предназначены для пересылки информации с использо­ванием последовательно подтверждаемых кадров. От­клики SI0 и SI1 используются при выполнении действий над единичным кадром для подтверждений приема кадров команд SI0 и SI1, а также для индикации потерь кадров или проблем с синхронизацией.

ЦСИО также обращаются к уровню 3. Спецификации уровня 3 (рекомендации I.450 и I.451) включают соединения коммутации каналов, соединения коммутации пакетов и соединения между пользователями.

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

Протокол «Управление вызовом абонента» (см. рис. выше) определен Рекомендацией I.450. Он ориентирован на передачу специальных сообщений. Последние согласуют виды сервиса, используемого при сигнализации, и сообщают о результатах проверки совместимости этого сервиса во взаимодействующих абонентских системах. Обеспечение сквозной (через интегральную сеть) сигнализации осуществляется протоколами уровней 4-7. Второй режим коммутации отличается от первого (см. табл. в начале лекции) более современной методологией. Поэтому первый режим применяется в старых сетях. Для вновь создаваемых интегральных сетей рекомендуется использовать для сигнализации D-канал.

Третий режим (см. ту же табл.) обеспечивает в интегральной сети коммутацию пакетов. Иерархия протоколов в этом режиме показана на рис. 4, из которого следует, что в рассматриваемом режиме используются как протокол LAPD, так и широко применяемый в подсетях коммутации пакетов стандарт LAPВ. На сетевом уровне, как и в указанных подсетях, в интегральной сети используется третий уровень Рекомендации Х.25/3.

Контрольная по информационным сетям и телекоммуникациям (Лабораторная работа)

Брейман А.Д. Сети ЭВМ и телекоммуникации. Глобальные сети (Документ)

Дипломная работа - Построение сети широкополосного абонентского доступа на ГТС г. Алматы (Дипломная работа)

Презентация - Технологии широкополосного доступа. IP-телфония (Реферат)

Дипломный проект - Сеть абонентского доступа (Дипломная работа)

Дипломная работа - Планирование сети доступа NGN для новых групп пользователей (Дипломная работа)

Дипломный проект - Модернизации и расширения сети телекоммуникаций с использованием возможностей системы беспроводного доступа (Дипломная работа)

Наукова стаття - Пассивные оптические сети (PON) (Документ)

Протоколы родительских собраний (Документ)

Шувалов В.Н. Телекоммуникационные системы и сети (3/3) (Документ)

n1.doc

3.3. УРОВЕНЬ LAPD

Протоколы уровня 2 (LAPD - Link Access Procedure on the D-channel) как базового, так и первичного доступа определены в рекомендациях ITU-T 1.440 (основные аспекты) и 1.441 (подроб­ные спецификации). Эти же рекомендации в серии Q имеют но­мера Q.920 и Q.921. Обмен информацией на уровне LAPD осуще­ствляется посредством информационных блоков, называемых кад­рами и схожих с сигнальными единицами ОКС- 7.

Сформированные на уровне 3 сообщения помещаются в ин­формационные поля кадров, не анализируемые уровнем 2. Задачи уровня 2 заключаются в переносе сообщений между пользовате­лем и сетью с минимальными потерями и искажениями. Форматы и процедуры уровня 2 основываются на протоколе управления зве­ном передачи данных высокого уровня HDLC (High-level Data-Link Control procedures), первоначально определенном Международной организацией по стандартизации ISO и образующем подмножест­во других распространенных протоколов: LAPB, LAPV5 и др. Про­токол LAPD, также входящий в подмножество HDLC, управляет потоком кадров, передаваемых по D-каналу, и предоставляет ин­формацию, необходимую для управления потоком и исправления ошибок.

Рис. 3.8. Формат кадра

Кадры могут содержать либо команды на выполнение дейст­вий, либо ответы, сообщающие о результатах выполнения команд, что определяется специальным битом идентификации коман­да/ответ C/R. Общий формат кадров LAPD показан на рис. 3.8.

Каждый кадр начинается и заканчивается однобайтовым фла­гом. Комбинация флага (0111 1110) такая же, как в ОКС-7. Имита­ция флага любым другим полем кадра исключается благодаря за­прещению передачи последовательности битов, состоящей из бо­лее чем пяти следующих друг за другом единиц. Это достигается с помощью специальной процедуры, называемой «бит-стаффингом» (bit-stuffing), которая перед передачей кадра вставляет ноль после любой последовательности из пяти единиц, за исключением фла­га. При приеме кадра любой ноль, обнаруженный следом за по­следовательностью из пяти единиц, изымается.

Адресное поле (байты 2 и 3) кадра на рис. 3.8 содержит иден­тификатор точки доступа к услуге SAPI (Service Access Point Identi­fier) и идентификатор терминала TEI (Terminal Equipment Identifi­er) и используется для маршрутизации кадра к месту его назначе­ния. Эти идентификаторы, уже упоминавшиеся в первом парагра­фе данной главы, определяют соединение и терминал, к которым относится кадр.

Идентификатор пункта доступа к услуге SAPI занимает 6 би­тов в адресном поле и фактически указывает, какой логический объект сетевого уровня должен анализировать содержимое инфор­мационного поля. Например, SAPI может указывать, что содер­жимое информационного поля относится к процедурам управле­ния соединениями в режиме коммутации каналов или к процеду­рам пакетной коммутации. Рекомендацией Q.921 определены зна­чения SAPI, приведенные в табл. 3.1.
Таблица 3.1. Значения SAPI

Идентификатор TEI указывает терминальное оборудование, к которому относится сообщение. Код TEI=127 (1111111) указы­вает на вещательную (циркулярную) передачу информации всем терминалам, связанным с данной точкой доступа. Остальные зна­чения (0-126) используются для идентификации терминалов. Диа­пазон значений TEI (табл. 3.2) разделяется между теми термина­лами, для которых TEI назначает сеть (автоматическое назначе­ние TEI), и теми, для которых TEI назначает пользователь (неав­томатическое назначение TEI).

Таблица 3.2. Значения TEI

При подключении УПАТС (представляющей собой функцио­нальный блок NT2) к АТС ISDN общего пользования с использо­ванием интерфейса PR1 в соответствии с требованиями стандар­тов ETSI, принятых и в России, ТЕ1==0. В этом случае процедуры назначения TEI не применяются.

Бит идентификации команды/ответа C/R (Command/Res­ponse bit) в адресном поле перенесен в DSS-1 из протокола Х.25. Этот бит устанавливается LAPD на одном конце и обрабатывается на противоположном конце звена. Значение C/R (табл.3.3) классифицирует каждый кадр как командный или как кадр ответа. Если кадр сформирован как команда, адресное поле идентифицирует получателя, а если кадр является ответом, адресное поле иденти­фицирует отправителя. Отправителем или получателем могут быть как сеть, так и терминальное оборудование пользователя.

Таблица 3.3. Биты C/R в поле адреса

Бит расширения адресного поля ЕА (Extended address bit) слу­жит для гибкого увеличения длины адресного поля. Бит расшире­ния в первом байте адреса, имеющий значение 0, указывает на то, что за ним следует другой байт. Бит расширения во втором байте, имеющий значение 1, указывает, что этот второй байт в адресном поле является последним. Именно такой вариант приведен на рис. 3.8. Если впоследствии возникнет необходимость увеличить размер адресного поля, значение бита расширения во втором бай­те может быть изменено на 0, что будет указывать на существова­ние третьего байта. Третий байт в этом случае будет содержать бит расширения со значением 1, указывающим, что этот байт являет­ся последним. Увеличение размера адресного поля, таким обра­зом, не влияет на остальную часть кадра.

Два последних байта в структуре кадра на рис. 3.8 содержат 16-битовое поле проверочной комбинации кадра PCS (Frame check sequence) и генерируются уровнем звена данных в оборудовании, передающем кадр. Это поле имеет ту же функцию, что и поле СВ (контрольные биты) в сигнальных единицах ОКС-7 (глава 10 тома 1), и позволяет LAPD обнаруживать ошибки в полученном кадре. В поле FSC передается 16-битовая последовательность, биты которой формируются как дополнение для суммы (по модулю 2), в которой: а) первым слагаемым является остаток от деления (по модулю 2) произведения х k (x 15 +x 14 +…+x+l) на образующий поли­ном (х 16 +х 12 +х 5 +1), где k - число битов кадра между последним битом открывающего флага и первым битом проверочной комби­нации, исключая биты, введенные для обеспечения прозрачности;

б) вторым слагаемым является остаток от деления (по модулю 2) на этот образующий полином произведения х16 на полином, коэф­фициентами которого являются биты кадра, расположенные ме­жду последним битом открывающего флага и первым битом проверочной комбинации, исключая биты, введенные для обеспече­ния прозрачности. Обратное преобразование выполняется уров­нем звена данных в оборудовании, принимающем кадр, с тем же образующим полиномом для адресного поля, полей управления, информационного и FCS. Протокол LAPD использует соглаше­ние, по которому остаток от деления (по модулю 2) произведения х16 на полином, коэффициентами которого являются биты пере­численных полей и FCS, всегда составляет 0001110100001111 (де­сятичное 7439), если на пути от передатчика к приемнику никакие биты не были искажены. Если результаты обратного преобразова­ния соответствуют проверочным битам, кадр считается передан­ным без ошибок. Если же обнаружено несоответствие результатов, это означает, что при передаче кадра произошла ошибка.

Поле управления указывает тип передаваемого кадра и зани­мает в различных кадрах один или два байта. Существует три кате­гории форматов, определяемых полем управления: передача ин­формации с подтверждением (I-формат), передача команд, реали­зующих управляющие функции (S-формат), и передача информа­ции без подтверждения (U-формат). Табл. 3.4, являющаяся клю­чевой в этом параграфе, содержит сведения об основных типах кад­ров протокола DSS-1.

Рассмотрим эти типы несколько подробнее.

Информационный кадр (I) сопоставим со значащей сигналь­ной единицей MSU в ОКС-7 (параграф 10.2 первого тома). С по­мощью 1-кадров организуется передача информации сетевого уров­ня между терминалом пользователя и сетью. Этот кадр содержит информационное поле, в котором помещается сообщение сетево­го уровня. Поле управления 1-формата содержит порядковый но­мер передачи, который увеличивается на 1 (по модулю 128) каж­дый раз, когда передается кадр. При подтверждении приема 1-кад­ров в поле управления вводится порядковый номер приема. Про­цедура организации порядковых номеров рассматривается в сле­дующем параграфе данной главы.

Управляющий кадр (S) используется для поддержки функций управления потоком и запроса повторной передачи. S-кадры не имеют информационного поля и сравнимы с сигнальными еди­ницами состояния звена LSSU в ОКС-7 (параграф 10.2 первого тома). Например, если сеть временно не в состоянии принимать 1-кадры, пользователю посылается S-кадр «к приему не готов» (RNR). Когда сеть снова сможет принимать 1-кадры, она передает другой S-кадр - «к приему готов» (RR). S-кадр также может использоваться для подтверждения и содержит в этом случае поряд­ковый номер приема, а не передачи.
Таблица 3.4. Основные типы кадров LAPD

формат	Команды	Ответы	Описание
Информа­ционные кадры (I)	Информация	-	Используется в режиме с подтверждением для передачи нумерованных кадров, содержащих информационные поля с сообщениями уровня 3
Управля­ющие	К приему готов (PR-receive ready)	К приему готов (RR-receive ready)	Используется для указания готовности встречной стороны к приему I-кадра или для подтверждения ранее полученных 1-кадров
кадры (S)	К приему не готов (RNR)	К приему не готов (RNR)	Используется для указания неготовности встречной стороны к приему I-кадра
	Отказ/переспрос (REJ-reject)	Отказ/переспрос (REJ-reject)	Используется для запроса повторной передачи 1-кадра
	Ненумерованная информация (UI-unnumbered information)		Используется в режиме передачи без подтверждения
		Отключено (DM-disconnected mode)
Ненуме­рованные кадры (U)	Установка расширенного асинхронного балансного режима (SABME-set asynchronous balanced mode extended)		Используется для начальной установки режима с подтверждением
		Отказ кадра (FRMR-frame reject)
	Разъединение (DISC-disconnect)		Используется для прекращения режима с подтверждением
		Ненумерованное подтверждение (UA-unnumbered ask)	Используется для подтверждения приема команд установки режима, например, SABME, DISC

Управляющие кадры можно передавать или как командные, или как кадры ответа.

Ненумерованный кадр (U) не имеет аналогов в ОКС-7. В этой группе имеется кадр ненумерованной информации (UI), единст­венный из группы содержащий информационное поле и несущий сообщение сетевого уровня. U-кадры используются для передачи информации в режиме без подтверждения и для передачи некото­рых административных директив. Чтобы транслировать сообще­ние ко всем ТЕ, подключенным к шине S-интерфейса, станция передает кадр UI с ТЕ1==127. Поле управления U-кадров не содер­жит порядковых номеров.

Как следует из вышеизложенного, информационное поле имеется в кадрах только некоторых типов и содержит информа­цию уровня 3, сформированную одной системой, например, тер­миналом пользователя, которую требуется передать другой систе­ме, например, сети. Информационное поле может быть пропуще­но, если кадр не имеет отношения к конкретной коммутируемой связи (например, в управляющих кадрах, S-формат). Если кадр относится к функционированию уровня 2 и уровень 3 не участвует в его формировании, соответствующая информация включается в поле управления.

Биты P/F (poll/final) поля управления идентифицируют груп­пу кадров (из табл. 3.4), что также заимствовано из спецификаций протокола Х.25. Путем установки в 1 бита Р в командном кадре функции LAPD на одном конце звена данных указывают функци­ям LAPD на противоположном конце звена на необходимость от­вета управляющим или ненумерованным кадром. Кадр ответа с F== 1 указывает, что он передается в ответ на принятый командный кадр со значением Р= 1. Оставшиеся биты байта 4 идентифицируют кон­кретный тип кадра в пределах группы.

И в заключение данного параграфа, с учетом уже детально проанализированной структуры кадра уровня 2 протокола DSS-1, еще раз рассмотрим оба способа передачи кадров: с подтвержде­нием и без подтверждения.

Передача с подтверждением. Этот способ используется толь­ко в соединениях звена данных, имеющих конфигурацию «точка-точка», для передачи информационных кадров. Он обеспечивает исправление ошибок путем повторной передачи и доставку не со­держащих ошибок сообщений в порядке очередности. Этот спо­соб подобен основному методу защиты от ошибок при передаче значащих сигнальных единиц MSU в системе ОКС-7.

Поле управления информационного кадра имеет подполя «номер передачи» и «номер приема» . Эти подполя сопоставимы с полями FSN, BSN в сигнальных единицах MSU системы ОКС-7 (параграф 10.2 первого тома). Протокол LAPD присваивает возрастающие порядковые номера передачи N(S) по­следовательно передаваемым информационным кадрам, а имен­но: N(S)=0, 1, 2,... 127, О, 1,... и т.д. Он также записывает переда­ваемые кадры в буфер повторной передачи и хранит эти кадры в буфере вплоть до получения положительного подтверждения их приема.

Рассмотрим передачу информационных кадров от термина­ла к сети (рис. 3.9). Все поступающие к сети кадры проверяются на наличие ошибок, а затем в свободных от ошибок информацион­ных кадрах проверяется порядковый номер. Если величина N(S) выше (по модулю 128) на единицу, чем N(S) последнего принятого информационного кадра, новый кадр считается следующим по порядку и потому принимается, а его информационное поле пере­сылается конкретной функции сетевого уровня. После этого сеть подтверждает прием информационного кадра своим исходящим кадром с номером приема , значение которого на единицу больше (по модулю 128), чем значение N(S) в последнем приня­том информационном кадре.

Предположим, что последний принятый информационный кадр имел номер N(S)== 11 и что информационный кадр с номером N(S)=12 передан с ошибкой, в результате которой отбракован функциями LAPD на стороне сети. Следующий информационный кадр с N(S)= 13 успешно проходит проверку на ошибки, но посту­пает к сети с нарушением очередности и отбрасывается ею при проверке порядка следования. Тогда сеть передает кадр отказа (REJ) с номером N(R)=12, который запрашивает повторную пе­редачу информационных кадров из буфера повторной передачи терминала, начиная с кадра с N(S)=12. Сетевая сторона продол­жает отбрасывать информационные кадры при проверке их на по­рядок следования, пока не примет повторно переданный кадр с номером N(S)= 12.

Два потока сообщений от терминала к сети и в обратном на­правлении для этого соединения «точка-точка» независимы друг от друга и от потоков сообщений в других соединениях «точка-точка» в том же D-канале. В D-канале с n соединениями типа «точ­ка-точка» могут присутствовать 2п независимых последователь­ностей N(S)/N(R).

Передача неподтверждаемых сообщений. Управляющие кад­ры S и ненумерованные кадры U не содержат подполя N(S). Они принимаются, если получены без ошибок, и не подтверждаются. Управляющие кадры содержат поле N(R) для подтверждения при­нятых информационных кадров.

Ненумерованные информационные кадры UI не содержат ни поля N(S), ни поля N(R), поскольку они передаются в вещатель­ном режиме с ТЕ1==127, а возможность координировать порядко­вые номера передачи и приема для групповых функций во всех тер­миналах, подключенных к одному S-интерфейсу, отсутствует.