Отличительные черты ОСРВ от ОС общего назначения
ОС общего назначения, особенно многопользовательские, такие как UNIX , ориентированы на оптимальное распределение ресурсов компьютера между пользователями и задачами. В операционных системах реального времени подобная задача отходит на второй план - все отступает перед главной задачей - успеть среагировать на события, происходящие на объекте.Другое отличие - применение операционной системы реального времени всегда связано с аппаратурой, с объектом, с событиями, происходящими на объекте. Операционная система реального времени ориентирована на обработку внешних событий. Операционная система реального времени может быть похожа по пользовательскому интерфейсу на ОС общего назначения, однако устроена она совершенно иначе.Кроме того, применение операционных системах реального времени всегда конкретно. Если ОС общего назначения обычно воспринимается пользователями (не разработчиками) как уже готовый набор приложений, то операционная система реального времени служит только инструментом для создания конкретного аппаратно-программного комплекса реального времени. И поэтому наиболее широкий класс пользователей операционных системах реального времени - разработчики комплексов реального времени, люди проектирующие системы управления и сбора данных. Проектируя и разрабатывая конкретную систему реального времени, программист всегда знает точно, какие события могут произойти на объекте, знает критические сроки обслуживания каждого из этих событий.Система РВ должна успеть отреагировать на событие, произошедшее на объекте, в течение времени, критического для этого события. Величина критического времени для каждого события определяется объектом и самим событием, и может быть разной, но время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие реакции в предсказанное время считается ошибкой для систем реального времени.Система должна успевать реагировать на одновременно происходящие события. Даже если два или больше внешних событий происходят одновременно, система должна успеть среагировать на каждое из них в течение интервалов времени, критического для этих событий.
ОС реального времени |
ОС общего назначения |
|
Основная задача |
Успеть среагировать на события, происходящие на оборудовании |
Оптимально распределить ресурсы компьютера между пользователями и задачами |
На что ориентирована |
Обработка внешних событий |
Обработка действий пользователя |
Как позиционируется |
Инструмент для создания конкретного аппаратно-программного комплекса реального времени |
Воспринимается пользователем как набор приложений, готовых к использованию |
Кому предназначена |
Квалифицированный разработчик |
Пользователь средней квалификации |
Системы жёсткого и мягкого реального времени
Различают системы реального времени двух типов - системы жесткого реального времени и системы мягкого реального времени.
Системы жесткого реального времени не допускают никаких задержек реакции системы ни при каких условиях, так как:
- результаты могут оказаться бесполезны в случае опоздания
- может произойти катастрофа в случае задержки реакции
- стоимость опоздания может оказаться бесконечно велика.
Примеры систем жесткого реального времени - бортовые системы управления, системы аварийной защиты, регистраторы аварийных событий.
Системы мягкого реального времени характеризуются тем, что задержка реакции не критична, хотя и может привести к увеличению стоимости результатов и снижению производительности системы в целом.Пример - работа сети. Если система не успела обработать очередной принятый пакет, это приведет к таймауту на передающей стороне и повторной посылке (в зависимости от протокола, конечно). Данные при этом не теряются, но производительность сети снижается.Основное отличие между системами жесткого и мягкого реального времени можно выразить так: система жесткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени - не должна опаздывать с реакцией на событие
Ядро операционной системы
Ядро́ - центральная часть операционной системы (ОС), обеспечивающая приложениям координированный доступ к ресурсам компьютера, память, внешнее аппаратное обеспечение, внешнее устройство ввода и вывода информации, переводя команды языка приложений на язык двоичных кодов, которые понимает компьютер.Как основополагающий элемент ОС, ядро представляет собой наиболее низкий уровень абстракции для доступа приложений к ресурсам системы, необходимым для их работы. Как правило, ядро предоставляет такой доступ исполняемым процессам соответствующих приложений за счёт использования механизмов межпроцессного взаимодействия и обращения приложений к системным вызовам ОС.
Монолитное ядро
Монолитное ядро предоставляет богатый набор абстракций оборудования. Все части монолитного ядра работают в одном адресном пространстве. Это такая схема операционной системы, при которой все компоненты её ядра являются составными частями одной программы, используют общие структуры данных и взаимодействуют друг с другом путём непосредственного вызова процедур. Монолитное ядро - старейший способ организации операционных систем. Примером систем с монолитным ядром является большинство UNIX-систем.
Достоинства : Скорость работы, упрощённая разработка модулей.
Недостатки : Поскольку всё ядро работает в одном адресном пространстве, сбой в одном из компонентов может нарушить работоспособность всей системы.
Некоторые старые монолитные ядра, в особенности систем класса UNIX/Linux, требовали перекомпиляции при любом изменении состава оборудования. Большинство современных ядер позволяют во время работы подгружать модули, выполняющие часть функций ядра. В этом случае компоненты операционной системы являются не самостоятельными модулями, а составными частями одной большой программы, называемой монолитным ядром (monolithic kernel), которое представляет собой набор процедур, каждая из которых может вызвать каждую. Все процедуры работают в привилегированном режиме.
Микроядро
Микроядро предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. Решающим критерием «микроядерности» является размещение всех или почти всех драйверов и модулей в сервисных процессах.
Достоинства : Устойчивость к сбоям оборудования, ошибкам в компонентах системы. Основное достоинство микроядерной архитектуры - высокая степень модульности ядра операционной системы. Это существенно упрощает добавление в него новых компонентов. В микроядерной операционной системе можно, не прерывая её работы, загружать и выгружать новые драйверы, файловые системы и т. д. Существенно упрощается процесс отладки компонентов ядра, так как новая версия драйвера может загружаться без перезапуска всей операционной системы. Компоненты ядра операционной системы ничем принципиально не отличаются от пользовательских программ, поэтому для их отладки можно применять обычные средства. Микроядерная архитектура повышает надежность системы, поскольку ошибка на уровне непривилегированной программы менее опасна, чем отказ на уровне режима ядра.
Недостатки : Передача данных между процессами требует накладных расходов.
Среда исполнения
Требования, предъявляемые к среде исполнения систем реального времени, следующие:
- небольшая память системы - для возможности ее встраивания;
- система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;
- система должна быть многозадачной - для обеспечения максимально эффективного использования всех ресурсов системы;
- ядро с приоритетом на обслуживание прерывания. Приоритет на прерывание означает, что готовый к запуску процесс, обладающий некоторым приоритетом, обязательно имеет преимущество в очереди по отношению к процессу с более низким приоритетом, быстро заменяет последний и поступает на выполнение. Ядро заканчивает любую сервисную работу, как только поступает задача с высшим приоритетом. Это гарантирует предсказуемость системы;
- диспетчер с приоритетом - дает возможность разработчику прикладной программы присвоить каждому загрузочному модулю приоритет, неподвластный системе. Присвоение приоритетов используется для определения очередности запуска программ, готовых к исполнению. Альтернативным такому типу диспетчеризации является диспетчеризация типа "карусель", при которой каждой готовой к продолжению программе дается равный шанс запуска. При использовании этого метода нет контроля за тем, какая программа и когда будет выполняться. В среде реального времени это недопустимо. Диспетчеризация, в основу которой положен принцип присвоения приоритета, и наличие ядра с приоритетом на прерывание позволяют разработчику прикладной программы полностью контролировать систему. Если наступает событие с высшим приоритетом, система прекращает обработку задачи с низшим приоритетом и отвечает на вновь поступивший запрос.
Сочетание описанных выше свойств создает мощную и эффективную среду исполнения в реальном времени.
Кроме свойств среды исполнения, необходимо рассмотреть также сервис, предоставляемый ядром ОС реального времени. Основой любой среды исполнения в реальном времени является ядро или диспетчер. Ядро управляет аппаратными средствами целевого компьютера: центральным процессором, памятью и устройствами ввода/вывода; контролирует работу всех других систем и программных средств прикладного характера. В системе реального времени диспетчер занимает место между аппаратными средствами целевого компьютера и прикладным программным обеспечением. Он обеспечивает специальный сервис, необходимый для работы приложений реального времени. Предоставляемый ядром сервис дает прикладным программам доступ к таким ресурсам системы, как, например, память или устройства ввода/вывода.
Ядро может обеспечивать сервис различных типов:
- Межзадачный обмен. Часто необходимо обеспечить передачу данных между программами внутри одной и той же системы Кроме того, во многих приложениях возникает необходимость взаимодействия с другими системами через сеть. Внутренняя связь может быть осуществлена через систему передачи сообщений. Внешнюю связь можно организовать либо через датаграмму (наилучший способ доставки), либо по линиям связи (гарантированная доставка). Выбор того или иного способа зависит от протокола связи.
- Разделение данных. В прикладных программах, работающих в реальном времени, наиболее длительным является сбор данных. Данные часто необходимы для работы других программ или нужны системе для выполнения каких-либо своих функций. Во многих системах предусмотрен доступ к общим разделам памяти. Широко распространена организация очереди данных. Применяется много типов очередей, каждый из которых обладает собственными достоинствами.
- Обработка запросов внешних устройств. Каждая прикладная программа в реальном времени связана с внешним устройством определенного типа. Ядро должно обеспечивать службы ввода/вывода, позволяющие прикладным программам осуществлять чтение с этих устройств и запись на них. Для приложений реального времени обычным является наличие специфического для данного приложения внешнего устройства. Ядро должно предоставлять сервис, облегчающий работу с драйверами устройств. Например, давать возможность записи на языках высокого уровня - таких, как Си или Паскаль.
- Обработка особых ситуаций. Особая ситуация представляет собой событие, возникающее во время выполнения программы. Она может быть синхронной, если ее возникновение предсказуемо, как, например, деление на нуль. А может быть и асинхронной, если возникает непредсказуемо, как, например, падение напряжения. Предоставление возможности обрабатывать события такого типа позволяет прикладным программам реального времени быстро и предсказуемо отвечать на внутренние и внешние события. Существуют два метода обработки особых ситуаций - использование значений состояния для обнаружения ошибочных условий и использование обработчика особых ситуаций для прерывания ошибочных условий и их корректировки.
Обзор архитектур ОСРВ
За свою историю архитектура операционных систем претерпела значительное развитие. Один из первых принципов построения, монолитные ОС (рисунок 1), заключался в представлении ОС как набора модулей, взаимодействующих между собой различным образом внутри ядра системы и предоставляющих прикладным программам входные интерфейсы для обращений к аппаратуре.
уровневые ОС (рисунок 2).Примером такой ОС является хорошо известная система MS-DOS. В системах этого класса прикладные приложения могли получить доступ к аппаратуре не только посредством ядра системы или ее резидентных сервисов, но и непосредственно. По такому принципу строились ОСРВ в течение многих лет. По сравнению с монолитными ОС такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Недостатком
таких систем является отсутствие в них многозадачности. В рамках такой архитектуры проблема обработки асинхронных событий сводилась к буферизации сообщений, а затем последовательному опросу буферов и обработке. При этом соблюдение критических сроков обслуживания обеспечивалось высоким быстродействием вычислительного комплекса по сравнению со скоростью протекания внешних процессов.
Рисунок 2. Архитектура уровневой ОС
Одной из наиболее эффективных архитектур для построения операционных систем реального времени считается архитектура клиент – сервер. Общая схема ОС работающей по этой технологии представлена на рисунке 3. Основным принципом такой архитектуры является вынесение сервисов ОС в виде серверов на уровень пользователя, а микроядро выполняет функции диспетчера сообщений между клиентскими пользовательскими программами и серверами – системными сервисами. Такая архитектура дает массу плюсов с точки зрения требований к ОСРВ и встраиваемым системам. Среди этих преимуществ можно отметить:
1. Повышается надежность ОС, т.к. каждый сервис является, по сути, самостоятельным приложением и его легче отладить и отследить ошибки.
2. Такая система лучше масштабируется, поскольку ненужные сервисы могут быть исключены из системы без ущерба к ее работоспособности.
3. Повышается отказоустойчивость системы, т.к. «зависший» сервис может быть перезапущен без
перезагрузки системы.
Рисунок 3. Построение ОС с использованием архитектуры клиент-сервер
К сожалению на сегодняшний день не так много ОС реализуется по принципу клиент-сервер. Среди известных ОСРВ реализующих архитектуру микроядра можно отметить OS9 и QNX.
Список использованной литературы:
1) http://ru.wikipedia.org/wiki/Операционная_система_реального_времени
2) http://www.asutp.ru/?p=600591
3) http://www.mka.ru/?p=40774
4) http://www.4stud.info/rtos/lecture1.html
5)http://www.ozon.ru/context/detail/id/3092042/
Быстродействие ПЛК (компьютера) влияет на величину динамической погрешности системы автоматизации и запас ее устойчивости при наличии обратной связи. Для улучшения этих характеристик используют быстродействующие модули ввода-вывода и компьютер (ПЛК) с высокопроизводительным процессором. Это позволяет улучшить динамические характеристики системы, однако большинство операционных систем (ОС) не могут обеспечить одно и то же время выполнения задачи при повторных ее запусках, то есть время выполнения является случайной величиной.
Для устранения этой проблемы был разработан класс операционных систем, которые обеспечивают детерминированное (т.е. не случайное) время выполнения задач и время реакции на аппаратные прерывания. Такие ОС получили название операционных систем реального времени ОС РВ и были поделены на ОС жесткого и мягкого реального времени.
В системах жесткого реального времени существует жесткий временной порог. При его превышении наступают необратимые катастрофические последствия.
В системах мягкого реального времени характеристики системы ухудшаются с увеличением времени управляющей реакции. Система может работать плохо, но без катастрофических последствий.
Для решения задач жесткого реального времени применяют классический подход, т.е. построение событийно управляемой системы. Где для каждого события в системе устанавливается четко определенное время реакции и определенный приоритет. Практическая реализация таких систем сложна и всегда требует тщательной проработки и моделирования.
Следовательно, ОС РВ отличаются своим поведением, а не внутренним принципом построения. К примеру, операционная система Windows XP при управлении медленными (тепловыми) процессами может рассматриваться как ОС РВ, то есть если вероятность появления недопустимо больших задержек достаточно низка для достижения требуемого уровня сервиса.
В ОС жесткого РВ процесс представляется на выполнение одновременно с указанием требуемого времени выполнения. Планировщик ОС либо разрешает выполнение, гарантируя требуемое время, либо отклоняет процесс как невозможный для исполнения. Для этого планировщик должен точно знать, сколько времени требуется каждой функции ОС для выполнения задачи.
Базовыми требованиями для обеспечения режима реального времени являются следующие:
1) высокоприоритетные задачи всегда должны выполняться в первую очередь;
2) должна быть исключена инверсия приоритетов;
3) процессы и потоки, время выполнения которых нельзя планировать, никогда не должны полностью занимать ресурсы системы.
Инверсией приоритетов называют ситуацию, когда поток с высоким приоритетом требует предоставления ресурса, который уже занят потоком с более низким приоритетом.
Основным методом решения этой проблемы в ОС РВ является наследование приоритетов, которое заключается в следующем. Если низкоприоритетный поток блокирует выполнение нескольких высокоприоритетных потоков, то низкоприоритетный поток игнорирует назначенный ему первоначально приоритет и выполняется с приоритетом, который является наивысшим в блоке ожидающих его потоков. После окончания работы поток принимает свой первоначальный приоритет.
Для обеспечения режима реального времени в ОС могут быть реализованы следующие требования
1) поддержка динамических приоритетов,которые можно менять в процессе выполнения задачи, в многозадачном режиме с вытесняющим ядром (как для процессов, так и для потоков);
2) возможность наследования приоритетов;
3) возможность вытеснения задач ядром ОС;
4) ограниченная латентность прерываний (время, в течение которого прерывание запрещено - на время обработки критической секции кода);
5) выполнение сервисов ОС с приоритетом, который назначается клиентом сервиса.
В системах РВ обычно отсутствует виртуальная память, поскольку этот метод использует подкачку страниц с диска, время выполнения которой является непредсказуемым.
Наиболее распространенными в ПЛК и компьютерах для решения задач автоматизации являются операционные системы Windows CE, QNX Neutrino и OS-9.
QNX Neutrino
QNX Neutrino корпорации QNX Software Systems является операционной системой реального времени и обеспечивает многозадачный режим с приоритетами. Поддерживает микропроцессоры семейств ARM,StrongARM, xScale, x86, MIPS, PowerPC, SH-4, способна выполнять до 250 задач на одном узле.
QNX относится к микроядерным ОС, т.е. реализует только базовые функции ядра - управление адресным пространством ОЗУ и виртуальной памяти, процессами и потоками, обеспечивает межпроцессорную коммуникацию. Состоит из ядра, планировщика процессов и сервисов. Построена на основе сервисов - небольших задач, выполняющих основные функции ОС. Такая структура позволяет отключить любую ненужную функциональность, не изменяя ядро. Каждый драйвер, приложение, протокол или файловая система выполняются вне ядра, в защищенном адресном пространстве.
Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов. Операционная система QNX нашла применение как на нижнем уровне АСУТП (ОС для контроллеров), так и на верхнем уровне (ОС для программного обеспечения SCADA).
Операционная система OS-9 фирмы Microware System является многозадачной и многопользовательской, работает в режиме мягкого реального времени. Используется во встраиваемых приложениях на платформах ARM, StrongARM, MIPS, PowerPC, Hitachi SuperH, x86, Pentium, XScale, Motorola 68K.
OS-9 относится к классу Unix-подобных операционных систем реального времени и предлагает многие привычные элементы среды Unix. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули, разработчик может создавать системы с самой разной конфигурацией - от миниатюрных автономных ядер, ориентированных на ПЗУ контроллеров, до полномасштабных многопользовательских систем разработки.
OS-9 обеспечивает выполнение всех основных функций операционных систем реального времени: управление прерываниями, межзадачный обмен информацией и синхронизация задач.
OC WINDOWS
Операционная система Windows знакома всем как настольная система. Но это, прежде всего, относится к платформам Windows 3.хх/95, в которых действительно отсутствует поддержка реального времени. Ситуация резко изменилась с появлением Windows NT.
Сама по себе Windows NT не является операционной системой реального времени в силу ряда ее особенностей. Система поддерживает аппаратные, а не программные прерывания, отсутствует приоритетная обработка отложенных процедур и др.
Но в конце ХХ века ряд фирм предприняли серьезные попытки превратить Windows NT в ОС жесткого реального времени. И эти попытки увенчались успехом. Компания VenturCom разработала модуль Real Time Extension (RTX) - подсистему реального времени (РВ) для Windows NT. Эта подсистема имеет собственный планировщик со 128 приоритетами прерываний, который не зависит от NT. Максимальное время реакции на прерывание составляет 20-80 мкс вне зависимости от загрузки процессора. Теперь при каждом прерывании от таймера приоритет передается критичным по времени задачам. А в оставшееся от их работы время могут выполняться «медленные» процессы: ввод/вывод, работа с диском, сетью, графическим интерфейсом и т. п.
Windows CE.NET
Многозадачная операционная система жесткого реального времени Windows CE.NET корпорации Microsoft поддерживает микропроцессоры с архитектурой ARM, StrongARM и xScale, MIPS, SH, X86-совместимые. 32-разрядная Windows CE была создана компанией Microsoft для малых компьютеров (калькуляторов), но в силу ряда достоинств стала претендовать на роль стандартной ОС реального времени. К числу этих достоинств относятся:
1) открытость и простота стыковки с другими ОС семейства Windows;
2) время реакции порядка 500 мкс;
3) значительно меньшие по сравнению с другими ОС Windows требования к ресурсам памяти и возможность построения бездисковых систем.
4) допускает одновременное выполнение до 32 процессов;
5) имеет 256 уровней приоритетов;
6) поддерживает вытесняющую многозадачность;
7) обеспечивает карусельное исполнение цепочек с одинаковым приоритетом;
8) поддерживает вложенные прерывания;
9) имеет среднее время обработки прерывания 2,8 мкс, поддерживает вложенные прерывания;
10) обеспечивает время обработки потока прерываний (Interrupt Service Thread, IST), равное 17,9 мкс;
11) в минимальной конфигурации может быть установлена при объеме ОЗУ 200 Кб.
Планирование выполняется на основе приоритетов, для устранения инверсии используется наследование приоритетов. Несмотря на наличие возможности работы с виртуальной памятью, для обеспечения режима жесткого реального времени ее отключают.
Windows CE .NET поддерживает Microsoft Visual Studio .NET и Microsoft eMbedded Visual C++ с языками программирования Visual C++, Visual C#, and Visual Basic .NET
А в 1999 году компанией Direct by Koyo ОС Windows CE была впервые установлена на платформу микроPLC.
Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ). Но наибольшую популярность и распространение получили различные варианты ОС Windows (Windows NT/2000). Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации - рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.
Такая ситуация возникла в результате целого ряда причин и тенденций развития современных информационных и микропроцессорных технологий.
Вот несколько основных аргументов в пользу Windows:
Windows имеет очень широкое распространение в мире, в том числе и в России, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;
Эта ОС имеет множество приложений, обеспечивающих решение различных задач обработки и представления информации;
ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;
Приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;
Системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при поэтапном росте;
Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».
Планирование выполнения задач - одна из ключевых концепций в многозадачности и многопроцессорности как в операционных системах общего назначения, так и в операционных системах реального времени. Планирование заключается в назначении приоритетов процессам в очереди с приоритетами. Программный код, выполняющий эту задачу, называется планировщиком
Что такое реальное время (real-time)?
Существует несколько определений понятия реального времени, часто противоречащих друг другу, что не позволяет, к сожалению, принять единую терминологию. Близким к каноническому можно назвать следующее определение: «Система реального времени — это такая система, корректность работы которой зависит не только от выполнения неких заданий, но и от времени их выполнения. Если временные параметры задания нарушены — оно считается невыполненным». Дополнение к этому определению: «Следовательно, сама система должна иметь гарантированные временные параметры, т.е. поведение системы должно быть предсказуемым. Это позволяет минимизировать количество невыполненных (вследствие нарушения временных параметров) заданий».
Хорошим примером системы реального времени является робот, который берет деталь, движущуюся по конвейеру. Если он опоздает, то пропустит один цикл работы конвейера, а попытка взять деталь слишком рано может заблокировать движение других деталей. Другой пример — самолет, летящий на автопилоте. Специальные датчики определяют положение самолета в трехмерном пространстве. Только постоянное и своевременное получение этих данных бортовым компьютером гарантирует безопасность полета.
Иногда системой реального времени называют интерактивную систему с малым временем отклика. Рассмотрим следующий пример: набор текста в программе WinWord 2.0 на компьютере с процессором Athlon 1GHz. Время отклика в данном случае — это промежуток времени между нажатием клавиши и отображением соответствующей буквы в окне программы. Кажется очевидным, что эта величина в данном случае не имеет значения — все равно человек печатает медленнее. Ошибка заключается в подмене понятий — высокая скорость отклика совсем не означает гарантированность отклика. Загружая компьютер большим количеством ресурсоемких задач, мы можем увеличивать время отклика до бесконечности. Проделай следующий опыт: поместив ярлыки всех установленных программ (желательно, чтобы среди них были такие монстрообразные приложения, как Borland Delphi, Microsoft Office, и пара-тройка 3D-шутеров) на рабочий стол Windows95 (желательно билд 450 или более ранний:), выдели их мышью и нажми Enter. После этого винда будет громыхать жестким диском, жонглируя данными между своп-файлом и памятью, и не реагируя на какие-либо внешние воздействия, пока ты не нажмешь кнопку Reset. Обычно этого достаточно, чтобы понять, что быстрая система — не обязательно система реального времени. С другой стороны, реальное время не означает скорость выполнения программы; более того, алгоритмы, гарантирующие конечное время отклика, часто менее эффективны, чем обычные.
В англоязычной литературе упоминаются «soft real-time systems» и «hard real-time systems», но в этом случае не подразумевается программная (software) или аппаратная (hardware) реализация системы реального времени. Термин hard означает, что время отклика (LT — latency time) жестко задано, т.е. является константой. Мягкая (soft) система реального времени (RTS — real-time system) может изменять LT, что увеличивает эффективность RTS, манипулирующей процессами с различными приоритетами. Например, для оцифровки одного кадра видеопотока достаточно LT=0.033с (30 кадров/сек), а для процесса управления сервоприводами необходимо достичь значения LT порядка десятков микросекунд. Иногда термином hard обозначают классическую (описанную выше) модель RTS, а термином soft — систему, не являющуюся RTS в чистом виде, но LT которой снижена до необходимого уровня, обеспечивающего требуемую скорость обработки данных. Например, если компьютер под управлением DOS обрабатывает данные с электронного осциллографа, то это — SoftRTS, т.к. DOS — однозадачная операционная система, и, при условии достаточной скорости компьютера и нормальной работы осциллографа, ничто не должно помешать нам обрабатывать данные с достаточной скоростью (но гарантировать этого мы не можем!). В многозадачных операционных системах также возможна реализация SoftRTS, причем применяемая обычно в мультимедийных приложениях и 3D-играх, т.к. они позволяют обеспечить требуемое LT путем ухудшения качества обработки данных (снижение битрейта, уменьшение FPS, изменение разрешения экрана и глубины цвета).
Операционные системы реального времени
Понимание принципа действия и основных свойств операционных систем реального времени (RTOS — Real Time Operating System) требует введения таких базовых определений, как микроядро (microkernel) и макроядро (macrokernel).
Существует две основные школы ядростроителей (не смог подобрать более точного перевода для kernel
developers:): одна считает, что ядро операционной системы должно быть компактным и быстрым, а функциональность рассредоточена в процессах, другая проповедует более традиционный подход, предоставляя ядру все базовые функции ОС, а процессам — ничего, кроме возможности вызова этих самых функций. Для обозначения первого (по перечислению, а не по времени появления) типа архитектуры в 1989 году Ирой Голдштейн и Полом Дейлом был введен термин микроядро (microkernel). Первая (теперь — в хронологическом смысле) архитектура ядра (традиционная, или монолитная (monolithic), как ее называют в англоязычной литературе) получила название «макроядро» (что наглядно доказывает низкий уровень воображения у программистов, особенно системных).
Споры о том, какая архитектура лучше, идут до сих пор. Большинство реализаций ОС UNIX построены на макроядре, в том числе наиболее популярные на сегодняшний день — Linux и FreeBSD. На микроядре построены такие операционные системы, как Mach и QNX. Впрочем, некоторые системщики не относят Mach к микрокернелам по причине большого размера ядра (оно включает в себя драйвера устройств, что типично скорее для макрокернелов). С ядром QNX сложилась обратная ситуация — оно настолько мало (и по размеру, и по
функциональности), что пришлось ввести новый термин — наноядро (nanokernel). Думаю, что споры вокруг Mach можно было бы решить тем же путем, т.е. изменением терминологии — но, судя по всему, слова сантикернел и децикернел показались программистам недостаточно благозвучными. Следует понимать, что разграничение ОС на микроядра и макроядра производится вовсе не по размеру ядра, а по его архитектуре, т.е. по соотношению между количеством функций, реализованных в ядре, и функций, реализованных вовне ядра. Другие параметры (производительность, гибкость, работа в реальном времени) не могут быть признаками такого разграничения. Кроме того, граница между макрокернелами и микрокернелами становится все более размытой благодаря тому, что многие современные монолитные ядра содержат так называемые нити (threads) и обладают способностью к «мелкозернистому» распараллериванию (а как еще перевести fine-grained parallerism?). Архитектурно такие ядра подобны микрокернелам с большим количеством процессов, работающих в разделяемой (shared) памяти.
Возможность операционной системы работать в реальном времени в значительной степени определяется архитектурой ядра. Наиболее удобными в этом плане являются микроядра (собственно, для этого они и разрабатывались), но это не означает, что все микрокернелы работают в реальном времени (Mach — микроядро, не работающее в реальном времени, что вовсе не умаляет других достоинств этой операционной системы, породившей множество потомков, в том числе NeXTStep, Hurd, BeOS и MacOSX). Существование макрокернела с полноценной поддержкой работы в реальном времени все еще под вопросом (я не нашел никаких сведений о подобном проекте, кроме, разве что, Sun Solaris 2.x, но по моему мнению (не претендующему на компетентность), это скорее SoftRTS, а не HardRTS), а вот частичная реализация — обычное дело. Например, в Linux активно внедряются упоминавшиеся ранее межпроцессорные (от слова процесс, а не процессор) нити, причем уже существует большое количество приложений (первым был Web-сервер Apache), пользующихся этим интерфейсом.
QNX RTOS
Самая популярная в России RTOS — QNX 4.0 (вообще-то Windows NT, но ты много видел людей, которые юзают эНТю именно из-за этого?). Среди других unix-клонов она также занимает уверенное положение — пенетрация (т.е. захваченная доля рынка) этой ОС составляет приблизительно 8-10% — большей распространенности добились только Linux и FreeBSD (захватившие в сумме около половины российского рынка unix-систем). Несмотря на то, что QNX изначально является коммерческой, закрытой и проприетарной, в настоящее время ее модель лицензирования допускает получение и использование на безвозмездной основе как самой ОС (в минимальной конфигурации, конечно, и не для коммерческого использования, но — повторюсь — абсолютно бесплатно и без ограничений по времени), так и исходных кодов (тоже не всех и не для всех — но и это уже немало).
В чем же крутость этой ОС? Тот факт, что она многозадачная, многопользовательская, модульная и POSIX-совместимая, может удивить разве что бородатых полярников, которые свято верят, что пингвин — это такая еда:). Кстати, ОС эта раза в 2 постарше Лынукса. Впрочем, это не показатель. Ты только подумай — 8К микроядро (да-да, восемь килобайт!). Вот это показатель! Именно так достигается рекордное время переключения контекста — 2,5 наносекунды. Дело в том, что ядро управляет только разделением времени между процессами и передачей сообщений. Даже управление процессами и распределение ресурсов для процессов осуществляется отдельной прогой, которая так и называется — менеджер процессов, причем делает это она в соответствии с POSIX 1003.4 (это специальный стандарт на ОСРВ — почитай его, если надумаешь делать GNU QNX:).
Другие характеристики тебя вряд ли заинтересуют — они и не каждому QNX-профи известны и нужны. Поэтому про 12 возможных вызовов микроядра, 32 уровня приоритета и три алгоритма разделения времени (FIFO, круговой и адаптивный) я даже и не заикаюсь.
А вот требования к оборудованию очень советую почитать внимательно:
CPU: 8088, 80286, 80386 и выше
RAM: менее 640Кб (для исполнения), 2Mб (для разработки)
HDD: 5Мб для ОС и утилит (для системы программирования
— еще 4Мб); возможна бездисковая конфигурация.
Только не думай, что требования такие скромные, потому что система примитивная. Самая современная версия QNX (Neutrino 6.2.1) почти такая же жадная до ресурсов, как ХР. Что, испугался? 🙂 Я же сказал — почти! К тому же никто не мешает тебе установить QNX4 на 386 и наслаждаться. Препарируй на здоровье!
Управление автоматическими или автоматизированными комплексами, предъявляющими высокие требования к времени выполнения задач осуществляется операционными системами реального времени. Они обеспечивают гарантированное время реакции на внешние события и минимальные задержки.
Операционная система реального времени , ОС РВ (англ. Real-Time Operating System) - тип , как правило, специального назначения. Для этого термина есть различные определения, порой противоречащие друг другу:
- ОС, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе
- Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах - это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»
- ОС, реагирующая в предсказуемое время на непредсказуемое появление внешних событий
- Интерактивные системы постоянной готовности. В категорию ОС РВ их относят исходя из маркетинговых соображений и если интерактивную программу называют «работающей в реальном времени», то это лишь означает, что запросы от пользователя обрабатываются с задержкой, незаметной для человека.
- Иногда понятие системы реального времени отождествляют с «быстрой системой», но это не всегда правильно, так как важно не время задержки реакции ОС РВ, а то, чтобы этого времени было достаточно для рассматриваемого приложения и оно было гарантированно.
- Во многих специализированных сферах вводят свои понятия «реального времени». Например, процесс цифровой обработки сигнала называют идущим в реальном времени, если анализ и/или генерация данных может быть произведён за то же время, что и анализ/генерация тех же данных без цифровой обработки сигнала. Например, если при обработке аудио данных требуется 2,01 секунд на анализ 2,00 секунд звука, то это не процесс реального времени. Если же требуется 1,99 секунд, то это процесс реального времени.
Для систем реального времени характерно следующее:
- гарантированное время реакции на внешние события (например на прерывания от оборудования);
- жёсткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями);
- повышенные требования к времени реакции на внешние события или реактивности (задержка вызова обработчика прерывания не более десятков микросекунд, задержка при переключении задач не более сотен микросекунд)
Классическим примером задачи, где требуется ОС РВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется и робот имеет лишь маленький промежуток времени, когда он может её взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он спозиционируется раньше, то деталь ещё не успеет подъехать, и он заблокирует ей путь.
Виды ОС РВ
Динамические свойства программ реального времени принято характеризовать тремя определениями: программы «жесткого» (hard), «мягкого» (soft) и интерактивного («условного») реального времени.
Жесткое реальное время . Предусматривает наличие гарантированного времени отклика системы на конкретное событие, например, аппаратное прерывание, выдачу команды управления и т.п. Абсолютная величина времени отклика большого значения не имеет. Так, если необходимо, чтобы программа отработала некоторую команду за 1 миллисекунду, но она справляется с этим заданием лишь в 95% случаев, а в 5% не укладывается в норматив, такую систему нельзя охарактеризовать как работающую в жестком реальном времени. Если же команду нужно отработать в течение часа, что и происходит в 100% случаев – налицо жесткое реальное время.
В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем . При практическом применении время реакции должно быть минимальным.
Мягкое реальное время . В этом случае ожидающееся время отклика системы является величиной скорее индикативной, нежели директивной. Конечно, предполагается что в большинстве случаев (процентов 80 — 90) отклик уложится в заданные пределы. Однако и остальные варианты – в том числе полное отсутствие реакции системы – не должны приводить к плачевным результатам. Обычно считается, что если временной норматив превышен на один порядок, то это еще терпимо.
Интерактивное реальное время . Является скорее психологической, нежели технической характеристикой. Определяет время, в течение которого оператор – человек – способен спокойно, без нервозности, ожидать реакции системы на данные им указания. В качестве примера можно привести весьма популярные сегодня игры из категории «стратегии реального времени» (real-time strategy, см. например квазар на основе Warhammer).
В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline ), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.
Зачастую под СРВ безусловно понимают встроенные операционные системы , на деле же, существует различие между системами реального времени и встроенными системами. От встроенной системы не всегда требуется, чтобы она имела предсказуемое поведение, и в таком случае она не является системой реального времени. Однако даже беглый взгляд на возможные встроенные системы позволяет утверждать, что большинство встроенных систем нуждается в предсказуемом поведении, по крайней мере, для некоторой функциональности, и таким образом, эти системы можно отнести к системам реального времени.
Основные требования к ОС РВ
Мартин Тиммерман (директор компании-разработчика встраиваимых систем Dedicated Systems Experts) сформулировал следующие необходимые требования для ОС РВ:
- ОС должна быть многозадачной и допускающей вытеснение (preemptable),
- ОС должна обладать понятием приоритета для потоков,
- ОС должна поддерживать предсказуемые механизмы синхронизации,
- ОС должна обеспечивать механизм наследования приоритетов,
- поведение ОС должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.); это значит, что во всех сценариях рабочей нагрузки системы должно быть определено максимальное время отклика.
Особенности архитектуры ОС РВ
В течение последних 25-30 лет структура операционных систем эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер. Эти решения в той или иной степени нашли применение и при разработке операционных систем реального времени.
Монолитная архитектура представляет систему, состоящую из набора взаимодействующих модулей. Приложения обращаются к системе через API модулей. Изменения одного модуля влияют на другие модули. Чем больше модулей, чем сложнее они связаны между собой, тем тем менее предсказуемо поведение такой системы в процессе эксплуатации. Кроме того, возникают трудности для использования ОС такого типа в распределенной многопроцессорной системе.
Рис.1. Монолитная архитектура ОС РВ
Многослойная архитектура описывает систему, состоящую из нескольких функциональных уровней. Приложение может обращаться к аппаратным ресурсам как через системные вызовы ядра и системные службы, так и через API уровней. Вообще-то, возможность обращения к нижележащим слоям минуя верхние уровни семантически неверно, но для систем реального времени такая организация позволяет увеличить предсказуемость системы и снизить время отклика. Недостатком многослойной архитектуры является то, что изменения одного слоя влияют на соседние слои. Еще один недостаток, свойственный многослойной архитектуре - отсутствие многозадачности. Однако, далеко не всегда и не всем системам реального времени требуется поддержка многозадачности. Например, сложно обосновать необходимость многозадачного режима для встроенной ОС промышленного робота, подающего детали на конвейер.
Рис.2. Многослойная архитектура ОС РВ
Клиент-серверная архитектура ОС основана на минимизации количества функций, выполняемых ядром (точнее, микроядром ) такой системы. Например, на уровне ядра выполняются только планировщик, примитивы синхронизации и служба сообщений. Вся остальная функциональность выносится на пользовательский уровень и реализуется через серверы. Приложения-клиенты обращаются к ним и получают от них ответы путем обмена сообщениям через службу сообщений уровня ядра.
Рис.3 Клиент-серверная архитектура ОС РВ
Клиент-серверная архитектура позволяет создавать масштабируемые ОС и упрощает распределение в многопроцессорной системе. При эксплуатации системы замена одного модуля не вызывает эффекта “снежного кома”; кроме того, сбой модуля не всегда влечет за собой отказ системы в целом. Появилась возможность динамической загрузки и выгрузки модулей. Главной проблемой в этой модели является защита памяти, поскольку серверные процессы должны быть защищены. При каждом запросе сервиса система должна переключаться с контекста приложения на контекст сервера. При поддержке защиты памяти время переключения с одного процесса на другой увеличивается.
Контрольные вопросы
- Дайте определение операционной системы реального времени
- Что такое deadline ?
- В чем отличие «жесткого» реального времени от «мягкого»
- Сформулируйте основные требования к ОС РВ
- Укажите основные отличия в требованиях к ОС РВ от универсальных ОС
- Опишите модульную архитектуру
- Опишите многослойную архитектуру
- Опишите клиент-серверную архитектуру
Постоянный адрес этой страницы:
Вводный курс лекций
«Управление проектами»
Преподаватель
1.1. Определение понятия «проект» 2
1.2. Типы и виды проектов 4
1.3. Окружение проекта 5
1.4. Основные функции управления проектами 12
1.5 Жизненный цикл и фазы проекта 18
1.6. Начальные условия, ограничения и требования к проекту 21
1.7. Критерии успешности управления проектом 22
1.8. Управление портфелями, программами и проектами организации 25
1.9. Цели проекта 29
1.9.1. Процесс определения целей проекта 31
1.9.2. Описание целей проекта 33
1.9.3. Декомпозиция цели (построение дерева целей) 34
1.10. Подготовка проекта 37
1.11. Разработка бизнес-плана 37
2.1. Особенности подготовки проектов, в основе которых лежит заказ
2.1.1. Требования заказчика 48
2.1.2. Проектное задание 49
2.2. Особенности подготовки проектов, в основе которых лежит идея 50
2.2.1. Логико-структурный подход 52
2.2.2. Логико-структурная матрица 53
2.3. Особенности подготовки проектов, в основе которых лежит проблема 55
2.3.1. Выявление проблем 56
2.3.2. Принятие решения о проектировании 58
3. Дизайн проекта / организация проекта 60
Литература для самостоятельного изучения 62
Вопросы для зачёта 64
1.1. Определение понятия «проект»
Единого общепринятого определения понятия «проект» в литературе не существует.
Германский промышленный стандарт DINопределяет проект как «замысел (намерение), который в значительной степени характеризуется одноразовостью условий в их совокупности, например заданием цели, временными, финансовыми, людскими или другими ограничениями, разграничением от других намерений и специфической организацией выполнения проекта».
Институт проектного менеджмента PMI определяет проект как ограниченное во времени намерение создать уникальный продукт, услугу или результат.
Ограничение во времени подразумевает, что проект должен иметь фиксированное начало и фиксированный конец. Конец наступает, когда достигнуты цели проекта, или когда становится ясно, что цели не будут или не могут быть достигнуты, или когда отпала необходимость в проекте, и он прекращен. Ограничение во времени не означает краткосрочность; многие проекты могут длиться несколько лет. Временные рамки, как правило, не относятся к создаваемому в ходе проекта продукту, услуге или результату. Их жизнь может быть как многократно больше времени выполнения проекта (например, сооружение собора), так и много меньше (например, подготовка выборов). Большинство проектов предпринимается для достижения устойчивого, длительного результата.
Уникальность означает, что продукт или услуга имеет характерные отличия от всех подобных продуктов или услуг. Наличие повторяющихся элементов не изменяет фундаментальное свойство уникальности проекта. Уникальность является существенным признаком проекта, т. е. выполнение рутинных задач не может составлять предмета проекта. Это не означает, что в проекте должны отсутствовать повторяющиеся элементы. Несмотря на то, что зданий строится тысячи, проект каждого нового здания уникален - другой собственник, другой дизайн, другое местоположение, другой подрядчик и т. д.
Текущая деятельность, как правило, представляет собой повторяющийся процесс, поскольку выполняется в соответствии с существующими в организации процедурами. А в проектах возможна неопределенность в отношении продуктов, услуг или результатов, создаваемых в ходе проекта, по причине их уникального характера. Задачи по проекту могут быть новыми для команды проекта, что обусловливает необходимость более тщательного планирования, в отличие от рутинных работ. Кроме того, проекты предпринимаются на всех уровнях организации. В проекте может участвовать один человек, одно структурное подразделение или несколько структурных подразделений организации.
Результатом выполнения проекта может быть:
Продукт, представляющий собой элемент другого изделия или конечное изделие;
Способность предоставлять услуги (например, бизнес-функции, поддерживающие производство или дистрибуцию);
Результаты - последствия или документы (например, исследовательский проект производит данные, которые можно использовать для определения наличия тенденции или пользы какого-либо нового процесса для общества).
Примерами проектов могут служить:
Разработка нового продукта или услуги;
Осуществление изменений в структуре, кадрах и стиле организации;
Разработка или приобретение новой или усовершенствованной информационной системы ;
Строительство здания или сооружения;
Внедрение новой процедуры или нового процесса на предприятии.
Профессор предлагает следующее определение проекта: проект - это ограниченное по времени целенаправленное изменение отдельной системы с установленными требованиями к качеству результатов, возможными рамками расхода средств и ресурсов и специфической организацией. Включение в определение «отдельной системы» указывает не только на целостность проекта и наличие у него границ, но и подчеркивает единственность проекта (в отличие от серийного производства или текущей деятельности организации), а значит, его неповторимость и признаки новизны .
P . Steinbuch дает практичное короткое определение: проект - это одноразовое намерение выполнения задачи .
Таким образом, проект характеризуется:
Определенной целью;
Определенными средствами (человеческие, материальные, финансовые ресурсы);
Определенным временем выполнения;
Уникальностью.
1.2. Типы и виды проектов
Многообразие встречающихся в практической жизни проектов впечатляюще. В принципе, видов проектов столько же, сколько и самих проектов, что определяется уникальностью решаемых задач. Проекты различаются по сферам приложения, масштабу, длительности, сложности и т. д. Проекты можно классифицировать по различным основаниям, например:
- по типу проекта: технический, организационный, экономический, социальный, смешанный;
- по классу: монопроект, мультипроект, мегапроект;
- по масштабу проекта: мелкий, средний, крупный, очень крупный;
- по длительности проекта: краткосрочный, среднесрочный, долгосрочный;
- по сложности проекта: простой, сложный, очень сложный;
- по виду проекта: инвестиционный, инновационный, научно-исследовательский и др.
Очевидно, что приведенная система классификации далеко не единственная и не лучшая. P . Steinbuch , к примеру, выделяет проекты личные, государственные и проекты предприятий. Он подчеркивает, что применение методов проектного менеджмента в ряде случаев полезно и для личных проектов, например таких, как получение образования, заключение брака, смена места работы, строительство дома, проведение юбилея.
Параллельно с ростом числа людей, занятых оказанием услуг, растет и число соответствующих проектов, хотя в литературе им до сих пор почти не уделялось внимания.
1.3. Окружение проекта
Любой проект осуществляется в окружении некоторой динамической среды, частью которой он и сам является. Очевидно, что среда оказывает на него определенное, порой решающее воздействие.
Когда проект начат, он вскоре получает самостоятельную жизнь. Во время осуществления проекта его участники концентрируются на выполнении своих заданий. Они живут, думают и действуют в мире их проекта. В рамках долговременной организации - предприятия возникает маленькая, относительно кратковременная «организация - проект». При этом важно не потерять связь с окружающей действительностью. Руководитель и команда проекта должны понимать и постоянно отслеживать изменения внешней и внутренней среды.
К факторам ближнего окружения проекта, прежде всего, относится руководство предприятия, которое определяет цели и основные требования к проекту. Большое влияние на проект могут оказывать основные структурные подразделения предприятия, инфраструктура предприятия, отношение общественных организаций и коллектива в целом.
К факторам дальнего окружения проекта могут относиться политические факторы, например политическая стабильность, поддержка проекта правительством; экономические факторы (цены, тарифы, налоги и т. п.); законы и право; характеристики общества; уровень развития и состояние науки, техники и технологий; состояние инфраструктуры страны; уровень развития и особенности культуры; природные и экологические факторы.
Существенное влияние на проект, особенно на процесс его успешной реализации, оказывает внутренняя среда проекта.
Внутреннюю среду проекта определяют:
- стиль руководства проектом определяет психологический климат и атмосферу в команде проекта, влияет на ее творческую активность и работоспособность;
- специфическая организация проекта определяет взаимоотношения между основными участниками проекта, распределение прав, ответственности и обязанностей;
- участники проекта реализуют свои различные интересы в процессе осуществления проекта, формируют требования в соответствии с их целями и мотивацией и оказывают влияние на проект в соответствии с собственными интересами, компетенцией и степенью участия в проекте;
- команда проекта является «мозговым центром», мотором и исполнительным органом проекта, от которого во многом зависит прогресс и успех проекта;
- методы и средства коммуникации определяют полноту, достоверность и oпeративность обмена информацией между участниками проекта, что в значительной степени определяет успешность проекта;
- экономические условия проекта связаны со сметой и бюджетом проекта, ценами, налогами и тарифами, риском и страхованием, стимулами и льготами и другими экономическими факторами проекта и факторами, определяющими его основные экономические характеристики;
- социальные условия проекта характеризуются:
Обеспечением стандартных условий жизни для участников проекта,
Предоставляемыми социальными услугами (школы, детские сады, медобслуживание, отдых и т. д.),
Руководитель проекта - лицо, которому заказчик и инвестор делегируют полномочия по руководству работами по осуществлению проекта (планирование, контроль и координацию работ всех участников проекта). Состав функций и полномочий руководителя проекта определяются контрактом с заказчиком. Обычно перед руководителем проекта и его командой ставится задача всеобъемлющего руководства и координации работ на протяжении жизненного цикла проекта до достижения определенных в проекте целей и результатов при соблюдении установленных сроков, бюджета и качества.
Команда проекта - специфическая организационная структура , возглавляемая руководителем проекта и создаваемая на период осуществления проекта. Задача команды проекта - осуществление функций управления проектом до эффективного достижения целей проекта. Состав и функции команды проекта зависят от масштабов, сложности и других характеристик проекта, однако во всех случаях состав команды должен обеспечить высокий профессиональный уровень всех возложенных на псе обязанностей.
Контрактор (генеральный контрактор) - участник проекта, вступающий в отношения с заказчиком и берущий на себя ответственность за выполнение работ по контракту. Это может быть весь проект или его часть. В функции генерального контрактора входит заключение контракта с заказчиком (инвестором), отбор и заключение договоров с субконтракторами, обеспечение координации их работ, принятие и оплата соисполнителей. В качестве контрактора может выступать руководитель проекта или другие активные участники проекта.
Субконтрактор - это лицо (в т. ч. юридическое), которое вступает в договорные отношения с контрактором или субконтрактором более высокого уровня. Он несет ответственность за выполнение работ и услуг в соответствии с контрактом.
Проектировщик - юридическое лицо, выполняющее по контракту проектно-изыскательские работы в рамках проекта. Он вступает в договорные отношения с генеральным контрактором проекта или непосредственно с заказчиком.
Генеральный подрядчик - юридическое лицо, которое выбирается для реализации проекта. Он несет ответственность за выполнение работ в соответствии с контрактом, подбирает субподрядчиков для выполнения отдельных работ и услуг и заключает с ними договоры. В строительных проектах роль генподрядчика обычно выполняют строительные или просктно-строительные фирмы и организации.
Поставщики - субконтракторы, осуществляющие разные виды поставок на контрактной основе (материалы, оборудование транспортные средства и др.).
Лицензор - организации, выдающие лицензии на право владения земельным участком, ведения торгов, выполнения определенных видов работ и услуг и т. п.
Органы власти - сторона, удовлетворяющая свои интересы путем получения налогов от участников проекта, выдвигающая и поддерживающая экологические, социальные и другие общественные и государственные требования, связанные с реализацией проекта.
Владелец земельного участка - юридическое или физическое лицо, являющееся владельцем участка земли, вовлеченного в проект. Он вступает в отношения с заказчиком и передает на договорной основе право пользования или владения этим участком земли.
Производитель конечной продукции проекта - эксплуатирует созданные основные фонды и производит конечную продукцию. Его главная цель состоит в получении прибыли от продажи готовой продукции потребителям. Он принимает участие на всех фазах проекта и взаимодействует с основными участниками проекта. Его роль и функции зависят от доли собственности в конечных результатах проекта. Во многих случаях он является заказчиком и инвестором проекта.
Потребители конечной продукции - юридические и физические лица, являющиеся покупателями и пользователями конечной продукции, определяющие требования к ней и оказываемым услугам, а также масштаб рыночного спроса. Именно за счет средств потребителей возмещаются затраты на проект и формируется прибыль всех участников проекта.
Другие участники проекта. На осуществление проекта оказывают влияние и другие стороны из окружения проекта, которые по существу также могут быть отнесены к стейкхолдерам проекта:
Конкуренты основных стейкхолдеров проектов;
Общественные группы и население, чьи экономические и внеэкономические интересы затрагивает осуществление проекта;
Спонсоры проекта;
Различные консалтинговые , инжиниринговые , юридические организации, вовлеченные в процесс осуществления проекта, и др.
Кроме субъектов - индивидов, групп, организаций - в число стейкхолдеров (в данном случае термин «участники проекта» совсем не подходит) рекомендуется также включать гак называемых «безмолвных» стейкхолдеров, а именно:
Будущие поколения (их еще нет, но их интересы необходимо учесть, чтобы не создать проблем нашим вмешательством в сегодняшнюю реальность, как это сделали с нами предыдущие поколения, - долги, исчерпание даже возобновляемых ресурсов , проблема атомных и промышленных отходов, кислотные дожди и т. п.);
Прошлые поколения (их уже нет, но их интересы представлены оставленной ими культурой. Мы не должны наносить ущерб материальной или духовной культуре);
Окружающая среда (мы не должны вредить среде нашего обитания, живой и неживой природе).
Для определения полного состава стейкхолдеров проекта, построения его функциональной и организационной структур для каждого проекта на стадии разработки концепции проекта должны быть определены:
1. Предметная область - цели, задачи, работы и основные результаты, т. е. «что нужно сделать, чтобы реализовать проект?», а также его масштабы, сложность, допустимые сроки.
2. Отношения собственности, вовлеченной в процесс осуществления проекта (что, сколько стоит и кому принадлежит?).
3. Основные идеи реализации проекта (как сделать?).
4. Основные стейкхолдеры проекта (кого касается проект?).
5. Основные активные участники проекта (кто будет делать?).
6. Мотивации участников проекта (возможные подходы, ущербы, риски и т. д.).
Ответы на эти вопросы позволяют выявить релевантных стейкхолдеров проекта, их цели, мотивации, определить взаимоотношения и на этой основе принять обоснованные решения по организации и управлению проектом.
Управление проектом включает:
- идентификацию требований к проекту;
Удовлетворение различных потребностей, решение проблем и удовлетворение ожиданий различных стеикхолдеров проекта в ходе планирования и выполнения проекта;
Установление ясных и достижимых целей;
Адаптацию спецификаций, планов и подходов к различным интересам и ожиданиям стейкхолдеров проекта;
Балансирование противоречивых требований к качеству, объему работ, времени выполнения и стоимости.
Удовлетворение или превышение нужд и ожиданий стеикхолдеров проекта неизменно включает баланс противоречивых требований между:
Стейкхолдерами проекта с различными нуждами и ожиданиями;
Идентифицированными требованиями (нуждами) и не идентифицированными требованиями (нуждами).
В связи со стремлением добиться такого баланса план управления проектом приобретает итеративный характер и проходит через последовательную разработку на различных стадиях жизненного цикла проекта. По мере накопления информации план управления проектом детализируется и улучшается. Последовательная разработка позволяет команде осуществлять управление на более детальном уровне по мере развития проекта.
Сфера управления проектами имеет свою уникальную область знаний, частично пересекающуюся с соседними областями. Область общего управления содержит знания, которые следует иметь каждому менеджеру проекта. Область технического управления содержит специальные знания в конкретной области деятельности. Это то, что делает менеджера проекта специалистом в этой области. Вспомогательные и поддерживающие дисциплины помогают менеджеру проекта лучше выполнять свои функции.
1.4. Основные функции управления проектами
В международном стандарте РМВоК подробно рассматриваются девять функций управления проектами:
1. Управление интеграцией проекта.
2. Управление содержанием (предметной областью) проекта.
3. Управление сроками проекта.
4. Управление стоимостью проекта.
5. Управление качеством проекта.
6. Управление человеческими ресурсами проекта.
7. Управление коммуникациями (взаимодействиями и информационными связями) проекта.
8. Управление рисками проекта.
9. Управление контрактами и обеспечением проекта.
1. Управление интеграцией проекта включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и действий по управлению проектом:
- разработку Устава проекта - процесс разработки документа, который формально санкционирует проект или фазу и документирует первоначальные требования, удовлетворяющие потребности и ожидания стейкхолдеров проекта;
- разработку плана управления проектом - процесс документирования действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов;
- мониторинг и управление работами проекта - процесс отслеживания, проверки и регулирования исполнения для достижения целей проекта, определенных в плане управления проектом;
- осуществление общего управления изменениями - процесс проверки всех запросов на изменение, их утверждения и управления изменениями результатов, активов, процессов организации, документов проекта и плана управления проектом;
- завершение проект или фазы - процесс завершения всех операций, всех групп процессов управления проектом с целью формального завершения проекта или фазы.
2. Управление содержанием проекта . Цели проекта, задачи и работы, которые нужно выполнить для их достижения, вместе с требуемыми ресурсами определяют предметную область проекта, его содержательную сущность (англ. - scope ). Поскольку цели, задачи, работы, их объемы и/или другие элементы предметной области проекта в процессе его «жизни» претерпевают изменения, то возникает необходимость управления содержанием (предметной областью) проекта.
Управление содержанием проекта включает в себя процессы, обеспечивающие включение в проект тех и только тех работ, которые необходимы для успешного завершения проекта:
- сбор требований - процесс определения и документирования потребностей стейкхолдеров проекта для достижения целей проекта;
- определение содержания - процесс разработки подробного описания проекта и продукта;
- создание структурного плана проекта (СИП) - процесс разделения результатов проекта и работ проекта на более мелкие элементы, которыми легче управлять;
- подтверждение содержания - процесс формализованной приемки завершенных результатов проекта;
- управление содержанием - процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию.
3. Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершение проекта:
- определение операций - процесс определения конкретных операций, которые необходимо выполнить для получения результатов проекта;
- определение последовательности операций - процесс выявления и документирования зависимостей между операциями проекта;
- оценку ресурсов операций - процесс оценки типов и количества материалов, человеческих ресурсов, оборудования или поставок, необходимых для выполнения каждой операции;
- оценку длительности операций - процесс приблизительного определения количества рабочих периодов, требуемых для завершения отдельных операций при предполагаемых ресурсах;
- разработку расписания - процесс анализа последовательностей операций, их длительности, потребности в ресурсах и временных ограничений для создания расписания проекта;
- управление расписанием - процесс мониторинга статуса проекта для корректировки его исполнения и внесения изменений в базовое расписание.
4. Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и управления расходами и обеспечивающие завершение проекта в рамках утвержденного бюджета:
- определение бюджета - процесс суммирования оценок стоимости отдельных операций или пакетов работ для формирования санкционированного базового плана по стоимости;
- управление стоимостью - процесс мониторинга статуса проекта для корректировки бюджета проекта и внесения изменений в базовый план по стоимости.
5. Управление качеством проекта включает в себя процессы и действия исполняющей организации, политику в области качества, цели и сферы ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, ради которых он был предпринят:
- планирование качества - процесс определения требований и / или стандартов качества для проекта и продукта, а также документирования того, каким образом проект будет демонстрировать соответствие установленным требованиям и стандартам;
- осуществление обеспечения качества - процесс проверки соблюдения требований к качеству и результатов измерений в процессе контроля качества для обеспечения применения соответствующих стандартов качества и оговоренных требований;
- осуществление контроля качества - процесс контроля и записи результатов выполнения действий по обеспечению качества для оценки исполнения и разработки рекомендаций относительно необходимых изменений.
6. Управление человеческими ресурсами проекта включает в себя процессы по организации команды проекта и управления ею:
- планирование человеческих ресурсов - определение и документальное оформление ролей, ответственности и подотчетности, а также создание плана управления обеспечением проекта персоналом;
- набор команды проекта - привлечение человеческих ресурсов, необходимых для выполнения проекта;
- развитие команды проекта - повышение квалификации членов команды проекта и укрепление взаимодействия между ними с целью повышения эффективности исполнения проекта;
- управление командой проекта - контроль за эффективностью членов команды проекта, обеспечение обратной связи, решение проблем и координация изменений, направленных на повышение эффективности исполнения проекта.
7. Управление коммуникациями проекта - это область знаний, включающая в себя процессы, необходимые для своевременного создания, сбора, распространения, хранения, получения и в конечном итоге использования информации проекта:
- планирование коммуникаций - определение потребностей участников проекта в коммуникации и информации;
- распространение информации - своевременное предоставление необходимой информации участникам проекта;
- отчетность по исполнению - сбор и распространение информации о выполнении работ. Эта информация включает в себя отчеты о текущем состоянии, оценку прогресса и прогнозирование;
- управление участниками проекта - управление коммуникациями в целях удовлетворения требований участников проекта и решения возникающих проблем.
8. Управление рисками проекта включает в себя процессы, относящиеся к планированию управления рисками , их идентификации и анализу, реагированию на риски, мониторингу и управления рисками проекта:
- планирование управления рисками - выбор подхода, планирование и выполнение операций по управлению рисками проекта;
- идентификацию рисков - определение того, какие риски могут повлиять на проект, и документальное оформление их характеристик;
- качественный анализ рисков - расположение рисков по степени их приоритета для дальнейшего анализа или обработки путем оценки и суммирования вероятности их возникновения и воздействия на проект;
- количественный анализ рисков - количественный анализ потенциального влияния идентифицированных рисков на общие цели проекта;
- планирование реагирования на риски - разработка возможных вариантов и действий, способствующих повышению благоприятных возможностей и снижению угроз для достижения целей проекта;
- мониторинг и управление рисками - отслеживание идентифицированных рисков, мониторинг остаточных рисков, идентификация новых рисков, исполнение планов реагирования на риски и оценка их эффективности на протяжении жизненного цикла проекта.
9. Управление контрактами и обеспечением проекта включает в себя процессы покупки или приобретения тех необходимых продуктов, услуг или результатов, которые производятся вне исполняющей организации:
- планирование покупок и приобретений - определение того, что необходимо купить или приобрести, а также когда и на каких условиях;
- планирование контрактов - представление в документальном виде требований к продуктам, услугам и результатам, которые необходимо приобрести, а также определение потенциальных продавцов;
- запрос информации у продавцов - получение информации, расценок, оферт или предложений (в зависимости от поставки) от продавцов;
- выбор продавцов - анализ предложений, отбор потенциальных продавцов и обсуждение условий контракта с каждым продавцом;
- администрирование контрактов - управление контрактом и взаимоотношениями между покупателем и продавцом, анализ и документальное оформление текущей и прошлой деятельности продавца для определения необходимых корректирующих действий и обеспечения основы для будущих отношений с продавцом, управление изменениями, связанными с контрактом, и при необходимости управление контрактными взаимоотношениями со сторонним покупателем проекта;
- закрытие контрактов - завершение каждого контракта, включая разрешение всех открытых вопросов, и закрытие каждого контракта, относящегося к проекту или к фазе проекта.
1.5. Жизненный цикл и фазы проекта
Все проекты предпринимаются для достижения некоторой цели или решения какой-либо задачи: создания продукта, предоставления услуги, получения какого-либо результата. Жизненные циклы проекта и продукта (услуги, результата), как правило, не совпадают. Иногда жизненный цикл проекта бывает длиннее (например, организация выборной компании), но чаще всего он короче жизненного цикла продукта/услуги.
По современным воззрениям, принимая во внимание концепцию устойчивого развития человеческого общества, команда проекта должна понимать и учитывать полный жизненный цикл продукта (услуги, результата). Последними фазами жизненного цикла продукта, как правило, являются прекращение производства, сервисного обслуживания и поддержки и, наконец, утилизация продукта. Учет этого обстоятельства при выполнении проекта позволяет облегчить жизнь в будущем. Как показал опыт создания и ликвидации ядерных реакторов , затраты на их ликвидацию могут быть заметно выше затрат на их создание.
Проекты различаются по размеру и сложности. Независимо от размеров и степени сложности все проекты могут иметь следующую обобщенную структуру жизненного цикла:
Начало проекта;
Организация и подготовка;
Выполнение работ проекта;
Завершение проекта.
Фазы проекта - это отдельные части в рамках проекта, требующие дополнительного контроля для эффективного получения основного результата проекта. Они позволяют разделить проект на логические подгруппы для более легкого управления, планирования и контроля. Фазы проекта обычно выполняются последовательно, но в некоторых проектных ситуациях могут перекрываться. При последовательном выполнении фаз завершение фазы сопровождается передачей полученного результата в следующую фазу. Такое завершение фазы представляет собой естественную точку для переоценки предпринимаемых усилий и при необходимости для изменения или досрочного завершения проекта. Эти точки называются выходами фаз, контрольными событиями, воротами фаз, воротами решений, воротами этапов, точками критического анализа или точками остановки. Как правило, работы фазы имеют свойства, которые отличают ее от других фаз. При этом могут привлекаться разные организации и использоваться разные наборы навыков.
Планирование должно давать ответы на шесть вопросов:
- Что должно быть сделано? Что является целью, предметом и содержанием проекта?
- Кто может это сделать? Имеются ли соответствующие специалисты внутри предприятия или нужно привлекать сторонних? Кому будет поручена работа?
- Как следует выполнять работу? Нужно ли соблюдать специальные предписания, нормы, пользоваться определенными способами?
- Чем должна выполняться работа? Какие средства и ресурсы необходимы для ее проведения?
- Когда работа должна быть выполнена? К какому сроку она должна быть закончена и, соответственно, не позднее какого срока она должна быть начата?
Нередко фаза планирования подразделяется еще на ряд стадий.
Патентованных рецептов с указанием, до какой степени точности необходимо рассматривать детали проекта уже на стадии планирования или достаточно задать только некоторые рамки, предоставив руководителю проекта большую свободу для действий и решений, не существует. Справедливо правило: планирования столько - сколько необходимо, и максимум делегирования ответственности и полномочий как можно ближе к рабочему месту.
Фаза управления проектом в наибольшей степени зависит от конкретного содержания работ. Следует только отметить, что в этой фазе нередко требуются решения особого вида, когда возникают отклонения, которые уже не могут быть скомпенсированы в рамках проекта и которые угрожают самой возможности достижения цели.
Во многих случаях с завершением фазы выполнения проекта цель проекта оказывается достигнутой. Но часто требуется еще обучение персонала и поддержка при освоении. Особое значение имеет эта фаза при внутренних проектах. Обычно цель всего мероприятия достигается только тогда, когда новые технологии, структуры и т. п. становятся ежедневной практикой и успешно используются работниками. Зачастую эта фаза требует гораздо больше времени, чем вначале предполагалось.
Фаза контроллинга является сопровождающей функцией для всех фаз проекта. Во время фазы планирования задачей контроллинга является поддержка процессов планирования и принятия решений, проверка соответствия частных планов целям проекта, их полноты и непротиворечивости. В фазе выполнения проекта фактические результаты сравниваются с заданными, чтобы выявить отклонения от плана, проанализировать их причины и принять меры по исправлению положения. После завершения проекта должен быть проверен результат и должен быть зафиксирован и задокументирован опыт для будущих проектов.
1.6. Начальные условия, ограничения и требования к проекту
Начальные условия, ограничения и требования к проекту являются необходимой составной частью исходных данных для разработки и выбора концепции проекта. Они характеризуют:
Предысторию и существующее состояние системы;
Существующее состояние окружения предлагаемого проекта;
Требования к результатам проекта и способам их достижения, в частности должно быть указано и письменно зафиксировано, что команда проекта по техническим, этическим, политическим и другим причинам делать не может;
Ограничения на количественные параметры и допустимые пределы (границы): объемов, качества, расходов и доходов, сроков, продолжительности, потребляемых ресурсов, риска и др.
Важным моментом является четкое определение требований к документации проекта. С одной стороны, повышение эффективности использования времени как главного невозобновляемого ресурса требует минимизации всех бюрократических процедур и бумаготворчества.
С другой стороны, человеку свойственно не только забывать сказанное, но и через некоторое время совершенно по-иному его интерпретировать. Поэтому для исключения недоразумений и конфликтов необходимо все существенные договоренности, решения, результаты и т. п. фиксировать письменно, по возможности без излишней формализации.