CC BY
7Труды МАИ. Выпуск № 100
http://trudymai.ru/
УДК 658.5
Методика моделирования в жизненном цикле большой автоматизированной системы космодрома уровня Smart City
Бадалов А.Ю., Разумов Д. А.*
Российская Корпорация Средств Связи, 2-я Звенигородская ул., 13, стр. 40, Москва, 123022, Россия *e-mail: Razumov@pkcc.ru
Аннотация
Проектирование и развитие крупномасштабных автоматизированных систем (АС) всегда связано с преодолением большого числа неопределённостей, структурирование которых часто осуществляется за счёт использования практики стандартов и моделирования в рамках направления Systems & Software Engineering. Методы анализа больших систем (БС) предполагают их декомпозицию в контексте структурной и/или функциональной парадигм, которые позволяют рассматривать полученные составляющие как объекты для моделирования, функционального, имитационного (ИМ) и т.д. При проектировании АСУ космодрома регионального уровня возникает необходимость оптимизации принимаемых решений. Подобные системы функционируют всегда и непрерывно, независимо от уровня автоматизации. В этом смысле время их действия обладает мощностью континуума. Поэтому в настоящей работе предлагается методика моделирования именно в жизненном цикле (ЖЦ) большой АС космодрома, в том числе с использованием
имитационной модели для оптимизации ключевых показателей эффективности (КПЭ) системы.
Ключевые слова: жизненный цикл системы, большая система, Systems & Software Engineering, Smart City.
1. Введение
Уже на начальных этапах становления Systems Engineering для моделирования использовались различные методы математической науки: численные методы, математическая статистика, теория игр и др. Достижения в информационных технологий (ИТ) позволили привнести в практику создания больших АС такие мощные инструменты как имитационное моделирование. Во многих случаях имитационное моделирование - единственный способ получить представление о поведении сложной системы и провести её анализ. АСУ космодрома - это большая система (БС), в узлах которой расположены центры принятия решений, связанные информационными потоками и оперирующие силами и средствами из состава государственных, военных и муниципальных учреждений. В последнее время подобные решения принято оформлять на уровне парадигмы SmartCity, которая предполагает интеграцию деятельности всех служб и систем регионального и техногенного комплекса, каковым, прежде всего, является Космодром, в едином операционном контексте.
«Реализация проекта позволит с помощью специальных аппаратных средств обеспечить процесс не только контроля в городе с точки зрения техногенной
обстановки природных и погодных изменений, но и, в целом, создать максимально комфортную среду, позволяя экономить на ресурсах ЖКХ и обеспечить полную безопасность жителей. С учетом того, что ЗАТО "Углегорск" - это, в целом, закрытое территориальное образование, мы будем здесь, как на экспериментальной площадке, реализовывать идею "Умного и безопасного города", - сказал Рогозин. Город Углегорск в Амурской области расположен неподалеку от строящегося космодрома "Восточный ". В настоящее время Углегорску дали новое имя -Циолковский.
Целью создания АСУ космодрома (АСУК) является повышение качества управления сложным техногенным комплексом, в структуру которого входят органы оперативного управления, центры обработки вызовов и диспетчерские службы различных государственных, региональных и муниципальных структур, повышение оперативности реагирования на различные ситуации, или предотвращение вероятности (угрозы) их возникновения, повышение качества информированности этих служб, оперативного реагирования и координации их совместных действий. АСУК является органом повседневного и непрерывного во времени управления. АСУК способствует улучшению качества взаимодействия различных служб и ведомств в ходе выполнения специальных и повседневных задач, реагирования на события различного характера, повышению скорости реакции системы в целом, исключению дублирования функций и повышению эффективности использования средств государственных и региональных бюджетов, направляемых на эти нужды.
В свою очередь, АСУК предназначена для технического и информационного сопровождения принятия решения, координации действий служб посредством создания единого организационно-технического механизма, основанного на современных технологиях обработки, передачи и представления данных, использовании высокопроизводительных вычислительных и программных комплексов, а также средств космической спутниковой навигации, геоинформационных систем и других технологий. Таким образом, целями внедрения АСУК являются:
• обеспечение сокращения времени реагирования вышеперечисленных служб на события повседневного, чрезвычайного и комплексного характера,
• координация действий этих служб для повышения качества выполнения задачи.
Система должна предоставлять механизм поддержки действий для организации мероприятий по управлению ситуациями, как с рабочих мест в центрах управления, так и непосредственно в районах разворачивающихся событий на основе накопления, анализа (обработки) данных и реагирования на поступающие сообщения о событиях, происшествиях, техногенных катастрофах, обеспечения организации устойчивого взаимодействия с ответственными структурами министерств и ведомств.
Сложность обусловлена и тем, что организация таких систем не имеет под собой однозначной структурной реализации и определяется множеством факторов (наличие каналов связи, уровень автоматизации дежурных служб, взаимодействие ведомств, уровень финансового обеспечения и т.д.). Таким образом, проектирование
подобных БС связано с декомпозицией общей проблемы на уровне парадигмы жизненного цикла (ЖЦ)[1] в контексте структурно-функциональной компонентной иерархии, в узлах которой находятся дежурные диспетчерские службы (ДДС) и центры управления (ЦУ). Кроме того, проблемы организационного и регламентного взаимодействия требуют достаточно гибкого подхода к реализации на каждом этапе ЖЦ.
Задачи проектирования данной структуры до настоящего времени содержат во многом элементы неопределённости. Требования о количестве операторов, ресурсов реагирования и соответственно мощности и производительности вычислительных комплексов и не только в проектной документации не имеют под собой чёткого количественного и научного обоснования и разрабатываются в лучшем случае на основе сравнительных оценок из истории функционирования уже имеющихся реализаций. Однако это не является достаточным основанием для определения параметров проектируемой системы. Нередки случаи, когда подобные решения приводят к краху проекта, неоптимальному использованию имеющихся финансовых, материальных, кадровых и иных средств.
С другой стороны, проблема моделирования, в том числе имитационного, обобщённой структуры системы заключается в отсутствии необходимого количества статистической и иной информации единовременно по всем объектам. Авторы предлагают методику, которая обеспечивает построение достаточно адекватных моделей, помогающих принимать обоснованные решения, в этих ограничениях.
3. Структурно-функциональные подходы к декомпозиции системы
Данная задача обладает значительной степенью неопределённости с точки зрения построения базовой структуры управления и зависит от множества факторов, уровень значимости которых на столько специфичен и зависит от серии обстоятельств, учесть которые не всегда возможно с высокой долей вероятности.
Среди наиболее значимых здесь следует отметить:
1. Уровень взаимоотношений между государственными корпорациями (Роскосмос, ПАО «Россети», Спецстрой, Ростелеком и т.д.) и ведомствами центрального подчинения (МО, МВД, МЧС), степень влияния на процессы в данный момент каждого из них.
2. Полномочия и авторитет главного должностного лица - начальника космодрома или лица выполняющего его обязанности.
3. Уровень взаимодействия с местными региональными властями и степень их заинтересованности в развитии проекта.
4. Наличие и уровень развития инфраструктуры региона (каналы связи, оснащение средствами вычислительной техники, электрогенерация и распределительные сети, железнодорожная и автомобильная инфраструктура и т.д.).
5. Уровень финансирования, государственного, по линии отдельных ведомств, региональный бюджет.
6. Наличие в каждом из перечисленных ведомств локальных решений и уровень их адаптивности в смысле Inter Process Communication (IPC).
7. Готовность локальных центров управления переходить на централизованное решение и наличие ресурсов для этого.
8. Наличие подготовленных кадров и многое другое.
В связи с этим возникает как минимум три «экстремальные модели» построения структуры управления и различные варианты, которые могут возникнуть на основе влияния тех или иных факторов из вышеперечисленных на эти структуры. При этом следует отметить, что в процессе ЖЦ системы, её структура может меняться и обозначенные модели могут переходить одна в другую. Т.е. структура системы на данной стадии ЖЦ соответствует определённой комбинации условий, определяемой вышеперечисленными факторами.
Поэтому сначала рассматриваются эти три экстремальные (вырожденные в смысле конфигурации) модели, их преимущества и недостатки, описываются структурные аспекты построения АС, применяемые в Российской Федерации. Показана неоднозначность применяемых подходов, их разнообразие и зависимость от перечисленных факторов. Даётся понимание того, что какой-то общей схемы построения АС космодрома регионального уровня не существует, кроме того, эта схема меняется на различных этапах ЖЦ системы. Поэтому каждый этапный проект является уникальным в своём роде и соответственно требует от поставщиков различного уровня и от потребителя индивидуальных подходов, зависящих от совокупности факторов, определяемых на различных фазах ЖЦ системы как ключевые.
Структуру системы управления космодрома регионального уровня, как правило, составляют центры управления (ЦУ), центры обработки вызовов (ЦОВ) и дежурные диспетчерские службы различного уровня и подчинения (Рисунок 1).
Главный ЦУ •Анализ, отчёт • Консолидация • Разработка стратегии • Координация действий • Кросс организационное управление Per и ион Главный ССС
С&С центр МО • Контроль ЬСССэ з ■ Консолидация • Контроль статуса операции • Распределение региональн ресурсов / МО, площадки, НИ( 1 RCCC RCCC RCCC/LCCC
Локальный С&С центр • Оповещение и первичная реакция • Обработка событий • Распределение ресурсов / ДЧ. КВО \ v^jMj LCCC LCCC LCCC Операционный уровень
Рисунок 1. Региональная структура управления космодрома
На верхнем уровне иерархии располагается главный центр управления ССС
(Command Control Center в терминах C4I). Это может быть при определённом стечении обстоятельств ситуационный центр (СЦ) губернатора, если структура демилитаризована (Байконур) или находится на ранней стадии развития (Восточный) или ССС одной из главных на данном этапе развития системы структур, например ведомственный СЦ Спецстроя, на стадии строительства космодрома, Единая Дежурная Диспетчерская Служба регионального города Циолковский и т.д. Таким образом, основной акцент в управлении КВО делается на тот орган, который наиболее соответствует текущей стадии ЖЦ объекта.
Следовательно, структурная декомпозиция системы может давать разный результат в зависимости от определённого этапа и сложившихся обстоятельств, в соответствии с перечисленным набором основных факторов.
Рассмотрим самый общий набор функций, который соответствует разным структурным компонентам системы.
Главный ССС обеспечивает координацию действий всех служб министерств и ведомств на подотчётной территории, органов государственной власти и является опорным звеном для обеспечения управления со стороны национального центра управления в кризисных ситуациях (НЦУКС). Система обеспечения экстренного вызова оперативных служб является одним из основных организационно-технических механизмов, обеспечивающих комплексную работу всех ССС в регионе. Она базируется на центрах обработки вызовов (ЦОВ). В отдельных регионах принято решение иметь только один основной ЦОВ на всю обслуживаемую территорию, но иногда на уровне каждого
объектного/ведомственного (кислородный завод, аэропорт, НИП, стартовый комплекс, служба энергообеспечения, транспортный диспетчерский центр и т.д.) или муниципального органа (г. Циолковский), создают узел обработки вызовов. Всё зависит от объёмов финансирования и имеющихся технических возможностей, например, каналов передачи данных приемлемого качества. Таким образом, каждый ССС может выполнять следующие функции:
- приём и первичная классификация сообщений о событиях;
- определение ответственных ССС за эти события;
- передача информации на уровень ответственного ССС;
- контроль действий ДДС по завершении событий;
- подготовка отчётной информации для передачи на более высокий уровень.
Вследствие обозначенных выше причин можно выделить 3 наиболее характерных структурных организации, которые могут мигрировать одна в другую или сосуществовать совместно: централизованная схема, децентрализованная и смешанная. Рассмотрим каждую из них.
Централизованная схема управления.
За счёт выделяемого финансирования создаётся главный ССС, как правило, на базе специально строящегося или предусмотренного для этого здания. С точки зрения технической реализации обеспечивается необходимая телекоммуникационная платформа по обработке информации, поступающей с обслуживаемой территории, и строится соответствующая 1Т инфраструктура на базе общего центра обработки данных, к которому подключаются рабочие места операторов главного ЦОВ. При этом применяется унифицированное программное обеспечение, обеспечивающее специфику фиксации первичной информации для различных типов событий, а также управление ресурсами реагирования на основе применения технологий ГИС, современных цифровых систем связи и систем мобильного позиционирования. Таким образом, применяется так называемая полностью «централизованная» схема управления, которая осуществляет не только обработку экстренных вызовов в едином ЦУ (CCC), но и обеспечивает управление силами и средствами реагирования из этого центра.
Среди достоинств данного решения следует отметить:
• сокращение времени передачи информации специализированной бригаде для выезда к месту события;
• сокращение времени принятия решения по комплексному реагированию за счёт того, что диспетчеры всех служб находятся в одном месте и работают в единой системе на основе общего сервера;
• обеспечение единой схемы управления по комплексным событиям в результате использования унифицированных систем управления и связи, работающих на основе общих технических и информационных ресурсов.
Недостатками централизованного подхода являются:
• высокие начальные затраты по созданию системы (строительство и оборудование нового ЦОВ , модернизация каналов связи и т.д.);
• необходимость ликвидации специализированных ЦОВ (на более нижних уровнях) и вывод диспетчеров и операторов в подчинение новой структуры управления, связанная с этим процессом штатная и структурная реорганизация;
• увеличение первоначальных затрат на подготовку и обучение персонала главного ЦОВ.
Децентрализованная схема.
В соответствие с имеющимся опытом развития подобных проектов в России можно отметить следующие особенности:
Заказчик, как правило, не предполагает ликвидацию ЦОВ более нижнего уровня, обеспечивающих приём вызовов и реагирование по направлениям, т.е. ДДС существующих экстренных служб (ЖКХ, энергоснабжения, МВД и т.д.) остаются функционировать в прежнем составе. Во многом это обуславливается, например,
тем, что службы 01 и 02 являются ведомственными формированиями МЧС и МВД, поэтому решения по слиянию диспетчерских функций этих структур наталкиваются пока на непреодолимые ведомственные противоречия. Главный ЦОВ оснащается средствами связи и 1Т инфраструктурой, обеспечивающей приём экстренных вызовов с обслуживаемой территории. Его функции ограничиваются фиксацией информации о событиях и передачей их в специализированную службу, которая осуществляет реагирование и передаёт информацию о статусе завершения события обратно главный ССС. Таким образом, вся существующая инфраструктура сохраняется почти в неизменном виде и появляется новая надстройка в виде дежурной службы главного ССС.
Перечислим достоинства данной «децентрализованной» схемы:
• не требуется относительно больших объёмов финансирование на организацию главного ССС;
• штатная структура и состав информационного обеспечения в специализированных ССС остаются в почти неизменном виде;
• специализированные ЦОВ и соответствующие ССС остаются в штатной структуре и в подчинении соответствующих руководителей;
• соответствующие информационные ресурсы (сервера БД и т.д.) и техническая инфраструктура остаются в подчинении руководителей специализированных ССС;
• низкие требования к каналам передачи данных между ССС.
К недостаткам этой схемы относятся:
• временные задержки в схеме информационного взаимодействия между ССС различной ведомственной подчинённости для передачи информации и поддержке функций управления при реагировании на комплексное событие, что увеличивает время реакции на событие в целом;
• в целом затраты на обслуживание, эксплуатацию и обучение в рамках всех подсистем локальных ССС выше, чем при централизованной схеме, т.к. в каждом узле реализуются дублирующие функции по эксплуатации и обслуживанию технической инфраструктуры;
• повышенные затраты на развитие и модернизацию, т.к. при изменении в программном и аппаратном обеспечении требуется поддержка интерфейсов с системами других ССС.
Смешанная схема.
При реализации проекта в реальных условиях следует учитывать разнообразие дежурных служб, частей и подразделений, участвующих при отработке решений, а также неоднозначность взаимоотношений между ведомствами и не только. Поэтому необходимо предусмотреть разные возможности взаимодействия различных центров принятия решения (ССС), в зависимости от их уровня подчинённости, оснащения, технических условий, объёмов финансирования и некоторых других факторов. Очевидно, что перечисленные особенности дают право на жизнь как централизованной, так и децентрализованной схеме. Например, для того, чтобы выполнить требование некоторых ведомственных ССС оставаться хозяевами своей инфраструктуры по обработке событий и управлению ресурсами
для них следует рассматривать решение по децентрализованной работе. И наоборот, если мы имеем дежурную службу, которая не имеет требований по секретности и не имеет возможностей нести эксплуатационные и иные расходы по обслуживанью информационной и технической инфраструктуры ЦОВ, то вполне вероятно подключить сервисы регистрации событий для неё на общий сервер. Таким образом, при реализации проекта будут использоваться, скорее всего, оба вышеописанных подхода, что можно условно обозначить как «смешанную» схему реализации.
Достоинства и недостатки «смешанной схемы»
Достоинства:
• Возможность гибко подходить к построению структуры системы с учётом требований Заказчика в части реализации специфических задач.
• Возможность максимально приближаться к удовлетворению требований ключевых показателей эффективности при имеющихся ограничениях ресурсных, финансовых и политических возможностей.
• Возможность закладывать на перспективу реализацию наиболее оптимальной структуры при возникновении дополнительного финансирования и политической воли.
• Возможность показать на практике преимущества и недостатки того или иного подхода.
Недостатки:
• Наличие ограничений и сдерживающих факторов при возникновении дополнительных требований для удовлетворения ключевых показателей эффективности в случае развития ситуации.
• Сохранение неопределенности в структурных подходах может приводить к снижению качества выполняемых задач.
• Наличие дублируемых функций на различных уровнях и в узлах системы.
• Необходимость поддержания дополнительных интерфейсов к решениям от различных производителей.
Стоит отметить, что рассматриваемая система представляет собой совокупность подсистем, объединённых иерархическими и горизонтальными информационными связями и связями по управлению, и обладает всеми признаками больших систем.
Представленный анализ требует от разработчиков такой системы моделирования, которая позволяла бы гибко реагировать на меняющуюся ситуацию в зависимости от стадии ЖЦ, давала возможность моделировать процессы адекватно структурным изменениям без тотального перепрограммирования.
Рассматриваемая в статье автоматизированная система управления - большая система, относящаяся к классу пожизненных систем. Имеется в виду, что пожизненная система востребована всегда, но время эксплуатации конкретного варианта ограничено. По прошествии определенного времени требования к системе, её функциональным возможностям подлежат пересмотру и корректировке.
Иногда предпринимаются попытки построения подобных АСУ собственными силами, что называется с нуля, однако, практика создания больших систем показывает, что наиболее рациональным является создание АС на основе стандартного решения. Опыт работы с большими системами пока (тем более в регионах) незначителен. Условия и специфика развертывания АСУ в каждом случае свои. Это обстоятельство требует формализации инструментов, которые будут использоваться при создании системы на основе стандартного решения. Важно, чтобы Заказчик понимал потребность и специфику использования соответствующих инструментов.
4. Модель жизненного цикла системы
Как было показано Дёмингом: "Поскольку основные процессы (бизнес-процессы) организации - это организованная деятельность часто больших междисциплинарных коллективов, их можно и нужно рассматривать с позиций кибернетического подхода, используя понятия стратегического и оперативного управления. Исходя из этого, можно заключить, что: Стратегическое управление -это аспект управления, связанный с определением траектории состояний системы. Так как в цикле PDCA осуществляется целеполагание, будем связывать его со стратегическим управлением. Оперативное управление - это аспект управления, связанный с удержанием системы на определенной траектории (определенной на уровне стратегического управления) и будем связывать его с циклом SDCA ".
Однако, необходимо отметить, что «Первично построение траектории состояний системы - целеполагание и, соответственно, цикл PDCA. Удержание же
системы на определенной траектории может быть реализовано посредством цикла SDCA. Значит, цикл PDCA должен быть разорван».
В рассматриваемом случае стратегические задачи лежат в области разработки решений и нормативной базы, обеспечивающей платформу для проектирования и внедрения системы, поддержки её эксплуатации и подготовки необходимых материалов для развития. Таким образом, на стратегическом уровне создаётся и поддерживается базис, обеспечивающий основу для фаз ЖЦ Системы. Из этого следует, что модель управления жизненным циклом (ключевое слово цикл) включает в себя элементы замкнутых обратных связей и обеспечивает непрерывность во времени рассматриваемых процедур.
АСУ космодрома, как уже было отмечено, эта система, которая существует и совершенствуется непрерывно во времени, поэтому стадии её ЖЦ включают элементы замкнутых обратных подциклов. Здесь автор выделяет 2 уровня подциклов, первый из которых, внешний, соответствует непрерывному совершенствованию всей системы в целом(PDCA), а второй, внутренний, решает задачи на уровне разработки конкретных технических решений ЖЦ(SDCA).
С точки зрения системного анализа проводится функциональная декомпозиция ЖЦ АС в терминах стандарта IDEF0. IDEF0 как стандарт был разработан в 1981 году департаментом Военно-воздушных сил США в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Набор стандартов IDEF унаследовал своё название от этой программы (IDEF расшифровывается как ICAM Definition). В процессе практической реализации, участники программы
ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в больших АСУ.
В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. Не секрет, что практически все проекты моделирования и анализа деятельности больших систем сейчас в России, так или иначе, связаны с построением автоматизированных систем управления. Благодаря этому, стандарты IDEF0 в понимании большинства стали условно неотделимы от внедрения больших АСУ. Кроме того IDEF0 стал в России стандартом де-юре с появлением ГОСТ 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».
Как было показано, задачи стратегического уровня предполагают создание и базовых условий и развитие принципов, необходимых для поддержки фаз внутреннего ЖЦ (Рисунок 2).
Рисунок 2.Управлять на стратегическом уровне
Следующий этап декомпозиции модели ЖЦ приводит к уровню А0(Рисунок
3). На нём представлена модель жизненного цикла системы SDCA (функция «Управлять стадией ЖЦ» модели IDEF0 уровня A0) с точки зрения существующих базовых государственных стандартов, которые являются не только формализованным юридическим подходом к проектированию БС, но и служат воплощением принципов системного подхода и системного анализа, без которых невозможна разработка подобных проектов.
Рисунок 3. Управлять стадией жизненного цикла системы
Сложившиеся в России подходы к построению АСУ большими системами
основаны преимущественно на функциональном походе и механистической модели управления. При построении же больших систем настало время использовать идеи стандарта ГОСТ Р ИСО-МЭК 15288-2005. Этот стандарт является русифицированной версией международного стандарта ISO IEC 15288 и "... распространяется на системы, которые созданы человеком и состоят из одного или нескольких следующих элементов: технические средства, программные средства, люди, процессы, процедуры ...". Центральная идея стандарта -междисциплинарный подход к проблеме успешного создания систем и средство для её решения. В качестве ключевых аспектов системной инженерии в стандарте
определены: системный подход, жизненный цикл системы, инжиниринг требований, архитектурное проектирование, процессный и проектный подходы. В ГОСТ 15288 детали модели ЖЦ выражаются как процессы, из процессов можно построить приемлемую для вас конфигурацию. Если понимать сложную систему как совокупность упорядоченных структур и процессов, то это вполне соответствует действительности. При этом ЖЦ системы включает в себя следующие стадии:
1. Замысел
2. Разработка
3. Производство
4. Применение
5. Поддержка применения
6. Прекращение применения и списание
Помимо этого необходимо творчески переосмыслить комплекс стандартов на автоматизированные системы ГОСТ 34. Для государственных организаций ГОСТ 34, являются основой культуры проектирования, и они выдвигают использование стандартов этой группы в качестве необходимого условия участия в тендерах на поставку (разработку) системы. К несомненным достоинствам стандартов серии ГОСТ 34 можно отнести то, что они разработаны профессионалами, опиравшимися при их создании на опыт успешно выполненных проектов. Стандарты серии ГОСТ 34 максимально полно описывают такую сложную абстрактную сущность, которой является любая автоматизированная система, через комплекс документов :
• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
• РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».
Основной минус этой группы стандартов - они создавались в конце 80-х годов и поэтому их положения частично устарели. Например, при рассмотрении архитектуры автоматизированной системы рассматривается только двухуровневая модель. Кроме того, как уже было заявлено, рассматриваемая система является пожизненной и существует вне зависимости от уровня используемых средств автоматизации и процессов, поэтому необходимо дополнить линейную парадигму ГОСТ 34 циклическим механизмом ГОСТ ИСО/МЭК 15288, который позволяет осуществлять возврат на различные стадии проектирования при совершенствовании тех или иных компонент сложной системы. В ГОСТ 15288 детали модели ЖЦ выражаются как процессы, из процессов можно построить приемлемую на данный момент конфигурацию. Если понимать сложную систему как совокупность упорядоченных структур и процессов, то это вполне соответствует принципам системного анализа в целом. ГОСТ 15288: «Модель жизненного цикла включает одну или несколько моделей стадий в зависимости от необходимости. Модель собирается в виде последовательности стадий, которые могут перекрываться или повторяться в зависимости от сферы применения рассматриваемой системы, от ее размеров, сложности, изменяющихся потребностей и возможностей». Таким образом, это означает, что для создания наиболее оптимальной модели ЖЦ системы
допускается модифицировать модель ЖЦ для её адаптации к имеющимся условиям и обстоятельствам. Поэтому, основываясь на идеях стандартов ГОСТ Р ИСО/МЭК 15288:2005 и ГОСТ 34.601-90 , предлагается следующая модель жизненного цикла большой автоматизированной системы управления в контексте БЭСА:
Таблица 1
ГОСТ 34(ГОСТ 34.601-90) ГОСТ 34, дополненный ИСО/МЭК 15288
1. Формирование требований к 1. Стадия замысла системы управления (Концепция)
АС
2. Разработка концепции АС. 2. Стадия выбора поставщика решения на
автоматизированную систему.
3. Техническое задание. 3. Стадия разработки технического задания на
автоматизированную систему.
4. Эскизный проект.
4. Стадия технорабочего проекта.
5. Технорабочий проект
6. Ввод в действие. 5. Стадия ввода в действие автоматизированной системы.
6. Стадия проведения опытной эксплуатации автоматизированной системы
7. Сопровождение АС 8. Стадия сопровождения (поддержка применения) автоматизированной системы
9. Стадия прекращения использования (применения) и списания автоматизированной системы
5. Применение имитационного моделирования для оптимизации ключевых показателей эффективности системы в контексте проектирования цикла 8БСЛ
Для подобных систем ключевым показателем эффективности (КПЭ) является время прибытие ресурсов реагирования к месту события. Как уже было показано в настоящее время в реальных проектах не приводят каких-либо научно обоснованных инструментариев для обоснования этих КПЭ. Поэтому в этой главе предлагается механизм на базе имитационной модели.
Интервалы поступления заявок в центры обработки вызовов, а также время их обработки ресурсами реагирования являются случайными процессами. В работе на данных реального ЦОВ за несколько лет осуществляется выявление законов распределения плотностей вероятности этих величин.
Главный показатель эффективности учитывается в ИМ, в свою очередь на законы распределения рассмотренных величин влияет все рассмотренные факторы и факторы внешней среды. Следует отметить также, что вышеперечисленные факторы, могут учитываться как в структурной декомпозиции системы на разных этапах ЖЦ.
На уровне структуры стадии ЖЦ необходимо решить нетривиальную задачу построения иерархии центров управления и принятия решений, которая зависит от многих факторов. Задачи проектирования данной структуры до настоящего времени содержат во многом элементы неопределённости. Требования о количестве реагирования для конкретного ССС в проектной документации не имеют под собой чёткого количественного и научного обоснования и разрабатываются в лучшем случае на основе сравнительных оценок из истории функционирования уже имеющихся служб. Однако это не является достаточным основанием для определения параметров проектируемой системы. Недооценка вышеперечисленных требований может привести не к снижению времени реагирования, а наоборот к его увеличению, что может поставить под сомнение многомиллионные затраты, которые расходуются государством на построение подобных систем. С другой стороны неправильно просчитанная спецификация может привести к
неоптимальному использованию имеющихся финансовых, материальных и кадровых ресурсов.
5.1. Постановка задачи имитационного моделирования
В рамках рассматриваемого основного операционного процесса, ограниченных объёмов статистически достоверных данных и неопределённой структуры, представляющей из себя иерархию центров принятия решений, объединённых информационными связями и связями по управлению, предложить научно обоснованный механизм оценки требований по ресурсному обеспечению Command Control Center's(CCC), гарантирующий выполнение ключевых показателей качества функционирования системы.
5.2. Построение базовой имитационной модели CCC/ДДС
Как уже было отмечено, в контексте структурно-функциональной декомпозиции базовым элементом системы определяется CCC, для моделирования основного операционного процесса которого используется дискретно-событийная имитационная модель на основе библиотеки стандартных классов системы моделирования AnyLogic, которая позволяет работать в объектно-ориентированной парадигме. Для моделирования основного процесса используется дискретно-событийная имитационная модель на основе библиотеки стандартных классов системы моделирования AnyLogic, которые реализуют базовые блоки на уровне механизмов, описанных в теории массового обслуживания:
- источники событий,
- очереди,
- серверы обработки и т.д.
Манипулируя параметрами объектов, построенных на основе реализации этих классов, а также анализируя статистические зависимости можно подобрать оптимальный набор характеристик для составления предложений по спецификации конкретной системы.
Проектируемая система, как уже было отмечено, представляет собой иерархическую структуру различных центров управления, взаимодействующих между собой для обеспечения координации управления силами и средствами реагирования.
5.2.1. Методика оценки вероятностных характеристик модели
В качестве основных вероятностных характеристик базовой имитационной модели рассматриваемого функционального узла (ССС) выделяем: интенсивность входного потока заявок - длины интервалов между обращениями пользователей в ЦОВ автоматизированной системы диспетчерского управления (АДС) одного из ССС; временные характеристики обработки заявок - действия служб. Для каждого из указанных параметров была применена методика, предусматривающая следующие шаги: предварительный выбор семейства теоретического распределения; оценка параметров (положения, масштаба и формы) этих распределений; проверка гипотезы о правильности сделанного выбора; верификация полученных результатов с помощью сравнения расчетных и реальных данных, используя статистику по одному из узлов.
5.2.2. Эксперимент по оценке интенсивности входного потока заявок
Первый результат, полученный в ходе оценки интенсивности входного потока заявок, - необходимость выделения из исходного временного ряда достоверной компоненты. На графике (Рисунок 4) представлены длины интервалов между поступлением заявок одного из локальных ССС за год.
INTERVAL INTERVAL
180 160 - 1-
140 -120 - 1
100 -80 - - —j-1— 1
60 -40 -20 -0 - гЬттЫ; ьтЬг il 1 , ГШ 111 л! L, 1 1 1. ill У frrrh
ll'MIWPlin1 IIIITP4 1 11 1 1 Г...... ' ' 1 ■ l'RVII IHVWniVlfirn ПВПТТГИШПШЯШЩЩ ГЦ " II 1 ' г ч I1 l"i 1 IW р-11 ^ грщ ч-р 1 Г^Ч'Г1'!''«' W-ff-P-p Г1 11 1 и '
!■ INTERVAL INTERVAL!
1 551 1101 1651 2201 2751 3301 3851 4401 4951 5501 6051 6601 7151 7701 8251 8801 9351 9901 10451
Рисунок 4. На оси Y представлены длительности интервалов.
Принимаем за первоначальную гипотезу о вероятностном распределении длин
интервалов между поступлением заявок в ЦОВ, в соответствии с теоретическими рекомендациями, предположение об экспоненциальном характере этого распределения.
Для проверки указанных гипотез на основании полученных за определённый год данных в пакете STATISTICA строились и анализировались с помощью критерия Колмогорова-Смирнова гистограммы плотности распределения интервалов между поступлением заявок (Рисунок 5).
Рисунок 5.
Таким образом, получаем среднее значение интервалов между поступлением заявок равное 7,8 мин., дисперсию интервалов поступления 10,12, значение критерия Колмогорова-Смирнова 0,05335. Гипотеза об экспоненциальном распределении подтверждается.
5.2.3. Эксперимент по оценке временных характеристик обработки заявок
Гамма-распределение является наиболее «подозрительным» законом с точки зрения наилучшей применимости для оценки параметров вероятностной переменной типа «длительность интервалов обслуживания».
Масштабный параметр Ь и параметр формы а этого распределения связаны между собой системой уравнений:
аЬ = т, где т - среднее значение;
аЬ2 = б2, где s - дисперсия;
Решение этой системы уравнений позволяет определить максимально правдоподобные значения параметров гамма-распределения. Для проверки гипотезы о применимости гамма-распределения для оценки времени обработки заявок в исполнительных подразделениях ССС были использованы соответствующие данные за год и применен критерий согласия Колмогорова-Смирнова .
Рисунок 6.
При проверке данных параметров на имитационной модели ССС получаем отклонение от реального количества заявок за такой же период в следующем году не более 12%. На Рисунок 7 хорошо видно, что модельные графики плотности вероятности обслуживания заявки и интервалов поступления заявок практически полностью совпадают со статистическими.
Рисунок 7. Эксперимент по проверке гипотезы об адекватности имитационной модели
5.3. Построение типовой универсальной модели экстренной оперативной службы на основе анализа данных входного потока
В системе массового обслуживания, моделирующей каждый из центров обработки вызовов, следует предусмотреть: классификацию заявок по степени сложности обслуживания (реагирует одна служба, реагирует несколько служб и каких); возможность обмена информацией о заявках между ЦОВ ССС как по вертикали, так и по горизонтали (Рисунок 1).
5.3.1. Разбиение исходного входного потока заявок на подпотоки
Для того чтобы иметь возможность сделать выводы о том как работают ССС1, ССС3, для которых у нас статистики нет, на основе потока ССС 2 и мощность межузловых связей, необходимо разделить имеющийся входной поток 2 по определённым типам заявок:1 - требуется реагирование только сил и средств ССС1 , 2 - ССС2, 3 - ССС3, 13 - ССС1 и ССС3 соответственно и т.д. На основе этого делается вывод о потоках 1, 3 и строится типовая ИМ ССС. Таким образом, по «следам» совместной деятельности можно оценить параметры работы «отсутствующей статистики».
На графиках (Рисунок 8) показано, как осуществляется идентификация законов распределения для каждого из «подпотоков».
Рисунок 8. Идентификация законов распределения «подпотоков» по типам заявок.
Способом указанным выше осуществляется также идентификация законов распределения для интервала обслуживания для каждого из выделенных типов подпотоков.
5.3.2. Разработка имитационной модели
Типовая модель ССС (базовый класс) с расщеплённым входным потоком и с выходом, порождающим заявки к узлам ССС1, ССС2, ССС3 позволяет проверить гипотезу о том, что модель центра обработки вызовов с расщеплением входного
потока заявок по классам будет адекватной в смысле формирования итогового потока модели без расщепления.
Эксперимент подтверждает, что расщепление потока заявок на классы с соответствующими параметрами распределения не приводит к изменению параметров распределения исходного (совокупного) потока. Таким образом, создается базовый универсальный шаблон/класс для моделирования типового ССС -класс ComplexSource системы AnyLogic (Рисунок 9).
Рисунок 9.
На Рисунок 10 представлены результаты эксперимента по моделированию функционирования ДДС с входным потоком, генерируемым несколькими источниками. В данном случае сложный объект, описывающий ЦОВ с несколькими источниками представляется на уровне презентации обобщённо в виде значка «ДДС». Программно класс этого объекта формируется наследованием от класса ComplexSource, представленного средствами графического моделирования на Рисунок 9. При этом каждый из источников формирует подпоток определённого типа с интенсивностью экспоненциального закона распределения, которые были
выделены и идентифицированы выше. Также необходимо отметить, что
совокупность заявок всех представленных типов в точности составляет исходный статистический поток.
В правой верхней части Рисунок 10 имеется гистограмма распределения плотности вероятности интервалов поступления сообщений на входе в общую очередь. Если сравнить её с графиком, представленным на Рисунок 7 (правый нижний угол), то отчётливо видно, что это практически аналогичные распределения с одинаковыми параметрами.
Рисунок 10. Эксперемент - подтверждение гипотезы адекватности универсальной комплексной модели ССС
5.3.3. Разработка модели региональной системы SmartCity на основе базовой
универсальной модели локального ССС
Рисунок 11. Графический уровень представления регионального сегмента управления SmartCity
В качестве узловых объектов используются сущности, описания которых наследуются от базового класса модели ССС (Рисунок 9).
Тип: Сотр1ех5оигсе Пакет:
incl call centr
interarrivalTime_01
interarrivalTime_02D
interarrivalTime_03D
interarrivalTime_0103D
interarrivalTime_0102I>
interarriwalTime_0203I>
interarrivalTime_010203D
delayTlme0
ForvardCall0
exponential(1/5.0) exponential(1/2 0.6)
□
exponential(1/1555.3) exponential(1/5834.9) gamma( 2.52, 73.1 ) SelectCallCenteE03(callln)
Рисунок 12. Параметры объекта ССС3
Тип: Сотр1ех5оигсе
Пакет: ¡ncl_call_centr zJ
¡nterarnval I ime_0i' interarrivalTime_02D interarr i valT irne_03D ¡nterarrivalTime 0103d irtterarnvalTime_0102D in terarr i va 1T i me_0203D interarr i valT ime_010203° delayTime" ForvardCall" 1
exponential(1/10.D)
1
■
exponential(1/1555.3)
exponential(1/2D.6)
exponential(1/5 33 4.9)
gamma ( 2.52, 73.1 )
SelectlnDelay(callIn)
Рисунок 13. Параметры объекта ССС2
На рисунках 12 и 13 видно, что входные потоки объекта, моделирующего поведение ССС3, отличаются от объекта такого же класса, моделирующего ССС2. Специфика ССС3 отражается тем, что преобладают потоки, связанные с поступлением событий, включающих тип 03, что отражается интенсивностью экспоненциального распределения. Потоки, которые никак не соответствуют специфике ССС3, игнорируются, т.к. их интенсивность незначительна. Подобные приёмы использованы и для описания специфики ССС2 в параметрах объекта (Рисунок 13). Здесь видно, что значимыми являются потоки, имеющие тип заявок, включающих реакцию подразделений ССС2. При этом наибольшей интенсивностью обладает поток «чистых» заявок 02.
Графический уровень ИМ Системы позволяет подбирать оптимальные ресурсные значения для каждого ССС, манипулируя значениями с помощью элементов управления так называемых «бегунков» (Рисунок 14).
Прогон: 1 О Выполняется Время: 113872.35! Прогон: Время остановки не задано Дата: 09.04.2018 16:58:58 | 1> Память: Щ | 445.2 сек
Рисунок 14. Эксперимент - оптимизация ресурсных значений ССС с помощью графического представления ИМ Системы.
Чтобы оценить научную и практическую значимость работы, надо вспомнить, что необходимость применения имитационного моделирования чаще всего зависит от следующих факторов: отсутствие или неприемлемость аналитических и численных методов решения поставленной задачи; наличие или отсутствие достаточного количества исходной информации о моделируемой системе; непредсказуемость других возможных методик в смысле получения адекватных результатов в приемлемые интервалы времени; оптимизация системы с помощью манипулирования параметрами модели. Привязка имитационной модели к моделированию процессов, определяющих фазы ЖЦ БС, позволяет выйти на ряд конкретных количественных и финансовых показателей, определяющих параметры
функционирования системы.
Выводы
В работе разработана и предложена научно-обоснованная методика построения большой автоматизированной системы космодрома уровня SmartCity.
Дан анализ существующих систем управления в объектно-региональной концепции космодрома уровня SmartCity и определены их проблемные зоны.
Предложена модель жизненного цикла большой системы на основе применения технологии функциональной декомпозиции IDEF0 и методов реинжиниринга, описанных в международном стандарте серии ИСО МЭК 15288 «Системная инженерия. Процессы жизненного цикла систем».
Рассмотрены методы оптимизации ресурсов при оснащении служб и ЦУ региональной АСУ на базе имитационного моделирования в условиях ограниченного объёма статистических данных.
Представленный материал может оказаться полезным для проектировщиков и разработчиков больших региональных автоматизированных систем в контексте SmartCity, к которым относится АСУ космодрома, а также АС регионального и муниципального уровня, АС крупных спортивных мероприятий международного и государственного масштаба, ситуационных центров региональных и муниципальных правительств, ведомственных автоматизированных систем, в том числе в такой специфической области, к которой относятся органы государственной власти и управления.
Библиографический справочник
1. W. Edwards Deming. Out of the Crisis, The MIT Press Cambridge, Massachusetts, London, England, 1882, 419 p.
2. Емельянов А.А., Малышев В.В., Смольянинов Ю.А., Старков А.В., Формализация задачи оперативного планирования целевого функционирования разнотипных космических аппаратов дистанционного зондирования Земли // Труды МАИ. 2017. № 96. URL: http ://trudymai.ru/published. php?ID=85921
3. Артемьев В.Ю., Воронцов В.Л. О стандартизации, эфнофективсти, целях и стимулах, касающихся развития отечественной телеметрии, относящейся к ракетно-космической и ракетной технике // Труды МАИ. 2011. № 44. URL: http://trudymai.ru/published.php?ID=24989
4. Панов Д.В., Малышев В.В., Пиявский С.А., Ковков Д.В. Сравнительный многокритериальный анализ сложных технических и социальных систем в экономико-управленческом аспекте // Модернизация. Инновации. Развитие. 2016. Т. 7. № 2. с. 74 - 83.
5. Малышев В.В. Методы оптимизации в задачах системного анализа и управления. - М.: Изд-во МАИ-ПРИНТ, 2010. - 440 с.
6. Blanchard Benjamin S. System Engineering Management, John Wiley & Sons, 2004, 498 p.
7. Benjamin S. Blanchard, Wolter J. Fabrycky. Systems Engineering and Analysis, Prentice Hall, 1998, 738 p.
8. Clemen R., Reilly T.
9. Making Hard Decisions with Decision Tools Suite, Duxbury USA, 2002, 678 р.
10. Keeney Ralph L. Value-Focused Thinking: A Path to Creative Decisionmaking, Harvard University Press, 1996, 432 p.
11. Whittleston S. Introduction to System Analysis and Design, Bolton, School of Business and Creative Technology University of Bolton, 2010, 567 p.
12. Kendall K. Kendall J. Systems analysis and design. Upper Saddle River. Prentice Hall, 2010, 610 p.
13. Dennis A., Wixom B. Systems analysis design, New York, J. Wiley, 2003, 675 р.
14. Millington D. Structured systems analysis and design using standard flowcharting symbols // The Computer Journal, 1981, no. 24(4), pp. 295 - 300.
15. ISO/IEC/IEEE 15288:2015. Systems and software engineering - System life cycle processes, International Organization for Standardization, 2005, 108 р.
16. Автоматизированные системы. Стадии создания. ГОСТ 34. 601-90. - М.: Стандартинформ, 1990, 9 с.
17. Автоматизированные системы. Техническое задание на создание автоматизированной системы. ГОСТ 34. 602-99. - М.: Стандартинформ, 1989, 21 с.
18. Разумов Д.А., Алёшин В.Д. Имитационное моделирование в жизненном цикле автоматизированных систем управления в кризисных и чрезвычайных ситуациях // Труды V-й всероссийской научно-практической конференции по имитационному моделированию и его применению в науке и промышленности, С-Петербург, Ноябрь 2011. С. 244 - 249.
19. Загребаев А.М., Крицына Н.А., Кулябичев Ю.П., Шумилов Ю.Ю. Методы математического программирования в задачах оптимизации сложных технических систем. - М.: МИФИ, 2007. - 332 с.
20. Лотов А.В., Поспелова И.И. Многокритериальные задачи принятия решений. -М: МАКС Пресс, 2008. - 197 с.
21. Пантелеев А.В., Летова Т.А. Методы оптимизации в примерах и задачах. - М.: Высшая школа, 2005. - 544 с.
