close

Вход

Забыли?

вход по аккаунту

?

GamovOkhtilev

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное
образовательное учреждение высшего образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
В. Ю. Гамов, М. Ю. Охтилев
РАЗРАБОТКА МЕТОДОЛОГИЧЕСКИХ ОСНОВ
МОДЕЛИРОВАНИЯ ОБЪЕКТОВ И ПРОЦЕССОВ
В КОСМИЧЕСКОЙ ОТРАСЛИ
Учебное пособие
УДК 004.94
ББК 39.67
Г18
Рецензенты:
доктор технических наук, профессор Б. В. Соколов;
кандидат технических наук, старший научный сотрудник В. Н. Коромысличенко
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
Г18 Гамов, В. Ю.
Разработка методологических основ моделирования объектов и процессов в космической отрасли: учеб. пособие /
В. Ю. Гамов, М. Ю. Охтилев. – СПб.: ГУАП, 2018. – 123 с.
ISBN 978-5-8088-1248-2
Рассматривается организация производства в ракетно-космической отрасли и технология создания моделей СОТОП. Излагаемый
материал основывается на использовании теории моделирования; теории оптимизации; теории систем; теории вероятности; пространства
состояний систем; элементов факторного анализа; алгоритмов обработки и управления; методов построения сложных систем.
Издание стало логическим продолжением пособия «Организация
производства в космической отрасли при изготовлении прикладных
автоматизированных систем мониторинга и управления».
Варианты алгоритмов и программ для моделей СОТОП разработаны на протяжении нескольких лет студентами кафедры № 43 под
руководством авторов учебного пособия.
Предназначено для студентов всех форм обучения технических
вузов по направлению подготовки 231000 «Программная инженерия», по дисциплинам «Документирование разработки программного обеспечения», «Компьютерное моделирование», «Цифровая обработка сигналов».
УДК 004.94
ББК 22.18
ISBN 978-5-8088-1248-2
© Гамов В. Ю., Охтилев М. Ю., 2018
© Санкт-Петербургский государственный
университет аэрокосмического
приборостроения, 2018
ПРЕДИСЛОВИЕ
Содержание учебного пособия «Разработка методологических
основ моделирования объектов и процессов в космической отрасли»
сформировалось на основе материалов лекций, результатов проведения практических занятий, которые на протяжении ряда лет проводились со студентами Санкт-Петербургского государственного
университета аэрокосмического приборостроения (ГУАП). А также
на основе практических занятий, проведенных со студентами ГУАП
кафедры № 43, по разработке моделей и комплексов программ автоматизированных систем для ракетно-космической отрасли (РКО).
Некоторые варианты моделей и программ представлены в приложении 1 к данному учебному пособию. Наилучшие модели и программы получили свидетельства, которые также представлены
в приложении 2 к данному учебному пособию.
В учебном пособии совместно рассмотрены методологические основы математического моделирования компьютерных технологий
проектирования, разработки, производства, испытаний, эксплуатации автоматизированных систем обработки данных.
Показаны основные направления совершенствования системы
информации в РКО, которые могут быть связаны с обновлением
основных фондов действующих предприятий, стимулированием
научно-технической сферы и повышением качества рабочей силы.
Для внедрения таких инноваций необходимо формирование эффективного научного и технического пространства (в общем виде – единого информационного пространства отрасли), что позволит более
активно развивать ее направления. Базой для внедрения инноваций может стать рассматриваемый в учебном пособии метод организации производства в РКО. Метод основывается на развертывании
виртуального информационного пространства через моделирование сложных организационно-технических объектов и процессов
(СОТОП) и через, взаимосвязанные с ним, программные комплексы
руководителей (ПКР) различных уровней.
3
Учебное пособие предназначено для студентов очной, заочной,
очно/заочной (вечерней) форм обучения технических вузов, обучающихся по направлению подготовки 231000 «Программная инженерия», по направлению/специальности «02.03.03 «Математическое обеспечение и администрирование информационных систем»
направленности «Администрирование информационных систем»
и «Аэрокосмические информационные системы», по направлению
«09.03.04 «Программная инженерия» направленность «Разработка
программно-информационных систем», по дисциплинам «Компьютерное моделирование», «Цифровая обработка сигналов», «Автоматизированные системы научных исследований», «Документирование разработки программного обеспечения».
4
1. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ
МОДЕЛИ СОТОП
1.1. Система информации
о техническом состоянии и надёжности
Современный этап развития РКО характеризуется возрастанием
сложности космических комплексов (КК) и процессов управления
ими, что приводит к ужесточению требований к оперативности получения, качеству и достоверности результатов обработки и анализа информации различной природы, используемых при оценке
технического состояния и надежности КК, повышением меры ответственности за принимаемые решения о достигнутых уровнях
надежности КК и переходе на следующий этап жизненного цикла
(ЖЦ) КК.
В различных руководящих документах определения жизненного
цикла изделия различаются, из чего можно констатировать, что нет
единого понимания, содержания и структуры жизненного цикла.
Обычно понятие жизненного цикла адаптируется к конкретным
объектам или системам.
Проводимая в настоящее время кардинальная реформа РКО,
реализация крупномасштабных космических проектов требуют
решения сложных организационных и научно-технических задач,
что невозможно без обладания эффективными инструментами автоматизации процессов управления всеми стадиями жизненного
цикла изделий. При этом одним из важнейших требований является строгая регламентация и структуризация технологий управления ЖЦ изделий на основе действующих нормативных документов,
комплексная автоматизация всех видов деятельности, создание
различных классов автоматизированных систем (АС) осуществляющих поддержку и управление ЖЦ на различных стадиях и этапах
ЖЦ изделий. Автоматизация предполагает применение комплекса
технических, программных, организационных методов и средств
для повышения эффективности интеграции, хранения, обработки
и использовании территориально распределённых информационных ресурсов организаций и предприятий РКО.
Увеличение количества контролируемых параметров и требование обеспечить управление космическими комплексами в реальном
масштабе времени (РМВ), в том числе при возникновении нештатных
ситуаций, обуславливают необходимость постоянного совершенствования процессов сбора, обработки, интерпретации и анализа
5
разнородной информации, а также – создания специальных, принципиально новых по идеологии построения и функциональным возможностям комплексов автоматизированной интеллектуальной обработки данных. При этом особо актуальными становятся вопросы
совместного эффективного использования накопленных информационных ресурсов предприятий и организаций РКО – оперативных
и архивных фондов электронных документов, информационных потоков автоматизированных систем различного назначения. Только
комплексный подход, предусматривающий консолидацию общего
поля знаний и широкое организационное и информационное взаимодействие, позволит успешно решать задачи управления, оценки
технического состояния и повышения надёжности космических
комплексов на всех стадиях ЖЦ.
В соответствии с требованиями государственных нормативных
документов, на предприятиях и в организациях космической отрасли функционирует система информации о техническом состоянии
и надежности КК и входящих в их состав изделий.
Действующая система информации о техническом состоянии
и надежности КК и входящих в их состав изделий предназначена для
своевременного обеспечения федеральных органов исполнительной
власти, заинтересованных предприятий и организаций, участвующих в создании, производстве и эксплуатации КК, достоверными
сведениями, необходимыми для выполнения работ по обеспечению и повышению уровня технического состояния, качества и надежности комплексов и входящих в их состав изделий, совершенствованию систем менеджмента качества предприятий и организаций [1].
1.1.1. Анализ соответствия существующей системы информации
техническом состоянии и надежности
требованиям государственных нормативных документов
В настоящее время перед организациями и предприятиями, разрабатывающими и эксплуатирующими КК, все чаще встает проблема обеспечения эффективного управления системой информации
о техническом состоянии и надежности КК.
Это связано с основными недостатками существующей системы
информации о техническом состоянии и надежности КК:
− большие объемы разнородной информации о техническом состоянии и надежности КК не интегрированы и не систематизированы, соответственно, не созданы единые базы данных обо всем
6
жизненном цикле КК и не сформировано единое информационное
пространства РКО;
− наличие многочисленных, несовместимых между собой, выполненных на различных платформах, информационных систем;
− слабый уровень автоматизации аналитической обработки информации о техническом состоянии и надежности КК;
− ограничение оперативного доступа к информации о техническом состоянии и надежности КК, что приводит к снижению возможностей всех участников системы, а особенно Заказчиков КК,
объективно оценивать техническое состояние и достигнутый уровень надежности КК.
Кроме того, существующие на настоящий момент предложения
по переводу системы информации на безбумажную технологию
обмена документами между всеми участниками этой системы не
устраняют данные недостатки, так как основную аналитическую
работу все равно приходится выполнять вручную (или с малой степенью автоматизации конкретных прикладных аналитических задач на предприятиях и организациях отрасли).
Естественно, создание единой защищенной сети передачи данных между всеми участниками системы информации является
одной из приоритетных целей, которая поможет решить задачу повышения оперативности получения различных электронных документов в различных форматах. Однако это слабо влияет на качество
основной аналитической работы по оценке технического состояния
и надежности КК, так как опять потребуется ручная обработка имеющейся в документах информации или ручной ввод этой информации в локальные базы данных предприятий и организаций для
дальнейшей обработки.
Таким образом, только устранение указанных недостатков сможет поднять на новый уровень функционирование системы информации о техническом состоянии и надежности КК с целью обеспечения заданного качества КК, снижения себестоимости, сокращения
издержек при производстве и эксплуатации изделий.
Для определения возможных путей совершенствования системы информации о техническом состоянии и надежности КК необходимо рассмотреть требования государственных нормативных
документов по системе информации и степень их выполнения в существующей системе информации о техническом состоянии и надежности КК.
Система информации является единой для всех предприятий
и организаций, участвующих в создании, производстве и эксплу7
атации КК и входящих в их состав изделий, независимо от форм
собственности.
Эти требования к системе информации распространяются на все
разрабатываемые, изготовляемые и эксплуатируемые КК и входящие в их состав изделия.
Работы по системе информации проводят на всех жизненных циклах изделий (при эскизном проектировании, разработке рабочей
документации, наземной отработке, летных испытаниях, опытном
и серийном (единичном) производстве и эксплуатации КК и входящих в их состав изделий).
При этом информационные потоки в системе информации должны быть постоянными и замкнутыми, обеспечивать максимальную
оперативность проведения необходимых работ по обеспечению и повышению уровня качества и надежности КК и входящих в их состав
изделий.
Сбору, обработке и использованию по назначению подлежит информация о техническом состоянии и надежности изделий, полученная в процессе разработки, изготовления, наземной отработки,
летных испытаний и эксплуатации КК, в том числе, информация
об отказах и неисправностях изделий КК, выявленных при выполнении работ [2].
В нормативных документах были разработаны следующие рекомендации по организации сбора, обработки, анализа информации
о техническом состоянии и надежности космических комплексов
на предприятиях и в организациях, участвующих в системе информации.
На предприятиях и в организациях, участвующих в системе
информации, руководители назначают (создают) подразделения
(службы) информации о техническом состоянии и надежности КК,
осуществляющие:
− организацию и координацию работ всех подразделений по системе информации в соответствии с требованиями настоящего стандарта;
− сбор информационных материалов о техническом состоянии
и надежности КК и входящих в их состав изделий;
− проведение централизованного учета, анализа, обобщения,
представления и хранения информационных документов, содержащих данные о неисправностях и отказах изделий;
− контроль своевременности и полноты обработки и реализации
мероприятий другими подразделениями по исследованию и устранению причин неисправностей и отказов;
8
− оценку технического состояния и эффективности мероприятий
по устранению неисправностей и причин их возникновения;
− разработку и представление итоговых обобщенных информационных документов, оформляемых в соответствии с требованиями
настоящего стандарта, а также докладов, представляемых руководству предприятия (организации), о состоянии работ по устранению
неисправностей и причин их возникновения;
− участие в разработке нормативных документов по системе информации;
− подготовку поступающей информации для обработки на ЭВМ;
− постановку и отработку на ЭВМ задач, предусматривающих
систематизацию и анализ информации о техническом состоянии
и надежности изделий;
− участие в разработке и внедрении единых автоматизированных информационных систем;
− служба информации в объединении состоит из подразделений
системы информации на предприятиях, входящих в состав объединения. При этом подразделение информации на головном предприятии объединения является головным по отношению к подразделению информации на остальных предприятиях объединения.
По решению руководителя объединения (предприятия) в службы
информации допускается включать другие структурные подразделения предприятий, исходя из задач, возложенных на предприятия
в системе информации;
− первичные носители информации составляют подразделения
предприятия (организации), проводящие работы, в процессе которых
является неисправность, с участием подразделения системы информации. Носители информации централизованно учитывают подразделения системы информации, а затем направляют в подразделение,
обрабатывающее данные на ЭВМ, и в тематическое подразделение,
ответственное за исследование и устранение причин неисправности.
Подразделение, обрабатывающее данные на ЭВМ, осуществляет:
− ввод информационных данных в машинную память:
− хранение информации о техническом состоянии изделий в машинной памяти;
− обработку информационных данных о техническом состоянии
и с выдачей необходимых сведений и статистических материалов
в отпечатанном виде;
− разработку математического обеспечения и отладку задач по
обработке информационных данных о техническом состоянии изделий;
9
− разработку и внедрение автоматизированных систем информации о техническом состоянии изделий.
Тематические подразделения, получив первичные носители информации о неисправностях изделий:
− участвуют в анализе причин возникновения неисправности
и в проведении необходимых исследований;
− участвуют в разработке мероприятий по исключению причин
возникновения неисправности и представляют предложения по этому вопросу для включения в план мероприятий в подразделение,
осуществляющее техническое руководство по теме (основному изделию);
− осуществляют техническое руководство работами по разработке и реализации мероприятий по исследованию и устранению неисправности и причин ее возникновения, выполняемых предприятиями-соисполнителями, и контроль за ними;
− разрабатывают информационные документы по результатам
исследований причин неисправности и реализации мероприятий
по их устранению и представляют эти документы в подразделение
информации для учета, обобщения и последующей рассылки в соответствии с требованиями стандарта.
Подразделения предприятия (организации), осуществляющие
техническое руководство работами по теме (основному изделию):
− разрабатывают план мероприятий по исследованию и устранению причин неисправностей на каждом этапе работ с конкретным
изделием;
− контролируют совместно с подразделением информации качество и сроки исполнения запланированных мероприятий.
Однако, даже при наличии требований к системе информации
в государственных нормативных документах, особенно в части создания и сопровождения автоматизированных систем информации
о техническом состоянии изделий, в существующей системе информации о техническом состоянии космических комплексов автоматизированные информационные системы (комплексы), в основном,
разрабатываются и используются на этапе сбора, обработки и передачи информации, а заключительный этап – непосредственно анализ результатов обработки информации о техническом состоянии
и надежности КК и степени выполнения целевых задач – практически выполняется вручную.
При этом возникают проблемы при проведении систематизации,
накоплении, доведении, хранении информации, при проведении
инженерного и статистического анализа данных, а также при обоб10
щении и распространении опыта разработки, изготовления, испытаний и эксплуатации КК и входящих в их состав изделий.
Для соответствия системы информации о техническом состоянии и надежности КК требованиям, заданным в нормативных документах, первичная информация должна подвергаться количественному и качественному анализу с использованием современных
информационных технологий.
При автоматизированной обработке информации должны выполняться следующие операции:
− классификация и кодирование данных;
− систематизацию данных по установленным классификационным признакам и формирование массивов данных для последующего анализа, передачи, хранения;
− кодирование документированных носителей (полное и выборочное);
− перевод данных с документированных на магнитные носители
и обратно;
− инженерный и статистический анализ данных;
− поиск данных в банках по запросам и выдачу данных по установленной форме.
Для обеспечения возможности обобщения и распространения
опыта разработки, изготовления и эксплуатации комплексов и входящих в их состав изделий обработка информации должна предусматривать систематизацию, накопление и хранение сведений о
техническом состоянии и надежности комплексов и входящих в их
состав изделий с использованием средств вычислительной техники.
Инженерный и статистический анализ данных о техническом
состоянии и надежности комплексов и входящих в их состав изделий должен проводиться с целью:
− выявления причин неисправностей конструкционного, производственного и эксплуатационного характера, снижающих надежность изделия, выработки рекомендаций по их устранению;
− оценки достаточности и эффективности мероприятий по повышению надежности;
− оценки уровня надежности наблюдаемых изделий;
− выявления тенденций изменения уровня надежности;
− выявление основных факторов, влияющих на надежность изделий;
− контроль полноты и достоверности собираемых и передаваемых данных о техническом состоянии и надежности комплексов
и входящих в их состав изделий [3].
11
Именно слабое применение новых современных информационных технологий в существующей системе информации не позволяет эффективно решать перечисленные выше задачи, особенно при
проведении систематизации, накоплении, доведении, хранении
информации, при проведении инженерного и статистического анализа данных, а также при обобщении и распространении опыта разработки, изготовления, испытаний и эксплуатации КК и входящих
в их состав изделий на всех этапах жизненного цикла.
В настоящее время в космической отрасли предпринимаются попытки внедрить технологии электронного сопровождения наукоемкой продукции на всех этапах жизненного цикла (ИПИ- или CALSтехнологии).
CALS (Continuous Asquisition and Life cycyle Support) переводится как «Непрерывные поставки и информационная поддержка
жизненного цикла продукции» На русском языке этому понятию
соответствует аббревиатура ИПИ – «Информационная поддержка
изделия».
ИПИ-технологии – это современный подход к разработке, производству, эксплуатации и обслуживанию изделий путем информационной поддержки их жизненного цикла на основе электронного
обмена данных. Концепция ИПИ определяет правила, регламенты,
стандарты по которым строится информационное взаимодействие
участников проектирования, производства, испытаний и других
этапов жизненного цикла.
При применении ИПИ значительно повышается эффективность
деятельности предприятий за счет ускорения процессов исследования, разработки, сокращения издержек при производстве и эксплуатации изделий, существенного повышения качества выпускаемой
продукции.
Так, от внедрения CALS-технологий в США получен следующий
эффект [9]:
− прямое сокращение затрат на проектирование – от 10 до 30%;
− сокращение времени разработки изделий – от 40 до 60%;
− сокращение времени вывода новых изделий на рынок – от 25
до 75%;
− сокращение доли брака – от 23 до 73%;
− сокращение затрат на подготовку технической документации
– до 40%.
Поэтому работы по внедрению ИПИ-технологий должны быть отнесены к разряду первоочередных, так как дальнейшее отставание
отечественных предприятий в сфере ИПИ-технологий, существу12
ющее ныне, в ближайшем будущем приведет к потере конкурентоспособности российской космической продукции как на внешнем,
так и на внутреннем рынках. К сожалению, РКО на сегодняшний
момент имеет ряд инфраструктурных проблем, препятствующих
повсеместному внедрению ИПИ-технологий, основными из которых являются:
− дефицит высококвалифицированных специалистов в области
информационных технологий;
− отсутствие отечественных технических, общесистемных и прикладных средств ИПИ-технологий, поэтому предприятия вынуждены ориентироваться на дорогостоящие импортные.
− плохо координируются работы по внедрению передовых информационных технологий;
− плохо выполняются требования ведомственных и международных стандартов по ИПИ-технологиям.
Кроме того, уже существующие на предприятиях автоматизированные информационные системы, относящиеся к различным
этапам жизненного цикла изделий, в большинстве случаев созданы
в разное время на различных программно-аппаратных платформах
и практически не интегрированы между собой, на различных предприятиях применяются самые разные электронные технологии
описания изделия на одном и том же этапе ЖЦ.
Это создает объективные трудности в информационном взаимодействии между предприятиями и организациями при совместной
разработке, производстве и эксплуатации изделий.
А создаваемые в настоящее время корпорации, объединяющие
десятки предприятий, не смогут обеспечить эффективное оперативное взаимодействие проектировщиков, поставщиков, изготовителей и потребителей продукции [9].
Поэтому, одной из основных проблем оперативного получения
и доведения до всех пользователей объективной и достоверной информации о техническом состоянии и надежности КК является отсутствие автоматизированных комплексов контроля технического
состояния и надежности систем и агрегатов КК с едиными, автоматизированными базами данных и знаний, использующих измерительную информацию в реальном времени проведения всех видов
испытаний и штатной эксплуатации (ШЭ), а также всю имеющуюся
на момент испытания структурированную информацию об объекте
мониторинга:
− конструктивные, схемные и технологические решения, выбранные в процессе проектирования и изготовления КК;
13
− результаты заводских, стендовых, летных испытаний и штатной эксплуатации КК;
− результаты моделирования функционирования КК в различных режимах;
− результаты исследований и экспертиз, проведенных для определения причин отказов и неисправностей, возникших на предыдущих этапах испытаний (наземной отработки, летных испытаний,
серийного (единичного) производства и эксплуатации);
− мероприятия по устранению и предупреждению причин отказов и неисправностей с оценкой их эффективности, проведенные доработки;
− полученная в процессе эксплуатации оценка стабильности тактико-технических и эксплуатационных характеристик КК;
− конструкторская, эксплуатационно-техническая и методическая документация.
Именно отсутствие автоматизированных комплексов контроля/
мониторинга технического состояния и надежности систем и агрегатов КК с едиными для всех потребителей базами данных и знаний с возможностью аналитической обработки информации обо
всех этапах ЖЦ КК от проектирования до вывода из эксплуатации,
содержащими всю вышеперечисленную информацию, а также отсутствие единой защищенной среды передачи данных между всеми
участниками системы информации приводит:
− к низкой оперативности получения информации о качестве
функционирования и надежности КК, особенно при возникновении
нештатных (аварийных) ситуаций, что может способствовать принятию ошибочных или несвоевременных решений по проведению
испытаний или по дальнейшей эксплуатации КК;
− к низкому уровню достоверности и объективности оценки технического состояния и надежности КК и входящих в их состав изделий из-за ограниченного доступа ко всей имеющейся у предприятий
разработчиков, изготовителей КК, а также организаций, эксплуатирующих КК, информации о причинах имеющихся замечаний,
отказов и аварий КК, эффективности проведенных доработок, направленных на устранения этих причин, а также из-за отсутствия
возможности проводить качественную аналитическую обработку
больших объемов информации;
− к снижению возможностей Заказчиков КК оперативно и эффективно воздействовать на предприятия разработчиков и изготовителей КК, а также эксплуатирующие организации по вопросам обеспечения безопасной эксплуатации и повышения надежности КК [7].
14
Следствием этого являются повторяющиеся замечания и отказы систем и агрегатов КК, аварии КК по одной и той же причине
(«двойные аварии КК»), переносы сроков выполнения КК задач по
предназначению, большие экономические и политические потери.
С подобными проблемами сталкиваются и зарубежные специалисты при создании, производстве, испытании и эксплуатации
КК. Так, например, 30.04.1999 г. РН «Titan 4В» вывела КА связи
«Milstar 2» МО США на нерасчетную орбиту, параметры которой
не позволили использовать его по назначению. Ущерб составил
1.2 млрд $. Причина – в систему управления РН было заложено дефектное программное обеспечение (ПО).
В ходе расследования комиссия установила, что во время предполетной подготовки и проверки бортового ПО не была выявлена и исправлена ошибочная константа, введенная программистом в ПО
для работы инерциальной измерительной системы. Во время предстартовой подготовки и при проведении предстартового отсчета эта
константа отображалась на средствах визуального отображения,
как это положено, но никто не придал значения тому, что она в десять раз меньше. Никто из персонала, участвующего в предстартовой подготовке, не смог оценить последствий, к которым может привести ввод неверного значения этой константы.
Комиссия назвала несколько факторов, приведших к потере КА:
− процесс разработки ПО четко не определен и не документирован;
− недостаточно полное понимание работы ПО и подготовки блока
инерциальной навигации, что привело к появлению плохо проработанной процедуры расчета и тестирования констант для программы;
− «неадекватная и непрямая связь» между различными участниками предстартовой подготовки не позволила исправить ошибку;
− процесс гарантийной проверки проходит без понимания сути проверяемого процесса в целом или на уровне отдельной программы [4].
1.1.2. Методологические основы моделирования
при совершенствовании системы информации
Существенное повышение эффективности и качества системы
информации о техническом состоянии и надежности изделий возможно только при создании единых баз данных и знаний обо всех
этапах их жизненного цикла в составе распределенной вычислительной сети космической отрасли с использованием существующих и разрабатываемых в настоящее время автоматизированных
комплексов контроля/мониторинга технического состояния КК.
15
Поэтому предлагается технология построения системы информации о техническом состоянии КК на основе единых баз данных
и знаний в составе распределенной вычислительной сети предприятий и организаций, участвующих в системе информации о техническом состоянии и надежности КК с использованием аппаратнопрограммных комплексов контроля/мониторинга технического состояния и надежности систем и агрегатов КК в реальном масштабе
времени, разрабатываемых на основе интеллектуальных информационных технологий (ИИТ). Так, уже сейчас предлагается использовать информацию, получаемую от разработанных или разрабатываемых в настоящий момент автоматизированных комплексов.
Для каждого конкретного космического комплекса с этой целью
предлагается создать модель СОТОП, обеспечивающую совершенствование системы информации о техническом состоянии КК и входящих в его состав изделий на всех этапах их жизненного цикла.
1.2. Назначение модели СОТОП
Модель СОТОП должна представлять собой автоматизированную информационную систему, учитывающую особенности проектирования, создания, испытаний и эксплуатации, а также сбор,
обработку, хранение и представление обобщенной информации о техническом состоянии и надежности КК и входящих в него составных
частей на всех этапах их жизненного цикла.
Функционально модель СОТОП должна включать:
− компоненты управления информационными ресурсами;
− компоненты информационной инфраструктуры;
− компоненты доступа к данным;
− компоненты аналитической отчётности.
Модель СОТОП предназначена для своевременного обеспечения
предприятий и организаций, участвующих в проектировании, производстве, испытаниях и эксплуатации КК, актуальной информацией, необходимой для выполнения работ по поддержанию требуемого уровня технического состояния и надежности КК и входящих
в его состав изделий на всех этапах их жизненного цикла [2].
Модель СОТОП должна представлять собой совокупность средств
и методов сбора, обработки, обмена, хранения, поиска и представления информации, функционирующих на единых принципах и по
общим правилам.
Модель СОТОП функционально должна обеспечивать информационное взаимодействие и доступ потребителей к соответствующим
16
территориально-распределенным системам обработки и хранения
данных и включать в себя:
− информационные ресурсы – совокупность консолидированных
данных и знаний, организованных специальным образом для эффективного доступа к информации о РН;
− информационное взаимодействие – распространение (обмен)
информационными ресурсами между предприятиями (организациями) кооперации на всех этапах жизненного цикла РН на основе соответствующих информационных технологий;
− информационную инфраструктуру – совокупность территориально-распределенных организационных и программно-технических средств, обеспечивающих информационное взаимодействие.
Компоненты управления информационными ресурсами предназначены для сбора, интеграции и хранения разнородной информации о РН.
Компоненты информационной инфраструктуры предназначены
для организации эффективной коммуникационной среды, основанной на единых принципах и механизмах обмена электронными
данными между предприятиями и организациями, участвующими
в создании, производстве и эксплуатации РН.
Компоненты доступа к данным предназначены для реализации
сервисов обработки и представления информации, а также поддержки единых принципов идентификации, аутентификации субъектов и объектов информационного взаимодействия.
Компоненты генерации аналитической отчётности предназначены для формирования различных отчётных документов и протоколов на основе данных информационных ресурсов.
Компоненты модели СОТОП должны располагаться на предприятиях промышленности, в эксплуатирующих организациях и организациях Генерального заказчика, участвующих в системе информационного взаимодействия о техническом состоянии и надежности РН и включенных в единую информационную инфраструктуру
СОТОП.
Для решения задачи формирования обобщенной модели электронной структуры изделия (ОМ ЭСИ) должны быть выработаны
требования к представлению документации в электронном виде
и переводу уже выпущенной документации в электронный вид.
Создание модели СОТОП, в соответствии с требованиями ТЗ,
соединенного с автоматизированными комплексами контроля/мониторинга технического состояния и надежности КК во всех организациях и предприятиях, участвующих в системе информации
17
о техническом состоянии и надежности КК, позволит встроить её
в существующую структуру системы информации и, таким образом, внедрить новую технологию построения системы информации
о техническом состоянии и надежности КК. Что позволит более
эффективно использовать не только всю информацию о качестве
функционирования систем и агрегатов КК на всех этапах его жизненного цикла в реальном масштабе времени, но и накопленный
опыт специалистов при проектировании, изготовлении, испытаниях и штатной эксплуатации КК.
Система информации о техническом состоянии конкретного
РН будет базироваться на единой, постоянно пополняемой информационной базе данных и знаний в едином информационном пространстве (ЕИП), доступной всем пользователям, участвующим
в системе информации о техническом состоянии и надежности КК
(Заказчики КК, конструкторские бюро, предприятия-изготовители, эксплуатирующие организации, подразделения анализа летнотехнических характеристик КК, институты космической отрасли,
представительства Заказчика), что позволит многократно повысить
оперативность и эффективность мер, направленных на повышение
качества оценивания технического состояния и надежную эксплуатацию КК.
Таким образом, создание модели СОТОП должно обеспечить:
− повышение оперативности и качества информационного взаимодействия предприятий при совместной разработке, производстве
и испытаниях изделий путем создания системы интеграции информационных технологий, относящихся к различным этапам жизненного цикла изделий;
− обеспечение и повышение качества выпускаемой продукции
путем создания эффективной системы сбора и анализа информации
о дефектах и причинах отказов произведенной продукции на всех
этапах жизненного цикла;
− повышение эффективности деятельности предприятий за счет
сокращения издержек при производстве и эксплуатации изделий;
− возможность в режиме реального времени отслеживать деятельность всех включенных в процесс субъектов, их загруженность,
состояние технологий и т.д.;
− повышение оперативности и эффективности принятия решений в процессе управления предприятиями путем использования
непрерывной информации обо всех технологических изменениях
и её оперативного анализа.
18
2. ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ
И ПРИНЦИПЫ ПОСТРОЕНИЯ МОДЕЛИ СОТОП
2.1. Концепция построения модели СОТОП
Основное внимание уделяется анализу следующих основных положений, являющихся базовыми при построении модели СОТОП:
− создание единого информационного пространства предприятий и организаций, участвующих в проектировании, производстве,
испытаниях и эксплуатации РН;
− обеспечение информационного взаимодействия и доступа потребителей к соответствующим территориально-распределенным
системам обработки и хранения данных;
− создание единой структуры управления процессами информатизации и автоматизации на основе общих принципов подходов,
единой технологической политики;
− обеспечение единого нормативного, методического и организационного обеспечения процессов информатизации;
− использование единых подходов, организационно-технических решений, технологий к построению систем защиты информации и обеспечению безопасности информационных ресурсов;
− постепенный переход к интеллектуализации технологий поддержки принятия решений, ориентированных на цепочку «моделирование – прогнозирование – принятие решения».
2.1.1. Виды информации модели СОТОП
Каждой стадии жизненного цикла РН соответствует свой набор данных, характеризующих основные процессы и виды работ на
этой стадии, и их конечные результаты:
− конструкторские данные об изделии: совокупность информационных объектов, создаваемых в процессе проектирования и разработки изделия, содержащая сведения о составе изделия, геометрических моделях изделия, его компонентах и их технических
характеристиках, об их отношениях в структуре изделия, о результатах расчетов и моделирования, допусках на изготовление деталей и т.д.;
− технологические данные об изделии: совокупность информационных объектов, создаваемых на стадии технологической подготовки производства и ассоциированных с информационными объектами, описывающими изделие и его компоненты. Технологиче19
ские данные содержат сведения о способах изготовления и контроля изделия и его компонентов в процессе производства (в том числе
входного контроля покупных изделий и материалов), описание
маршрутных и операционных технологий, нормы времени и расхода материалов, управляющие программы для станков с ЧПУ,
а также данные для проектирования приспособлений, специального и измерительного инструмента и т.д.;
− производственные данные об изделии: совокупность информационных объектов, создаваемых в процессе производства, описывающих изделие и его компоненты, а также содержащих сведения
о статусе конкретных экземпляров изделия и его компонентов
в производственном цикле;
− данные о качестве изделия: совокупность информационных
объектов, создаваемых при выполнении всех видов контроля, ассоциированных с информационными объектами, описывающими
изделие и его компоненты, содержащих сведения о степени соответствия конкретных экземпляров изделия и его компонентов заданным техническим требованиям, техническим условиям, требованиям стандартов и другим нормативно-техническим документам;
− логистические данные об изделии: совокупность информационных объектов, создаваемых в процессе проектирования и разработки, ассоциированных с информационными объектами, описывающими изделие и его компоненты, содержащих сведения, необходимые для интегрированной логистической поддержки изделия
на постпроизводственных стадиях ЖЦ изделия;
− эксплуатационные данные об изделии: совокупность информационных объектов, создаваемых в процессе проектирования
и разработки, содержащих сведения, необходимые для организации обслуживания, ремонта и других действий, обеспечивающих
работоспособность систем и агрегатов и изделия в целом, готовность
к целевому применению.
Кроме того, совокупность информационных объектов, порождаемых на стадии эксплуатации, может быть представлена (в соответствии с ассоциированными данными и документами) следующими
основными видами:
− технологическая информация;
− организационно-техническая информация;
− измерительная информация.
Технологическая информация включает следующие сведения:
− конструкторская (КД) и эксплуатационная (ЭД) документации, извещения и пр.;
20
− сведения о ресурсах, регламентных работах, доработках и ремонтах, информация о результатах технических проверок, наличии комплектующих и запасных частей, инструментов и принадлежностей (ЗИП) с указанием гарантийных сроков хранения;
− данные о текущем состоянии изделия (с рабочих мест подготовки РН);
− технологические графики (ТГ) работ с фактическими сроками
исполнения этапов, а также данные по задержкам и изменениям
сроков отработки ТГ;
− информация о результатах испытаний (сведения о замечаниях,
отказах и неисправностях на ТК, СК и в полёте, качественные оценки результатов испытаний, формализованные данные отчётов об испытаниях, сведения о результатах работы комиссий) и пр.
В состав организационно-технической информации входят:
− приказы и распоряжения;
− переписка;
− технические решения;
− частные ТЗ;
− сведения о принимаемых решениях в ходе испытаний;
− технологические графики работ, сетевые графики;
− репортажная информация;
− донесения, отчеты и данные о ходе выполнения работ и пр.
Измерительная информация включает:
− результаты измерений параметров функционирования систем
РН на всех этапах испытаний и эксплуатации;
− информация от смежных информационных и управляющих
систем и пр.
Измерительная информация представляет собой результаты
телеметрических измерений проводимых различными комплексами.
2.1.2. Используемые методологии и технологии
В настоящее время мало кто подвергает сомнению необходимость
внедрения интегрированных систем управления разработкой и эксплуатацией космических комплексов и систем, основанных на новых информационных технологиях, сгруппированных под общим
термином технологий информационной поддержки изделия (ИПИтехнологий) [23].
В соответствии с этой концепцией, для структурированного
хранения информации об изделии, организации консолидирован21
ных информационных ресурсов, принятия оперативных и эффективных управленческих решений на основе достоверных данных
применяются информационные технологии поддержки жизненного цикла продукции, которые принято называть PLM. PLM (англ.
Product lifecycle management) дословно – это управление жизненным циклом изделий. Иными словами, PLM – это подход (концепция), основанный на централизации всей информации об изделиях
в едином информационном пространстве.
Современный рынок PDM/PLM-систем широко представлен как
отечественными, так и зарубежными продуктами. В качестве наиболее широко применяемых на предприятиях машиностроения
можно отметить следующие разработки фирм: PTC (WindChill),
Dassault Systèmes (SmarTeam), HetNetIBM (ENOVIA), EDS-UG
(TeamCenter), АСКОН (ЛОЦМАН) [14].
Стоит отметить, что основную долю установленного ПО на отечественных предприятиях занимают компоненты САПР а не целостные PLM – системы.
Важнейшим компонентом PLM является организационно-техническая система PDM (Product Data Management), обеспечивающая управление всей информацией об изделии. С помощью PDMсистем осуществляется отслеживание больших массивов данных
и инженерно-технической информации, необходимых на всех стадиях ЖЦ изделия.
В PDM-системах обобщены такие технологии, как:
− управление инженерными данными (engineering data
management – EDM);
− управление документами;
− управление информацией об изделии (product information
management – PIM);
− управление техническими данными (technical data management
– TDM);
− управление технической информацией (technical information
management – TIM);
− управление и манипулирование электронной информацией,
всесторонне определяющей конкретное изделие.
PLM – это концепция управления, а PDM – это инструмент реализации большей части положений этой концепции, предполагающий переход от оперирования понятием «Документ» (спецификация, чертеж и пр.) к понятию «Изделие», как ключевому объекту
деятельности, принимая во внимание все аспекты стадий жизненного цикла.
22
По сути, PDM система предусматривает:
− создание единой интегрированной среды управления инженерными данными и проектами;
− создание электронного хранилища всей информации о создаваемом изделии на всем протяжении его жизненного цикла;
− создание полного электронного описания изделия со всей сопутствующей информацией, включая электронные модели деталей
и сборок, конструкторскую, технологическую и эксплуатационную
документацию, результаты инженерных расчетов, документацию
по испытаниям и т.д.;
− решение проблем совместного функционирования компонентов САПР различного назначения, координацию работы систем
CAE/CAD/CAM, управления проектными данными и проектированием;
− поддержку интеграции с другими программными средствами,
использующимися для поддержки жизненного цикла изделия;
− управление и мониторинг, обеспечение планирования, актуальный и достоверный контроль выполнения всех этапов работ.
В настоящее время не существует систем, которые в полной мере
реализуют концепцию управления жизненным циклом изделия,
т.к. на практике отсутствуют критерии определения принадлежности системы к какому-то определенному классу. Многие производители относят свои продукты к нужному им классу только потому,
что в систему в ограниченном, а иногда и просто в декларативном
виде, включены функции, соответствующие требуемому классу.
Программные комплексы, реализующие набор PDM технологий, носят универсальный характер. Отчасти это продиктовано требованиями рынка и растущими возможностями программного обеспечения и вычислительными мощностями. Необходимый уровень
специализации в этом случае достигается настройкой программного обеспечения, созданием специальных библиотек, модулей,
а также формированием методической основы моделирования
и проведения расчетно-аналитических работ.
Один из наиболее востребованных комплексов в области трехмерного моделирования Creo Elements/Pro(Pro/ENGINEER) состоит из основной универсальной программы и ряда подключаемых
модулей. Наиболее развитый российский программный комплекс
трехмерного моделирования «Компас-3D» также обладает целым
рядом подключаемых библиотек и специальных приложений, в том
числе специализированных для аэрокосмической отрасли. Именно
формирование и внедрение в процесс проектирования, конструи23
рования и производства данных методик позволяет в полной мере
реализовать возможности программного обеспечения и серьезно повысить эффективность проектирования.
Например, разрабатываемая и адаптируемая к особенностям
процесса проектирования и производства на предприятиях РКО
методология нисходящего проектирования, представляет собой
комплекс достаточно сложных взаимоувязанных методик работы
с инструментами CAD /CAM/CAE под управлением PDM-системы,
которые призваны обеспечить сквозной процесс проектирования
и производства, полную увязку всех моделей и тем самым существенно повысить эффективность работы предприятий [13].
Однако универсальность комплексов, реализующих набор PDM
технологий, не в полной мере обеспечивает решение задач повышения надёжности, эффективности и качества информационной поддержки изделия на всех стадиях ЖЦ и не приносит ожидаемых результатов по следующим причинам:
− отсутствие единой концепции автоматизации подразделений
и организаций кооперации: предприятия обладают большим числом разнородных и узкоспециализированных автоматизированных
систем, зачастую выполняющих одинаковые функции и плохо стыкующихся между собой;
− отсутствие системного подхода к выбору программных средств:
программное обеспечение выбирается на основании не всегда достоверной рекламной информации, без учёта специфики предприятий,
целей внедрения, детального анализа заявленного функционала
и анализа отечественного и международного опыта внедрения;
− отсутствие отечественной нормативной базы, позволяющей перейти от традиционных методов организации процессов проектирования, производства, испытаний, эксплуатации и т. д., основанных
на бумажном документообороте, к новым, основанным на электронном взаимодействии и обмене данными. Существующий комплекс
стандартов (ЕСКД, ЕСТД, ЕСПД и др.), ряд отраслевых стандартов
и других нормативных документов не позволяет отказаться от традиционного бумажного документооборота. Применение компьютерных технологий для обмена электронными данными только дублирует бумажный документопоток;
− достаточно низкая конкурентоспособность российских разработчиков ИПИ-технологий по сравнению с западными фирмами. В частности, отсутствие у российских разработчиков ПО комплексных решений по построению единого информационного пространства, технологиям поддержки принятия решении на всех стадиях ЖЦ;
24
− наличие у процессов проектирования, производства и эксплуатации следующих аспектов сложности: структурная сложность,
сложность функционирования, сложность выбора поведения, сложность развития, сложность моделирования;
− невозможность учесть все характеристики информационных потоков, сопровождающих изделие, особенно на постпроизводственых
стадиях ЖЦ (объемность, разнородность, взаимосвязанность и пр.);
− отсутствие средств и методов интеграции технологической, организационно-технической и измерительной информации, формируемой АСУ различного уровня, развёрнутыми на площадках (космодромах) запуска;
− отсутствие единой методологии и технологий, обеспечивающих работу со знаниями, экспертными заключениями, набором
гипотез (альтернатив), прогнозными оценками и формирующими
набор базовых инструментов поддержки принятия решений.
Все перечисленные факты существенно снижают эффективность
применения «мощных» PDM-систем при решении задач повышения уровня надёжности и безопасности КК. При этом функционал
таких систем зачастую значительно выходит за рамки решаемых
задач, что приводит к большим необоснованным затратам материальных и интеллектуальных ресурсов.
Следует отметить, что процессы и работы при применении РН на
космодромах находятся в информационном отрыве от предыдущих
стадий ЖЦ. Обмен информацией во всех направлениях между этапами проектирования, производства и эксплуатации осуществляется либо на бумажных носителях, либо их электронными копиями,
но и в том и в другом случаях – в виде текстовых документов. Форма, содержание и периодичность представления данных документов регулируется рядом отраслевых и государственных стандартов
ограниченного распространения.
Причиной данного отрыва следует назвать территориальную
и организационную разнесённость этапов изготовления и применения космических средств. При этом достаточно сложным является
процесс межведомственного согласования характеристик информационных потоков. Кроме того, как показано в [12,13], в самой организации, применяющей изделия ракетно-космической отрасли –
на космодроме, отсутствуют системы сквозного и непрерывного информационного сопровождения подготовки и пуска РН.
Действительно, процесс подготовки и пуска РН – это совокупность более детальных, но не менее сложных подпроцессов:
− доставка с завода изготовителя на космодром;
25
− сборка на техническом комплексе;
− различные виды испытаний;
− вывоз на стартовый комплекс;
− заправка и пуск РН.
На протяжении всех указанных этапов должны быть обеспечены непрерывность и согласованность информационных потоков,
а также гарантированный и непрерывный доступ ко всем информационным ресурсам.
В связи со всем вышеизложенным, является актуальным интеграция информационной среды (PDM-систем, АС различного
назначения, система электронного документооборота (СЭД), электронных фондов и пр.) предприятий ракетно-космической отрасли
с информационной средой космодрома. Кроме того, не менее важен
комплекс мероприятий по организационной и информационной
интеграции с другими участниками кооперации, основанный на
единых принципах и технологиях, реализуемый с использованием
унифицированных программных платформ.
Именно такую глобальную интеграционную (для всех не только
данных, но знаний), функционально сложно структурированную
задачу и призван решить СОТОП. При этом СОТОП не является
в целом ни PLM, ни PDM, ни СЭД-системой, как это указано выше,
и должен строиться с учётом изложенных ниже принципов.
2.1.3. Основные принципы построения модели
Все участники системы информации о РН должны постоянно обмениваться актуальной и достоверной информацией при гарантированной доступности территориально-распределённых информационных ресурсов.
Несложно понять, что без стандартизации методов, подходов,
требований к информационным системам, тщательной проработки
принципов и функциональной структуры информационных ресурсов, информационного взаимодействия и информационной инфраструктуры решение задач по совершенствованию системы информации о техническом состоянии и надежности РН не представляется
возможным.
Прежде всего, необходимо определить принципы построения модели СОТОП РН, основные из которых базируются на понятии информационной среды.
Информационная среда – это совокупность информационных
ресурсов, информационного взаимодействия, информационной ин26
фраструктуры, т.е. всего набора условий для реализации технологической цепочки «данные – информация –знания – решения».
Информационные ресурсы есть совокупность консолидированных данных и знаний, организованных специальным образом для
эффективного доступа информации о РН.
Информационное взаимодействие – распространение (обмен) информационными ресурсами между предприятиями (организациями) кооперации на всех этапах жизненного цикла РН на основе соответствующих информационных технологий и регламентов.
Информационная инфраструктура представляет собой совокупность территориально-распределенных организационных и программно-технических средств, обеспечивающих информационное
взаимодействие.
Информационная среда как единая система, должна предоставлять комплекс (набор) методов и средств для организации работы
с информацией, применения технологий интеллектуальной обработки и эффективного использования знаний и, по сути, должна являться основой для функционирования системы информации. Система информации, в соответствии с [2], определяется как организационная совокупность технических и обеспечивающих средств,
технологических процессов и кадров, реализующих функции сбора, обработки, хранения, поиска, выдачи и передачи информации.
Определим следующие основные принципы создания, развёртывания и использования модели СОТОП:
− в основе модели СОТОП должен лежать поэтапный переход
к безбумажным технологиям ведения всех сфер деятельности (организационно-управленческой, проектно-конструкторской, производственно-технологической и эксплуатационно-технической);
− основными структурными элементами модели СОТОП должны
быть базы данных и знаний о созданных и создаваемых изделиях,
результатах их испытаний и эксплуатации;
− базы данных и знаний должны рассматриваться как основа
для долгосрочной стратегии, нацеленной на повышение эффективности на всех стадиях ЖЦ изделия;
− в рамках информационных ресурсов, модель СОТОП должна обеспечиваться хранение и доступ к разнородной информации
(структурированной и слабо структурированной);
− должно быть обеспечено структурное представление хранимых
данных в виде, позволяющем конечному пользователю осуществлять доступ к ним без привлечения экспертов, а также хранение
метаданных и других атрибутивных признаков, необходимых для
27
сохранения материалов и обеспечения долговременного доступа
к ним;
− должна быть предусмотрена возможность информационного
взаимодействия с автоматизированными (информационными) системами (подсистемами) организаций и предприятий кооперации
на основе единых подходов;
− должна быть обеспечена возможность работы в условиях существенного роста (объема) информационных ресурсов, количества
вновь подключаемых источников информации без существенного
изменения прикладного программного обеспечения (масштабируемость);
− вся информация по РН должна формироваться в виде единого
информационного объекта – электронного описания изделия (ЭОИ)
[19], а также привязываться к элементам электронной структуры
изделия (ЭСИ) [18] и стадиям его жизненного цикла;
− при работе с данными и знаниями должны соблюдаться принципы комплексности и системности, заключающиеся в возможности обработки и оценки всей необходимой совокупности данных
в различных разрезах, с учётом внутренних структур и связей;
− создание и развитие модели СОТОП должно базироваться на
использовании единой корпоративной сети передачи данных, единых механизмах обмена данными;
− формируемая коммуникационная инфраструктура должна
обеспечивать безотказное и оперативное доведение информации для
всех участников кооперации, обеспечивая полноту и своевременность предоставления данных, необходимых для принятия управленческих решений;
− при разработке основных принципов и технологий в рамках
модели СОТОП должен быть предусмотрен учёт (анализ) зарубежного опыта и ранее накопленного опыта в ведущих предприятиях
ракетно-космической отрасли;
− применяемые средства информатизации должны, по возможности, поддерживать международные стандарты представления
и обмена информацией в электронном виде;
− в рамках модели СОТОП должны использоваться единые системотехнические решения для ведения и поддержания системы
классификации и кодирования, комплектования, каталогизации,
информационного поиска и доставки документов, а также унифицированной системы видов и форм документов;
− создание модели СОТОП должно осуществляться с использование унифицированных программно-аппаратных платформ на осно28
ве базовых информационных защищенных компьютерных технологий (БИЗКТ);
− должно использоваться общесистемное и прикладное программное обеспечение отечественной разработки, функционирующее в среде БИЗКТ;
− архитектура модели СОТОП должна обеспечивать возможность поэтапной разработки и внедрения. Это позволит обеспечить
расширение функциональных характеристик без принципиальных
доработок (замены) аппаратно-программных и платформенных решений;
− должен обеспечиваться принцип невмешательства (в соответствии с разработанными при внедрении регламентами) в налаженную, отработанную и закрепленную соответствующими нормативными документами информационную технологию проектирования,
производства и испытаний, существующую в территориально-разнесенных организациях.
Более подробно рассмотрим следующие основные принципы, являющиеся определяющими при построении модели СОТОП:
− формирование единого информационного пространства;
− взаимодействие с информационными системами;
− построение электронного описания изделия;
− применение унифицированных программных платформ;
− использование технологий и инструментальных средств автоматизированной разработки ПО.
2.1.3.1. Формирование единого информационного пространства
Информационное пространство может создаваться, конфигурироваться и функционировать как ведомственная (в рамках отдельного предприятия или организации), так и как отраслевая (в рамках
единого информационного поля отрасли) среда, где главной составляющей (информационным объектом) выступает РН. Именно в контексте последней конфигурации можно вести речь о реализации
единого информационного пространства модели СОТОП РН.
Таким образом, ЕИП представляет собой совокупность данных
и знаний, организованных специальным образом, построенное
с использованием систем баз данных (БД), файловых хранилищ,
технологий их ведения и использования, информационно-телекоммуникационных систем и сетей, функционирующих на единых
принципах и по общим правилам, обеспечивающих информационное взаимодействие и доступ потребителей к этим территориально29
распределенным информационным ресурсам из организаций
и предприятий кооперации отрасли, участвующих в совершенствовании системы информации РН.
При этом основой ЕИП являются технологии формирования
и управления предметно-ориентированными, интегрированными,
достоверными, доступными поддерживающими хронологию наборами данных.
Важно отметить, что основные цели создания модели СОТОП совпадают с целями создания ЕИП [14].
ЕИП рассматривается как целостная структура, направленная на
информационное, организационно-техническое обеспечение и управление данными, процессами и этапами работ на всех этапах ЖЦ РН.
Основными свойствами ЕИП являются:
− интегрированность – данные из различных информационных
ресурсов представляют упорядоченное, взаимосвязанное, функциональное объединение;
− предметная ориентация – данные атрибутируются в соответствии с электронным описанием объекта информации и стадиями
ЖЦ;
− структурированность – иерархия данных выстроена в соответствии с электронной структурой изделия, доступ к ним предоставляется через соответствующие логические разделы электронного
каталога фондов хранения;
− инвариантность во времени – данные сохраняют свою истинность на протяжении всех стадий ЖЦ и при архивном хранении,
каждый элемент данных ассоциирован с датой своего возникновения;
− неразрушаемость (стабильность информации) – однажды загруженные данные никогда не изменяются и не уничтожаются;
− минимизация избыточности информации – при загрузке данные фильтруются, преобразуются, исключается их избыточность;
− доступность – на всех стадиях ЖЦ и информационного цикла
(рождение информации, ее накопление, обработка, анализ и использование) обеспечивается гарантированное предоставление информации потребителям в соответствии с установленными регламентами и полномочиями.
Основу единого информационного пространства составляют метаданные (мета-схема ЕИП), представляющие формальное описание единой интегрированной информационной модели изделия,
а также данных и знаний, циркулирующих в ЕИП [17].
Метаданные используются для описания и автоматизированной
обработки содержимого ресурса, построения поисковых индексов
30
и позволяют обеспечить достаточно высокую точность и эффективность выбора разнотипной информации.
Мета-схема ЕИП определяет термины и семантику описания
и применения единой интегрированной информационной модели
изделия и должна обеспечивать:
− описание объектов инфраструктуры ЕИП c перечнем атрибутов
и отношений между объектами;
− синтаксическую интероперабельность – описание типов данных, форматов и моделей различных информационных ресурсов на основе согласованных унифицированных подходов и стандартов;
− семантическую интероперабельность – создание и согласование стандартных прикладных профилей метаданных и онтологий,
относящихся к различным предметным областям, что позволяет
упростить интеграцию разнообразных систем, автоматизацию обмена метаданными, их обработку и преобразование;
− открытость – доступ к соответствующей информации по описаниям (мета-элементам);
− расширяемость – возможность детализации описаний и добавление новых метаданных;
− уникальную идентификацию информации и объектов инфраструктуры – возможность установления взаимосвязей между
ресурсами разных информационных источников распределенной
среды, способность объединять связанные данные отдельных репозиториев в виртуально-единые ресурсы.
− возможности интеграции информации (при расширении/добавлении объектов ЕИП) на основе использования существующих
информационных стандартов.
Сервисы, поддерживающие ЕИП должны базироваться на технологиях, позволяющих:
− эффективно размещать и осуществлять поиск информации
в распределенной среде;
− создавать динамические средства описания информационных
объектов с возможностью расширения репозитариев описаний, по
мере увеличения данных и знаний об этих объектах, с адекватным
отображением в структурах баз знаний и БД;
− создавать средства поддержки (целостность, репликация,
управление) ЕИП и эффективных инструментов расширения;
− создавать инструментальные средства обработки данных по
информационным объектам с возможностью их конфигурирования
для обработки групп взаимосвязанных объектов;
31
− создавать эффективные инструменты миграции (частичной репликации) информации при расширении ЕИП на новые узлы информационной инфраструктуры.
В ЕИП важны не только характеристики информационной составляющей (многомерность, многоуровневость, интегрированность
данных, многообразие информационных потоков и пр.), но и информационный комфорт, под которым понимается доступность информации, способность оперативно получать данные информационных
ресурсов, возможность извлекать требуемые знания, проводить аналитическую обработку, формировать отчётные документы и т.д.
2.1.3.2. Интеграция информационных систем
Информационная система (автоматизированная) представляет
собой взаимосвязанную совокупность системы обработки информации и соответствующих ресурсов (программных, технических,
информационных и т. д.) и предназначена для сбора, хранения, обработки и распространения информации.
Основной акцент при построении модели СОТОП делается на создание такой функциональной структуры, в рамках которой существующие автоматизированные системы являются источниками/
потребителями информации.
Автономно функционирующие ведомственные системы PDM,
САПР, СЭД, АСУ различного уровня уже развёрнуты и функционируют в информационной среде многих предприятий и организаций
РКО. Очевидно, что при организации их взаимодействия на основе
технологий и архитектурных решений модели СОТОП задача замены уже используемых систем какими-либо другими не возникает,
поскольку такие мероприятия связаны с дорогостоящими и длительными процедурами. Замена может быть вызвана лишь выявленной недостаточной функциональностью используемых АСУ или
невозможностью сопряжения с техническими и программными
средствами модели СОТОП, ввиду использования устаревших информационных технологий.
Практическая реализация модели СОТОП основывается на идее
использования информационных систем предприятий и организаций
кооперации РКО, как источников информации об изделии на различных стадиях ЖЦ, обработке этой информации внутри модели СОТОП
и при необходимости обратного экспорта обработанных данных (результатов) в информационную систему предприятия с целью организации интегрированных коллекций информационных ресурсов на
32
всех стадиях жизненного цикла РН. Положительным эффектом от
внедрения такой технологии является постепенное распространение
унифицированных представлений типовых документов в рамках кооперации с возможностью последующей автоматизации обработки (извлечения) данных из таких унифицированных документах.
Модель СОТОП использует набор технологий интеграции разнородных данных, предоставляя возможности их использования
различными категориями пользователей, сокращая организационные и информационные разрывы при принятии управленческих решений.
Проблема интеграции данных о РН на всех стадиях жизненного цикла чрезвычайно многоаспектна и многообразна. Сложность
и характер используемых методов ее решения существенным образом зависят от уровня интеграции, который необходимо обеспечить, свойств отдельных источников данных и всего множества информационных ресурсов.
Рассмотренные ранее PDM системы (системы управления данными об изделии) предоставляют ряд готовых технологий и программно-технических решений, помогающих в той или иной мере
решить задачу интеграции.
Как правило, данные системы слишком дорогостоящи, разработаны зарубежными компаниями, используют закрытое ПО, решают комплекс задач интеграции в общем виде и могут применяться
лишь на отдельных стадиях жизненного цикла изделия. В любом
случае, для максимальной эффективности использования автоматизированных систем, входящих в ведомственную информационную среду, необходима интеграция информационных ресурсов всех
поставщиков и потребителей данных о РН в рамках единого информационного пространства.
К основным интеграционными подходами, реализуемым в рамках модели СОТОП, относятся:
− интеграция данных;
− интеграция приложений;
− интеграция процессов обмена информацией;
− интеграция взаимодействий пользователей.
Интеграция данных (информационных ресурсов) обеспечивает
получение единого представления обо всех информационных объектах на всех стадиях жизненного цикла изделия.
Интеграция разнородных приложений позволяет управлять потоками событий и координировать работу приложений в контексте
транзакций, сообщений или данных.
33
Интеграция процессов обмена информацией обеспечивает реализацию единых протоколов и регламентов обмена между поставщиками и потребителями информации в рамках информационного
взаимодействия.
Интеграция взаимодействия пользователей обеспечивает единый интерфейс доступа к интегрируемым информационным ресурсам с учетом установленных полномочий.
В основе всех перечисленных интеграционных подходов лежит
интеграция данных. Основными методами интеграции информационных ресурсов являются:
− консолидация;
− федерализация;
− распространение (миграция).
Метод консолидации данных (актуальное (материализованное)
представление) предусматривает использование единого централизованного хранилища интегрирующего разнородную информацию
из нескольких информационных систем.
При использовании метода федерализации данных (виртуальное
представление) образуется единое виртуальное информационное
пространство, данные в котором могут храниться в различных территориально-распределённых информационных системах.
Наконец, метод распространения (миграции) предусматривает перенос набора данных из одной информационной системы
в другую.
Следует отметить, что рассматриваемые унифицированные программные платформы реализуют как методы интеграции, основанные на консолидации данных в едином хранилище, так и организацию распределённой архитектуры хранения информационных
ресурсов.
Первый способ является основой программной платформы
управления электронными фондами модели СОТОП и предусматривает построение централизованной системы интеграции данных.
Организация распределённой архитектуры хранения информационных ресурсов является базовой методологией программной
платформы управления данными, формируемыми АСУ сложных
организационно-технических объектов.
Интеграция данных в модели СОТОП обеспечивается на следующих уровнях:
− физическом;
− логическом;
− семантическом.
34
Интеграция данных на физическом уровне, с практической точки зрения, является наиболее простой задачей и сводится к преобразованию данных различных источников в единый формат физического представления.
Интеграция данных на логическом уровне предусматривает возможность доступа к данным, содержащимся в различных источниках, в терминах единой глобальной схемы, которая описывает их
совместное представление с учетом структурных и поведенческих
свойств. Семантические свойства данных при этом не учитываются.
Поддержку единого представления данных с учетом их семантических свойств в контексте единой онтологии предметной области
обеспечивает интеграция данных на семантическом уровне.
Источники данных информационных ресурсов СОТОП обладают
различными свойствами:
− являются производными организационно-технических, технологических и измерительных систем;
− поставляют первичные (необработанные) и вторичные (обработанные) данные;
− формируют полные и сокращённые (существенные) потоки информации;
− поддерживают представление данных в терминах иерархической, реляционной и объектно-ориентированной моделей;
− могут генерировать однородные или неоднородные потоки
данных.
Неоднородность поступающих из источников данных проявляется в информационных системах в различных аспектах.
Так, при интеграции на физическом уровне в источниках данных могут использоваться различные форматы файлов или структуры пакетов информации.
На логическом уровне интеграции для различных источников
может иметь место неоднородность используемых моделей данных или различие схем данных, при использовании единой модели
данных.
Информационно-управляющие системы, системы электронного
документооборота, объектные и реляционные базы данных и другие источники информации отличаются семантическими свойствами данных, при этом, как правило, каждому такому источнику соответствует своя онтология.
В ходе экспериментов с моделями СОТОП решался ряд задач,
состав которых зависел от требований к системе интеграции и используемых подходов.
35
К ним, в частности, относятся:
− разработка принципов построения системы интеграции данных с учётом их семантики;
− создание интегрирующей модели данных, являющейся основой единого пользовательского интерфейса модели СОТОП;
− разработка методов отображения моделей данных разнородных источников и построение отображений (правил преобразований) в интегрирующую модель централизованного хранилища;
− интеграция понятий и метаданных, используемых в системе
источников данных;
− преодоление неоднородности источников данных.
В качестве интегрирующих (глобальных) моделей данных использованы реляционные модели и методы, основанные на стандартах XML.
В качестве инструмента интеграции данных выбран комбинированный набор технологий, поддерживаемых унифицированными
программными платформами:
− сервис-ориентированные технологии, использующие набор
программных посредников (адаптеров) для доступа к разнородным
информационным ресурсам;
− технологии преобразования разнородной информации различных систем в интегрированные наборы данных, организации
и ведения архивных и оперативных баз данных (централизованных
и распределённых);
− технологии организации файловых хранилищ, обеспечивающих консолидированное хранение и доступ к большим объёмам
разнородной информации;
− технологии доступа к информационным ресурсам с использованием специализированных протоколов;
− технологии интеграции коллекций текстовых информационных ресурсов (электронных документов), предусматривающие,
главным образом, интеграцию метаданных источников, каталогов,
классификаторов, тезаурусов, онтологий и т.д.
− технологии обмена файлами и коллекциями файловых каталогов;
− технологии пакетного обмена данными на основе предметноориентированных схем метаданных.
При выборе и реализации технологических решений по системе
интеграции данных применялись положения ряда отечественных
и международных стандартов.
Среди них[22]:
− стандарты баз данных ISO/IEC SQL, ISO/IEC SQL/MED;
36
− стандарт объектных данных консорциума ODMG;
− стандарты UML консорциума OMG;
− стандарты платформы XML консорциума W3C;
− стандарт Дублинского ядра консорциума OCLC;
− стандарты инициативы открытых электронных архивов (Open
Archives Initiative, OAI),
− и ряд других.
При этом главное назначение стандартов при разработке методов
интеграции – определение унифицированной модели данных (метаданных), являющейся основой единого интерфейса для доступа
к интегрированным информационным ресурсам со стороны приложений (сервисов) и пользователей.
2.1.3.3. Построение модели электронного описания изделия
Одной из основных задач модели СОТОП является возможность
предоставления всем участникам информационного взаимодействия (с учетом их полномочий) актуальных и достоверных данных
в любое время и в любом месте (в рамках ЕИП) вне зависимости от
того, где, когда и кем эти данные были сформированы.
В рамках модели СОТОП единым источником информации о РН
является электронное описание изделия.
Один из основных принципов построения модели СОТОП (сформулированных ранее) гласит, что вся загруженная в модель СОТОП
информация по конкретному изделию РН должна консолидироваться в едином информационном объекте – экземпляре электронного описания изделия, и привязываться к элементам электронной
структуры изделия и стадиям его жизненного цикла.
Пользователи получают информационную поддержку своей деятельности, а также любую требуемую информацию об изделии, его
тактико-технических данных, конструкции, контроле производства, особенностях его обслуживании и эксплуатации, опираясь на
единое ЭОИ, что обеспечивает возможность перехода на более высокий уровень интеграции данных об изделии — подняться с уровня
конкретных конструкторских документов на уровень совокупности
конструкторских документов и данных.
Ключевой методологией концепции электронного описания изделия является объектно-ориентированное моделирование.
Обычно в процессе традиционного математического моделирования для решения прикладных вычислительных задач основой разработки становится единственная математическая модель объекта
37
предметной области, которая через прикладной интерфейс адаптируется к различным областям практических приложений.
Однако такой подход к решению задач на всех стадиях ЖЦ РН
реализовать практически невозможно, так как, ввиду существенного различия процессов и видов работ на каждой из стадий ЖЦ,
которые необходимо отразить в ЭОИ, единую модель создать невозможно.
При объектно-ориентированном подходе основой системы становится не одна модель в какой-то предметной области, а общая (интегрированная) модель изделия – электронное описание изделия.
Согласно [3], под понятием ЭОИ подразумевается единая интегрированная модель, содержащая всю информацию об изделии,
требуемую на любом из этапов его ЖЦ, а при формировании каждого фрагмента модели – используются единые средства и методы
построения. При этом подразумевается также обеспечение целостности всей модели, описывающей изделие.
Электронное описание изделия превращает всю совокупность
информации о РН в важнейший информационный ресурс и позволяет решать следующие задачи:
− обеспечивать информационную совместимость различных автоматизированных систем на этапах проектирования, производства, эксплуатации;
− обеспечивать обмен электронными документами (конструкторскими, эксплуатационными и пр.), а также результатами всех видов
испытаний, данными объективного контроля;
− проводить общую оценку уровня надёжности изделия, всех его
составных частей, а также готовности к выполнению целевой задачи.
ЭОИ имеет большой объем и включает в себя данные, относящиеся к различным стадиям жизненного цикла. Вследствие этого, процесс создания интегрированной модели является также дискретным (с точки зрения ЖЦ изделия): отдельные наборы электронных
данных формируются и включаются в ЭОИ на разных стадиях ЖЦ.
Вследствие указанных особенностей, ЭОИ имеет модульный
принцип построения. Модульность ЭОИ требует наличия средств,
описывающих состав модулей, их основные параметры (дату создания, перечень соответствующих электронных документов, их атрибуты, права доступа и т.д.), а также структурную иерархию. Если
содержимое каждого из модулей – это данные об изделии, то описание самих модулей – это метаданные. Данные, описывающие модули, формируют структуру интегрированной модели изделия, поэтому они являются структурными метаданными. С точки зрения
38
модели СОТОП и принципов формирования её электронных фондов, модули представляют предметно-ориентированные комплекты
электронных документов, соответствующие электронной структуре
изделия, стадиям жизненного цикла и размещаются в соответствующих логических разделах электронного каталога архива.
ЭОИ отражает состав изделия с точки зрения иерархической совокупности его составных частей, которую принято называть электронной структурой изделия.
2.1.3.4. Применение унифицированных программных платформ
Понятие платформы и платформенно-ориентированного построения информационных систем сейчас является общепринятым
и трактуется гораздо шире, чем просто способность работать в определенной операционной системе. Под платформой понимается среда
исполнения и набор технологий, используемых в качестве основы
для построения определенного круга приложений. При этом важно,
что платформа предоставляет разработчику определенную модель,
как правило, изолирующую его от понятий и подробностей более
низкоуровневых технологий.
Другим неоспоримым преимуществом является стандартизация. Наличие единой платформы в конкретной предметной области для большого количества прикладных решений способствует
формированию общего «информационного базиса», включающего
и людей (программистов, экспертов-аналитиков, инженеров по знаниям и пользователей) и методологию (типовые структуры данных,
модели и алгоритмы, пользовательские интерфейсы). Опираясь на
этот базис, разработчики тратят минимум усилий на поиск необходимых решений в любой ситуации, начиная от включения в проект
нового специалиста и кончая реализацией какой-либо подсистемы прикладного приложения или решения задач сопровождения
и поддержки.
При выборе программных решений и технологий построения модели СОТОП, основное внимание уделялось анализу существующих
целостных, полнофункциональных программных платформ, при
этом оценивались следующие критерии:
− отечественная разработка и поддержка;
− опыт внедрения, реализованные проекты и отзывы;
− многоплатформенность (в смысле возможности функционирования на различных аппаратных средствах под управлением различных ОС);
39
− надежность и отказоустойчивость;
− масштабируемость;
− совместимость и мобильность программного обеспечения;
− наличие технологий построения систем сбора, хранения, доступа и управления большими объёмами информации;
− наличие технологий интеграции территориально-разнесённых
информационных ресурсов;
− способность оперативной адаптации существующих и создания новых функциональных компонентов и архитектурных решенеий по требованию Заказчика;
− наличие технологий, а также инструментов для разработки
и модификации внутрисистемных компонент на базе платформенных решений.
Ядром модели СОТОП, базовыми программными компонентами, реализующими основной набор целевых функций интеграции,
хранения данных и знаний, организации информационного взаимодействия, являются две унифицированные программные платформы (УПП):
− программная платформа управления электронными фондами;
− программная платформа управления данными.
При выборе программной платформы по управлению электронными фондами рассматривались решения следующих отечественных разработчиков: 1С, DocsVision, CSoft Development,
OmegaSoftware, АСКОН и др. Выбор был сделан в пользу платформы «Архив» [18].
Платформа «Архив» среди остальных выделяется следующим:
− наиболее полно решает задачи архивного учета и хранения информационных ресурсов предприятий;
− обеспечивает работу с общими ресурсами вертикально-интегрированной территориально-распределенной организации с многоуровневой филиальной сетью;
− построена с учетом требований актуальной и нормативной
базы и перспективных методик, рекомендуемых Всероссийским научно-исследовательским институтом документоведения и архивного дела.
Основными преимуществами платформы является:
− предметно-ориентированный подход к организации учета и систематизации информации, индексирование и поиск с учетом требований клиента к индексированию и структурированию информации;
− удобная работа с документами любой структуры и форматов;
40
− быстрое прототипирование отраслевого решения;
− легкий для понимания пользователями интерфейс;
− доступ к массивам данных без ограничения объема;
− конфиденциальность хранящейся информации;
− использование промышленных программно-аппаратных платформ.
Программное обеспечение является основой многих отечественных информационных систем, а в число заказчиков входят крупнейшие отечественные предприятия, государственные организации, учреждения науки и культуры.
Разработанные организационно-технические принципы, методики и технологии легли в основу создания УПП, позволяющей
формировать функционал и архитектуру информационных систем,
обеспечивать решение задач автоматизации процессов мониторинга
и управления, а также реализовать функции поддержки принятия
решения.
Примерами успешной реализации проектов с использованием
данной программной платформы являются ряд проектов в ракетнокосмической отрасли и в атомной энергетике.
Рассмотренные унифицированные программные платформы
представляют собой так называемый framework (скелет, каркас),
на основе которого проектируется, разрабатывается и функционирует приложение. С одной стороны, платформа является фундаментом для построения приложений, а с другой – средой исполнения. Кроме того, платформа содержит, разумеется, и инструментарий, необходимый для разработки, администрирования и поддержки приложений. Модули, реализующие различные функции
инструментария могут являться самостоятельными сущностями
или выступать в качестве отдельных программных продуктов, но
концептуально полностью опираются на технологии платформы.
Кроме того, платформа предлагает разработчику собственную модель работы с данными и изолирует его от особенностей конкретной реализации хранилищ данных, опираясь на соответствующий
функционал.
Базовые элементы построения УПП представлены на рис. 1
Под термином «унифицированность» понимается:
− унифицированность внутрисистемных и внешних интерфейсов взаимодействия;
− унифицированность построения систем сбора, хранения и доступа к информационным ресурсам;
− модифицируемость и устойчивость:
41
Базовое ПО:
− инструментальные средства разработки (среда проектирования);
− исполнительная система;
− система администрирования;
− средства тестирования и отладки;
− средства сбора статистики.
Компоненты
расширения
функциональности
Интерфейсы и библиотеки API, адаптеры и сервисы ЕИП
Метаданные (мета-схема УПП)
Технологии сбора, обработки и хранения данных,
организации вычислений, моделирования,
оценивания и прогнозирования
Рис. 1. Базовые элементы построения УПП
− принцип компонентной архитектуры, предусматривающий кооперацию относительно независимых и заменяемых компонентов
организации системы;
− расширяемость и адаптивность к изменениям объема и количества источников информации, составу функций, расчетных
и аналитических алгоритмов и моделей;
− инвариантность к изменениям в организационной и управленческой структуре, независимость базовых архитектурных решений
от количества и разнообразия источников данных;
− возможность выполнять тестирование элементов платформы
и разрабатываемого прикладного ПО с различным уровнем детализации, сбора статистических данных на разных этапах проектирования и развертывания;
− возможность взаимодействия или интеграции со смежными
информационно-технологическими системами с использованием
открытых международных стандартов и общей модели данных;
− унифицированность решений:
1) широта охвата реализуемых задач;
2) комплексный состав программных средств;
3) многофункциональность используемых аппаратных средств;
4) способность функционировать в условиях реального времени;
5) использование предметно-ориентированного набора технологий работы с данными и знаниями.
42
Выбор платформенно-ориентированного подхода к построению
модели СОТОП позволил проводить эскизное проектирование не «с
чистого листа», а дорабатывать и развивать типовые решения, опираясь на предшествующие наработки, шаблоны, а также использовать высокий уровень адаптируемости существующих решений под
требования Заказчика.
2.1.3.5. Использование технологий автоматизированной разработки
программного обеспечения
Разработка прикладного программного обеспечения элементов
инфраструктуры тесно связана с программными компонентами
интегрируемых информационных систем (модели данных, протоколы информационного взаимодействия и пр.). В процессе функционирования ведомственных автоматизированных систем возможно
изменение характеристик программного обеспечения, включение
в их состав новых уникальных модулей, использование новых протоколов передачи данных. Кроме того, вновь подключаемые информационные системы, также могут обладать набором новых (ранее
неизвестных) программных компонентов, алгоритмов обработки
и интерфейсов.
Поэтому к множеству требований к функциональной и программной архитектуре модели СОТОП, таких, как надежность,
эффективность, быстродействие и т.д., добавляется необходимость
наличия технологий оперативной и эффективной разработки новых программных решений и сопровождения старых. Использование таких технологий должно опираться на отработанные методики, апробированные инструментальные средства, возможность
организации совместной работы программистов и экспертов предметной области, т.е., в конечном счёте, – на автоматизацию процесса разработки прикладного ПО и информационной системы
в целом.
До определенного времени процесс разработки программ не требовал выбора определенной технологии программирования. Технологии либо вообще не было, либо имелись средства, ориентированные на конкретную разработку, создание узкоспециализированных
программных средств, жестко связанных не только с соответствующими предметными областями, но и информационными системами
конкретной организации.
В настоящее время положение изменилось. Согласно установившимся представлениям, понятие «технология разработки про43
граммного обеспечения» включает в себя систему или совокупность
инструментальных средств автоматизации разработки ПО и технологический процесс, регламентирующий порядок организации
и проведения этих работ.
На современном рынке ПО присутствуют разнообразные технологии и поддерживающие их инструментальные средства (прежде
всего CASE-средства – Computer Aided Software Engineering – средства автоматизированного проектирования ПО), зачастую с близкими характеристиками и возможностями.
Однако, уровень представительства отечественных продуктов на
этом рынке ничтожно мал, а реализуемые ими подходы недостаточно эффективны или вообще не обеспечивают решение целого ряда
проблем, стоящих перед теорией и практикой создания автоматизированных систем, интегрирующих большие потоки разнородной
информации и работающих в реальном масштабе времени. Основными из этих проблем являются:
− отсутствие единой концептуальной основы в построении информационных систем, функционирующих как в различных условиях применения, так и целевого назначения;
− наличие большого количества форм представления данных
и, соответственно, типов моделей представления знаний об объектах автоматизации, обусловленное существованием субъективных
взглядов и специализированных подходов в разных заинтересованных организациях, занимающихся проблемами построения информационных систем, что препятствует накоплению, систематизации
и распространению опыта эксплуатации доказавших свою полезность передовых информационных технологий;
− невозможность, как правило, с помощью существующих научных и практических подходов автоматически формировать корректную и оптимальную программу обработки информационных
потоков;
− неспособность известных к настоящему времени прикладных
теорий, моделей и алгоритмов проводить обработку и интеграцию
данных, ввиду существенных особенностей информационных потоков, среди которых можно отметить их естественный параллелизм,
слабо предсказуемую интенсивность, наличие недостоверных данных и др.;
− большие затраты на модернизацию и сопровождение программных комплексов;
− наличие жёсткой зависимости от платформы и системы управления базами данных (СУБД);
44
− недостаточная открытость и малый набор или вовсе отсутствие
интерфейсов взаимодействия с продуктами других производителей;
− сложность в освоении и использовании.
Предлагаемая технология и комплекс инструментальных
средств автоматизированной разработки ПО, входящих в состав
УПП, ориентированы на использование всего доступного набора
данных и знаний, проектирование и разработку без участия коллектива программистов и позволяют существенно сократить сроки
и расходы на создание или модификацию программных решений.
Суть ее состоит в предоставлении специалисту в предметной области широкого набора методик, удобного интеллектуального пользовательского интерфейса для разработки моделей объекта автоматизации, алгоритмов обработки, формирования сценариев интеграции информационных ресурсов, взаимодействия со средствами
долговременного хранения, проектирования и наполнении баз знаний (БЗ), а также для решения непосредственно задач поддержания
и совершенствования функционала информационной системы.
Технология базируется на концепции RAD (Rapid Application Development – быстрая разработка приложений) – создание и использование средств разработки программных продуктов с акцентом на
быстроту и удобство программирования, создание технологического процесса, позволяющего максимально оперативно реализовывать программные решения на всех этапах жизненного цикла процесса проектирования.
Основой технологии является операционная среда (среда проектирования и разработки), а также использование сквозной модели
проектирования программного обеспечения. В соответствии с такой моделью, производится комплексное совместное параллельное
проектирование как самой операционной среды, максимально учитывающей специфику задач предметной области, так и формирование непосредственно архитектуры автоматизированной системы
(АС) для объекта автоматизации. Основные этапы используемой
технологии проектирования АС (смотри рис. 2) включают:
− этап 1. Функциональное проектирование, заключающееся в выявлении информационных потребностей заказчика (предпроектное
обследование, формулировка технических и частных технических заданий на разработку систем и подсистем проектируемого продукта);
− этап 2. Концептуальное проектирование АС (для данных –
формирование концептуальной схемы БД, например, в виде ERDдиаграмм; для процессов обработки данных – определение входных
и выходных данных, варианта интеграции). Концептуальный про45
Рис. 2. Технология сквозного проектирования АС
ект не зависит от реализации и отражает содержательную сторону
проектируемой АС;
− этап 3. Разработка архитектуры АС (выбор модели доступа
к данным, программной платформы общего ПО – операционной системы, системы управления базами данных и др.; выбор аппаратной
платформы – структура вычислительной сети при многомашинном
комплексе и др.);
− этап 4. Логическое проектирование АС (формирование логической схемы БД и разработка прикладных программ с использованием мета-языка операционной среды);
46
− этап 5. Отладка и тестирование прикладных программ АС;
− этап 6. Сопровождение АС.
Объект информатизации – совокупность информационных ресурсов, средств и систем обработки информации, используемых
в соответствии с заданной информационной технологией, а также
средств их обеспечения [19].
При этом также параллельно выполняются следующие объектно-ориентированные этапы проектирования:
− информационное концептуальное моделирование – введение
параметров (концептуальных понятий предметной области), групп
и атрибутов параметров, задание правил сегментации области значений вводимых параметров (для осуществления качественного
анализа и перехода от непрерывнозначных показателей свойств
данных к дискретным);
− формирование поведенческих моделей объекта автоматизации
– задание вычислительных моделей (как интеллектуальных агентов) и их метасистем (коллективов агентов). Суть этапа поведенческого моделирования состоит в описании информационных процессов (динамики функционирования), происходящих в АС. Данный
этап опирается на такие понятия, как состояние системы, событие,
переход из одного состояния в другое, условия перехода, последовательность событий. Его реализация предполагает визуально-объектное представление знаний конечных пользователей (экспертов,
специалистов по эксплуатации объекта автоматизации), т. е. представления в виде модели, которая служит интерфейсом между человеком и вычислительной системой;
− проектирование и генерация графического пользовательского
интерфейса, предназначенного для организации диалога с пользователем и визуализации данных и результатов функционирования;
− автоматический синтез корректной метапрограммы для ее реализации в сетевой среде проектируемой АС. На этом этапе выполняется комплексная
− автоматическая верификация всех введенных данных и синтезируется максимально параллельная программа мониторинга
и управления вычислениями на языке внутреннего представления.
За счет наличия итерационного сквозного режима проектирования достигаются максимальное взаимодействие не только конечных пользователей, но и всех участников проекта, комплексирование (учет) их знаний и интересов. Кроме того, за счет совмещения во
времени большинства проектных работ обеспечивается минимизация сроков получения конечного продукта.
47
Главным достоинством проектирования АС, в соответствии
с представленной сквозной итерационной схемой, является возможность непосредственно в ходе разработки оперативно выявлять
и уточнять, а затем и реализовывать необходимый набор функциональных модулей создаваемого прикладного ПО.
Кроме того, обеспечивается возможность тиражирования программных решений, а также существенно упрощается процесс сопровождения и доработки (развития) созданного прикладного ПО.
Предлагаемая технология и инструментальные средства автоматизированной разработки ПО включают в свой состав комплекс
программных, лингвистических и логико-математических средств
для реализации следующих задач:
− интерпретация данных. Под интерпретацией понимается процесс определения смысла данных, результаты которого должны
быть согласованными и корректными. Обычно предусматривается
многовариантный анализ данных;
− классификация данных. Под классификацией понимается
процесс соотношения объекта с некоторым классом объектов и/или
обнаружение характерных отличий между объектами в некоторой
системе с построением упорядоченного по некоторому принципу
множества объектов, которые имеют сходные классификационные
признаки (свойства);
− оценивание. Основная задача оценивания – непрерывная интерпретация данных, систематизированное исследование ситуации, процесса, результатов с целью формирования набора альтернатив для принятия решений и прогнозирования;
− поддержка принятия решений по результатам оценивания состояния объекта. Поддержка принятия решения – это совокупность процедур, обеспечивающая лицо, принимающее решения, необходимой
информацией и рекомендациями, облегчающими процесс принятия
ответственных решения на основе выбора нужной альтернативы;
− прогнозирование. Прогнозирование позволяет предсказывать
последствия некоторых событий или явлений на основании анализа
имеющихся данных. Прогнозирующие системы логически выводят
вероятные следствия из заданных ситуаций. В прогнозирующей
системе обычно используется параметрическая динамическая модель, в которой значения параметров «подгоняются» под заданную
ситуацию. Выводимые из этой модели следствия составляют основу
для прогнозов с вероятностными оценками.
При формировании требований и разработке ПО АС, необходимо
проводить ряд исследований, включающих элементы сравнения,
48
типизации, классификации, обобщения, абстрагирования, повторения. Такого рода исследования представляют собой интеллектуальный анализ данных, состоящий из следующих этапов:
− анализ предметной области;
− постановка задачи;
− подготовка данных;
− построение моделей;
− проверка и оценка моделей;
− выбор модели;
− применение модели;
− коррекция и обновление модели.
Рассмотрим подходы к моделированию предметной области АС
при разработке программного обеспечения.
В основе проектирования прикладных аспектов АС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект АС в виде системы правильно
работающих программ, необходимо иметь целостное, системное
представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью
предметной области понимается некоторая система, имитирующая
структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой
области.
К моделям предметных областей предъявляются следующие
требования:
− формализация, обеспечивающая однозначное описание структуры предметной области;
− понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
− реализуемость, подразумевающая наличие средств физической реализации модели предметной области в создаваемом ПО;
− обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.
Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный
аспекты функционирования предметной области.
Структурный аспект предполагает построение:
− объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
49
− функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
− структуры управления, отражающей события и правила, которые воздействуют на выполнение процессов;
− организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
− технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств АС.
Для структурного аспекта моделей предметных областей основными элементами являются формы представления/отображения
и выбор языка представления проектных решений. Для отображения в основном используются графические методы, призванные
обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации.
Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет
собой совокупность графических объектов, используемых в модели.
Нотация является синтаксисом языка моделирования.
Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемого ПО АС.
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:
− время решения задач;
− стоимостные затраты на обработку данных;
− надежность процессов;
− косвенные показатели эффективности, такие как интенсивность входных потоков данных, скорость обработки и адекватность
принятия решений и т.д.
В основе различных методологий моделирования предметной
области лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях:
− на внешнем уровне (определении требований: что должна делать система);
− на концептуальном уровне (спецификации требований: как
должна функционировать система);
− на внутреннем уровне (реализации требований: с помощью
каких программно-технических средств реализуются требования
к системе).
50
С позиции жизненного цикла создаваемого ПО АС, описанные
выше уровни моделей соответственно строятся на этапах анализа
требований, логического (технического) и физического (рабочего)
проектирования. При этом выделяют следующие типы структурного моделирования: объектное, функциональное, управленческое,
организационное, техническое. Рассмотрим особенности структурного подхода к построению моделей предметной области на трех
уровнях детализации.
Объектная структура
Объект – это сущность, которая используется при выполнении
некоторой функции или операции (преобразования, обработки,
формирования и т.д.). Объекты могут иметь динамическую или статическую природу.
На внешнем уровне детализации модели выделяются основные
виды материальных объектов и основные виды информационных
объектов или документов.
На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты
и взаимосвязи. Таким образом строится обобщенное представление
структуры предметной области.
На внутреннем уровне концептуальная модель отображается
в виде данных базы знаний, файлов базы данных, входных и выходных документов (справочники, классификаторы и т.д.).
Функциональная структура
Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет прикладной процесс обработки, который может порождать объекты любой
природы (информационные, материальные и пр.). Функция может
быть представлена одним действием или некоторой совокупностью
действий.
На внешнем уровне моделирования определяется список основных функций или видов процессов обработки.
На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций.
На внутреннем уровне отображается структура информационного процесса: определяются иерархические структуры программных
модулей, реализующих автоматизируемые функции.
Структура управления
В зависимости от различных условий протекания процесса формируются определенные состояний объектов, связанные с насту51
плением событий. События вызывают выполнение функций, которые, в свою очередь, изменяют состояния объектов и формируют
новые события, и т.д., пока не будет завершен некоторый процесс.
Последовательность событий составляет конкретную реализацию
процесса обработки.
Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде
некоторого сообщения, фиксирующего факт выполнения некоторой
функции изменения состояния или появления нового. Процедурно
событие вызывает выполнение новой функции, и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. Таким образом, события выступают в связующей роли для выполнения функций процессов обработки.
На внешнем уровне определяются список внешних событий, вызываемых взаимодействием объектов предметной области с внешней средой, и список целевых установок, которым должны соответствовать процессы обработки.
На концептуальном уровне устанавливается набор правил, определяющих условия вызова функций при возникновении событий
и достижении состояний объектов.
На внутреннем уровне выполняется формализация этих правил
в виде триггеров или вызовов программных модулей.
Организационная структура.
Организационная структура представляет собой совокупность
организационных единиц, как правило, связанных иерархическими и процессными отношениями. Организационная единица – это
объект, представляющее собой объединение некоторых показателей, характеристик и ресурсов для выполнения совокупности общих функций или бизнес-процессов. В функционально-ориентированной организационной структуре организационная единица
выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор
функций, входящих в один тип процесса и относящихся к разным
функциям управления.
На внешнем уровне строится структурная модель объекта автоматизации в виде иерархии подчинения организационных единиц
или списков взаимодействующих объектов.
На концептуальном уровне для каждого объекта определяется его внутренняя структура (функционал и роль отдельных
элементов).
52
На внутреннем уровне определяются механизмы выполнения,
взаимодействия и доступа к вычислительным и информационным
ресурсам системы.
Техническая структура.
Топология определяет варианты размещение технических
средств обработки и анализа данных, а коммуникация – технический способ реализации взаимодействия .
На внешнем уровне модели определяются типы технических
средств обработки данных и их размещение.
На концептуальном уровне определяется способы коммуникаций между техническими комплексами.
На внутреннем уровне строится модель архитектуры вычислительной сети.
Для правильного отображения взаимодействий компонентов
создаваемого ПО АС важно осуществлять их совместное моделирование, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно
помогает в решении таких задач.
Структурным анализом принято называть метод исследования
системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней.
Ключевыми понятиями структурного анализа являются:
Операция – элементарное (неделимое) действие.
Функция – совокупность операций, сгруппированных по определенному признаку.
Процесс — связанная совокупность функций, в ходе выполнения которых потребляются определенные ресурсы и реализуются
поставленные задачи.
Подпроцесс – это процесс, являющийся структурным элементом
некоторого процесса и реализующий набор подзадач.
Модель – структурированное описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или
предполагаемую деятельность объекта автоматизации.
Рассмотрим методологии структурного моделирования предметной области.
Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функционально-ориентированные и объектно-ориентированные методологии.
53
Функциональные методики рассматривают моделируемую систему как набор функций, преобразующих поступающий поток информации в выходной поток. Процесс преобразования информации
потребляет определенные ресурсы. Основное отличие от объектной
методики заключается в четком отделении функций (методов обработки данных) от самих данных.
Объектные методики рассматривают моделируемую функциональную систему как набор взаимодействующих объектов – единиц
(элементов) анализа. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих функциональную систему, и распределение
между ними ответственностей за выполняемые действия.
Несомненным достоинством функциональных моделей является
реализация структурного подхода к проектированию по принципу
«сверху-вниз», когда каждый функциональный блок может быть
декомпозирован на множество подфункций и т.д., выполняя, таким
образом, модульное проектирование ПО АС. Для функциональных
моделей характерны процедурная строгость декомпозиции и наглядность представления.
При функциональном подходе объектные модели данных в виде
ER-диаграмм «объект – свойство – связь» разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.
Главный недостаток функциональных моделей заключается
в том, что процессы и данные существуют отдельно друг от друга –
помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия
выполнения процессов обработки информации, которые динамически могут изменяться.
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором
функций, которые могут обращаться к атрибутам этого класса.
Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств)
объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов).
В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), кото54
рые отличаются для определенных подклассов ситуаций. Это дает
возможность обращаться к подобным программным модулям по
общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных
систем к изменению предметной области по сравнению с функциональным подходом значительно выше.
При объектно-ориентированном подходе изменяется и принцип
проектирования. Сначала выделяются классы объектов, а далее
в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные
процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы.
55
3. ОПИСАНИЕ И ОБОСНОВАНИЕ
ВЫБРАННОЙ КОНСТРУКЦИИ
3.1. Функциональная структура модели СОТОП
Функциональная структура модели СОТОП включает следующее подсистемы:
1) информационные ресурсы:
− информационные ресурсы поставщиков информации;
− информационные ресурсы потребителей информации;
2) прикладные подсистемы:
− подсистема сбора (интеграции) данных;
− подсистема централизованного хранения данных;
− подсистема управления данными:
− подсистема предоставления доступа к данным;
− подсистемы аналитической отчётности.
3) платформенные решения:
− программная платформа управления электронными фондами;
− программная платформа управления данными, формируемыми АСУ;
4) подсистема обеспечения информационной безопасности;
5) подсистема администрирования;
Участники кооперации в процессе информационного взаимодействия одновременно выступают и в роли поставщиков, и в роли потребителей данных, предоставляя доступ к части своих информационных ресурсов, интегрированных в модели СОТОП, всем участникам информационного взаимодействия – в соответствии с их ролями и полномочиями.
Поставщики информации – автоматизированные системы (комплексы), системы электронного документооборота, электронные
фонды (архивы), базы данных, файловые хранилища предприятий
и организаций, располагающих данными, необходимыми для предоставления Потребителю в рамках обмена информации с использованием средств модели СОТОП.
Потребители информации – предприятия и организации, использующие данные в рамках основной деятельности и запрашивающие их у других.
Достоверность предоставляемой информации обеспечивается
каждым из поставщиков информации в рамках его зоны ответственности. При этом функциональные решения модели СОТОП
должны обеспечивать прием запросов, безошибочную маршрутиза56
цию и оперативную, неискаженную передачу информации между
потребителями и поставщиками.
Подсистема обеспечения информационной безопасности решает
следующие основные задачи:
− предотвращение утечки информации по техническим каналам;
− предотвращение несанкционированного уничтожения, искажения, копирования, блокирования информации;
− соблюдение правового режима использования массивов, программ обработки информации, обеспечения полноты, целостности,
достоверности информации в системах обработки;
− сохранение возможности управления процессом обработки
и использования информации в условиях несанкционированных
воздействий на защищаемую информацию.
Прикладные подсистемы автоматизируют ключевые процессы
управления данными модели СОТОП.
Подсистема сбора (интеграции) данных осуществляет:
− интеграцию информационных ресурсов с применением единых технологий, форматов, протоколов информационного взаимодействия;
− проверку (верификацию) поступающего информационного
контента;
− работу с метаданными интегрируемых информационных ресурсов;
− преобразование специфичных для интегрируемых систем протоколов информационного обмена в модели информационного взаимодействия;
− поддержку режима функционирования в реальном масштабе
времени при информационном взаимодействии с АСУ;
− трансляцию информационных потоков АСУ потребителям;
Подсистема централизованного хранения данных обеспечивает:
− размещение, использование и управление консолидированными информационными ресурсами системы;
− накопление и хранение больших массивов данных об изделии
(предоставленных поставщиками) на всех стадиях жизненного
цикла;
− высокопроизводительную обработку, надёжный и гарантированный доступ к данным;
− поддержку технологии формирования единой интегрированной модели;
− согласование и объединение данных нескольких информационных ресурсов;
57
− организационное и информационное взаимодействие унифицированных программных платформ посредством интерфейсов ЭСИ.
Подсистема управления данными реализует следующие функции:
− управление базами данных, файловыми хранилищами (развёртывание, обслуживание, резервирование, восстановление, предоставление доступа к данным);
− контроль статистики доступа, характеристик производительности;
− управление метаданными описывающими форматы/ структуры интегрируемых информационных ресурсов;
− управление единой интегрированной моделью;
− управление (координация) сервисами унифицированных программных платформ;
− взаимодействие с подсистемой аналитической отчётности.
Подсистема предоставления доступа к данным обеспечивает:
− управление процессами и сервисами, посредством которых потребители получают необходимый информационный контент;
− преобразование данных к заданным форматам (в соответствии
с поддерживаемыми моделями данных);
− организацию поисковых сервисов и процедур;
− визуализацию данных с использованием 2D и 3D мнемосхем,
посредством сервисов электронного каталога архивных фондов, интерфейсов электронной структуры изделия;
− поддержку интерфейсов (модулей) расширения из состава программных платформ, позволяющих подключать новые форматы
данных, проводить обработку информации, обеспечивая, тем самым, открытость функциональных решений модели СОТОП.
Подсистема аналитической отчётности позволяет:
− предоставлять информацию, хранящуюся в централизованном хранилище в различных разрезах с целью поддержки принятия управленческих решений и формирования необходимых отчётных документов и протоколов;
− проводить совместный анализ и оценку телеметрической информации, используя электронный архив пусковых кампаний РН,
генерировать табличные и графические отчётные документы;
− обеспечивать информационно-аналитическую поддержку принятия решений.
Подсистема администрирования решает задачи:
− управления доступом пользователей к информационным ресурсам в соответствии с установленными ролями и полномочиями,
на основе единых принципов идентификации, аутентификации;
58
− управления обновлениями;
− управления и координации служб и сервисов;
− управления функционированием системы в целом и её составными частями;
− мониторинга, оценки активностей, системных показателей,
характеристик.
Платформенные решения обеспечивают прикладные подсистемы сервисами информационного обмена, доступа к документам
электронных фондов и информационным ресурсам АСУ различного
уровня.
Программная платформа управления электронными фондами
реализует следующий набор функций [18]:
− консолидацию электронных документов различных информационных систем на основе единой методологии и единой интегрированной модели данных;
− импорт/экспорт пакетов электронных документов;
− возможность подключения новых информационных ресурсов
с помощью настраиваемых расширений;
− организацию гарантированного, защищённого хранения и доступа к данным архива электронных документов;
− комплектование и управление архивными фондами;
− взаимодействие с электронным контентом посредством интерфейсов электронной структуры, жизненного цикла изделия, а также предметно-ориентированных разделов электронного каталога
архивного фонда;
− контроль качества, актуальности и достоверности электронных документов;
− предоставление универсального инструмента визуализации
данных;
− организацию развитой системы поиска по содержимому электронных фондов.
На базе программной платформы управления электронными
фондами реализован комплекс программных компонент электронного архива долговременного хранения данных.
Программная платформа управления данными, формируемыми АСУ модели СОТОП, реализует следующий набор основных
функций:
− организацию сервисов сбора, обработки, анализа данных,
формируемых средствами АСУ модели СОТОП и информационноуправляющих систем космодрома, на базе концепции единой операционной среды с использованием унифицированных програм59
мных и аппаратных средств, интерфейсов, форматов данных и протоколов;
− взаимодействие с единой информационной средой космодрома
на базе реляционных, не реляционных (NonSql) и распределённых
баз данных;
− интеграцию данных АСУ в единое информационное пространство модели СОТОП;
− организацию и поддержку технологий доступа к ресурсам информационной среды на основе предметно-ориентированных онтологических спецификаций;
− поддержку методологий интеллектуально интерфейса и интеллектуальной обработки информации на основе полимодельных комплексов и адаптивных алгоритмов;
− организацию работы со знаниями (формирование экспертных
баз знаний, интерпретация, поддержка принятия решений);
− обработку разнородной информации в реальном масштабе времени.
Универсальные программные платформы реализуют идеологию
сервис-ориентированной работы с данными, когда информационное
взаимодействие оперирует не данными в «чистом» виде, а информационными сервисами, соответствующими определённому функциональному процессу.
Сервис-ориентированная архитектура (Service-Oriented Architecture – SOA) понимается как парадигма организации и использования распределенного множества функций. В рамках УПП формируется набор (репозиторий) сервисов, предоставляемых функциональными подсистемами (сбор, доступ, управление данными,
аналитика, администрирование и пр.), который управляется и контролирует ядром модели СОТОП, реализующим логику информационного взаимодействия.
Совокупность прикладных сервисов УПП обеспечивающих поддержку основных функций модели СОТОП представлена на рис. 3.
ФХ – файловое хранилище.
ИР – информационные ресурсы.
Прикладные сервисы УПП управления электронными фондами
реализуют следующий набор функций:
− интеграция ИР – приём пакетов информации от поставщиков
ИР, предварительная обработка и загрузку данных в логические
разделы архивных фондов, обеспечивающих информационное взаимодействие с источниками комплектования;
60
Аналитическая
отчётность
Рис. 3. Прикладные сервисы УПП
− подготовка контента – объединение данных и документов
в комплекты документации и представление их в унифицированном формате для последующей передачи и загрузки в централизованное хранилище;
− оцифровка – объединение данных и документов в комплекты
документации и представление их в унифицированном формате для
последующей передачи и загрузки в централизованное хранилище;
− доступ, поиск, просмотр – использование консолидированных
ресурсов электронных фондов конечными пользователями, а также управление процессами доступа к информационному контену,
включая использование интерфейсов ЭСИ и навигацию по структуре электронного тематического каталога, поиск и просмотр документов, формирование отчетов;
61
− загрузка, хранение, учёт – координация функционирования
группы сервисов УПП, обработка и преобразование форматов данных, обеспечение взаимодействие с архивными средствами долговременного хранения (базам данных, файловыми хранилищам),
учет, систематизацию, хранение и использование данных и документов.
Прикладные сервисы УПП управления данными АСУ модели
СОТОП реализуют следующий набор функций:
− интеграция ИР – приём пакетов информации от поставщиков ИР, предварительную обработка, загрузку в единое хранилище данных и/или репликацию измерительной и технологической
информации АСУ модели СОТОП внешним абонентам (потребителям ИР);
− репликация данных РМВ – поддержка процедуры многопоточной репликации информации в реальном масштабе времени;
− аналитическая отчётность – информационно-аналитическая
поддержка принятия решений, формирование различных отчётных документов и протоколов на основе данных информационных
ресурсов;
− доступ, поиск, просмотр – использование консолидированных
ресурсов электронных фондов конечными пользователями с использование интерфейса ЭСИ, и модулей расширения;
− загрузка, хранение – координация функционирования группы
сервисов УПП, обеспечение взаимодействие с архивными средствами долговременного хранения (базам данных, файловыми хранилищам), загрузку и поддержку в актуальном состоянии электронной
структуры изделия.
3.2. Архитектура модели СОТОП
В соответствии с базовыми принципами построения модели СОТОП, наибольшую ценность представляют не сами по себе данные,
а комплексный подход к использованию информации при оценке технического состояния, уровня надёжности РН, а также при
принятии управленческих решений. Поэтому все архитектурные
решения главным образом направлены на предоставление возможностей пользователям гибко использовать весь арсенал доступных
средств в процессе работы с информацией. Модель СОТОП в таком
контексте рассматривается и как рабочая среда пользователя, и как
средство интеграции данных о РН на протяжении всего жизненного
цикла изделия.
62
На концептуальном уровне, модель СОТОП, выступая в роли
интеграционной шины и интеграционного посредника, не отвергает использование существующих автоматизированных систем,
а является дополнением к ним, расширяет ведомственную информационную среду, интегрируя её в единое информационное пространство.
Архитектура модели СОТОП поддерживает решение следующих
основных задач:
− обеспечение межведомственного информационного взаимодействия за счет применения эффективных технологий интеграции информационных ресурсов, повышения надежности, скорости и безопасности сервисов доступа к электронным архивным фондам;
− поддержку автоматизации процедур и регламентов обмена
данными в процессе информационного взаимодействия с использованием соответствующих сервисов и интерфейсов ЭСИ;
− использование единых принципов (стандартов, интерфейсов)
обеспечения взаимодействия между интегрируемыми информационными системами;
− обеспечение возможности независимого использования и развития ведомственных информационных систем и ресурсов (автоматизированных систем организаций и предприятий кооперации),
т.е. вне информационного пространства;
− обеспечение технологической возможности подключения существующих и вновь создаваемых автоматизированных систем
к информационной инфраструктуре модели СОТОП;
− повышение надёжности взаимодействия всех функциональных подсистем, посредство постоянного контроля за инфраструктурными сервисами и организации централизованного мониторинга и администрирования;
− обеспечение технологической независимости инфраструктуры
модели СОТОП и регламентов его работы от проводимых технических, административных, организационных и иных изменений
в подключённых информационных системах.
Автоматизированные системы представляют собой «организационно-технические системы, обеспечивающие выработку решений
на основе автоматизации информационных процессов в различных сферах деятельности или в их сочетании» [17]. В современных
международных стандартах (например, в стандарте IEEE 1471)
такой тип систем принято называть «software-intensive systems» («системами, интенсивно использующими программное обеспечение»),
что указывает на «существенное влияние программного обеспечения
63
(ПО), входящего в их состав, на проектирование, конструирование,
материализацию и эволюцию АС».
Проектирование архитектуры и включение её в процесс
разработки АС способствует:
− снижению стоимости разработки, за счёт улучшения
взаимодействия между разработчиками;
− открывает возможность более ранней оценки альтернатив и рисков;
− снижает время выхода на рынок, за счёт возможности повторного использования предыдущих решений;
− снижает стоимость сопровождения, за счёт объединения
в группы изменений, поддающихся предвидению;
− способствует улучшению качества продукта и приводит
к другим позитивным эффектам.
Выполнение функций моделью СОТОП, описанных п.п. 3.1, обеспечивается взаимосвязанной совокупностью архитектур (архитектурными представлениями) [25]:
− программного обеспечения;
− аппаратного (технического) обеспечения;
− информационное обеспечения.
Программное обеспечение представляет совокупность программ,
необходимых для реализации функций системы в целом, а также обеспечения функционирования технических средств модели
СОТОП (базовое, специальное, прикладное ПО).
Информационное обеспечение включает анализ источников информации, их характеристики, принципы формирования ЭСИ, регламенты интеграции данных и рассмотрено в разделе 3.3.
Кроме того, информационное обеспечение предусматривает анализ и оценку следующих аспектов:
− принципы и варианты построения связной инфраструктуры;
− процедуры и регламенты доступа к сетевым ресурсам;
− порядок формирования открытых и защищенных контуров
коммуникационной среды;
− обеспечение информационной безопасности.
Следует отметить, что в экспериментах проектирования рассматривались решения по построению двух видов моделей СОТОП
первого и второго уровня.
Разделение на уровни в рамках модели СОТОП обусловлено различными функциональными задачами, решаемыми в соответствии
с типом участника (источник или потребитель), масштаба организации участника (объем порождаемого информационного контента,
64
количество абонентов в организации, одновременно использующих
средства модели СОТОП), а также отличием их программно-аппаратного оснащения и, соответственно, вычислительными мощностями.
Кроме того, архитектура построения модели СОТОП (для расширения функциональности и обеспечения максимальной гибкости)
предусматривает возможность подключения потребителей информационных ресурсов по схемам «толстый клиент» и терминальный
доступ.
3.2.1. Модель СОТОП первого уровня
Модель СОТОП первого уровня является основным элементом
построения инфраструктуры единого информационного пространства и предназначен для организации эффективного, безопасного
и высоконадёжного хранения информации, управления консолидированными данными, своевременного обеспечения потребителей
актуальной информацией, необходимой для выполнения работ по
поддержанию требуемого уровня технического состояния и надежности РН и входящих в его состав изделий на всех этапах их жизненного цикла.
Вычислительная инфраструктура (набор взаимосвязанных
программных и аппаратных компонентов, организационных процедур, регламентов информационного взаимодействия) модели
СОТОП первого уровня предоставляет набор прикладных сервисов и средств их поддержки, реализующий следующие основные
функции:
− интеграция информационных ресурсов участников кооперации в рамках единого информационного пространства;
− организация консолидированного, долговременного, отказоустойчивого хранения данных на базе централизованного хранилища;
− управление процедурами учёта, комплектования, публикации, обслуживания электронными фондами документов и данных
объективного контроля (технологической, измерительной информации) по РН, формируемыми территориально-распределёнными
информационными системами предприятий (организации);
− предоставление доступа к консолидированным информационным ресурсам участникам информационного взаимодействия
в рамках единого информационного пространства в соответствии
с установленными регламентами и полномочиями.
65
Вычислительная инфраструктура модели СОТОП первого уровня предусматривает наличие:
1) серверного оборудования;
2) средств долговременного, высоконадёжного хранения данных;
3) автоматизированных рабочих мест:
− доступа к информационным ресурсам;
− комплектования и обслуживания архивных фондов электронных документов и данных объективного контроля (технологической, измерительной информации) по РН;
− оцифровки бумажной документации;
− администрирования.
3.2.2. Модель СОТОП второго уровня
Модель СОТОП второго уровня ориентирован в первую очередь
на решение задач интеграции всех электронных данных в рамках
информационной среды предприятия (организации), подготовки
консолидированного информационного контента и загрузки его
в централизованное хранилище модели СОТОП первого уровня.
Интеграция информационных ресурсов с использованием моделей СОТОП второго уровня обеспечивает возможность упорядочения электронных данных в организациях поставщиках ИР и накопления её во временных хранилищах.
Применение такой технологии позволяет:
− повысить качество и эффективность процессов интеграции данных;
− контролировать достоверность, актуальность и полноту предоставляемых в ЕИП информационных ресурсов предприятий и организаций;
− повысить ответственность за исполнение регламентов информационного взаимодействия и, как следствие, – надёжность функционирования всей системы в целом;
− совершенствовать процессы координации и управления информационными потоками на ведомственном уровне;
− существенно снизить нагрузку на инфраструктуру централизованного хранилища (комплект первого уровня).
Модель СОТОП второго уровня предусматривает сокращённый набор прикладных сервисов и реализует следующие основные функции:
− формирование наборов данных и документов, предназначенных к экспорту из информационных систем предприятия (организации);
66
− подготовка и стандартизация всех видов электронных документов и данных этих наборов;
− организация временного хранения сформированных наборов
для экспорта в модель СОТОП;
− передача (экспорт) на централизованное хранение (модель СОТОП первого уровня) и предоставления доступа к загруженной информации уполномоченным участникам информационного взаимодействия в рамках единого информационного пространства.
Вычислительная инфраструктура модели СОТОП второго уровня предусматривает наличие:
1) серверного оборудования (при необходимости);
2) средств долговременного, высоконадёжного хранения данных;
3) автоматизированных рабочих мест:
− доступа к информационным ресурсам;
− подготовки и загрузки информационного контента;
− оцифровки бумажной документации.
3.2.2.1. Варианты применения моделей СОТОП
На рис. 4 и 5 представлены варианты применения моделей СОТОП первого и второго уровней при организации информационного
взаимодействия.
Поставщики информации формируют комплекты данных
и электронной документов с помощью своих информационных сиЭлектронные
документы и данные
Рис. 4. Применение модели СОТОП первого уровня
при организации информационного взаимодействия
67
Рис. 5. Применение модели СОТОП второго уровня
при организации информационного взаимодействия
стем, интеграционных модулей, ПО оцифровки и подготовки контента, а затем передают их на загрузку в электронные архивные
фонды [18].
При этом предлагается два регламента информационного взаимодействия поставщика информационных ресурсов (ИР) и модели
СОТОП.
Первый регламент предусматривает наличие доступного из информационной системы поставщика ИР временного архива и наличие в нем логического раздела (папки), в которой поставщик ИР
размещает свой информационный контент.
После комплекса автоматизированных проверок (соответствие
требованиям к форматам, структуре, составу и содержанию полей
регистрационных карточек и т.п.) сформированные комплекты данных перемещаются во временный архив, размещенный на средствах
поставщика ИР, откуда уже с использованием сервисов интеграции
пакеты эскспортируемых ИР помещаются в централизованное архивное хранилище модели СОТОП первого уровня.
Второй регламент предусматривает экспорт непосредственно
в централизованное архивное хранилище, минуя временный архив.
Этот регламент, очевидно может использоваться в случаях, когда
поставщики информации обладают высокопроизводительными
вычислительными ресурсами и системами хранения данных, при
68
этом развертывание аппаратно-программных средств временного
архива оказывается экономически нецелесообразным.
На средствах комплекта первого уровня поступающая в централизованное хранилище информация не обрабатывается (не выполняются процедуры очистки, фильтрации и т.п.), а хранится «как
есть». Её содержание и комплектность не проверяются. Ответственность за корректность (полноту, актуальность, целостность) предоставляемой информации лежит на её поставщиках.
Завершающий этап предполагает публикацию информации. Под
публикацией подразумевается подтверждение завершения всех процедур обработки данных предусмотренных регламентом, их учёта,
принятия на хранение и предоставление публичного доступа с учётом принятой политикой безопасности (правами доступа).
Процедура пополнения электронных фондов модели СОТОП информационным контентом должна выполняться по утвержденному
регламенту и обеспечивать:
− предоставление только той информации, которая необходима
для загрузки в централизованное хранилище;
− информационную безопасность на всем маршруте движения
данных из информационных ресурсов поставщика в системы хранения данных комплектов второго и/или первого уровней;
− целостность и сохранность информации при ее передаче;
− согласованность и корректность форматов и форм представления информации.
Периодичность и объемы поступлений данных от поставщиков
информации на уровень централизованного (консолидированного)
хранения не регламентируются, но должны быть определены и согласованы. Возможна реализация трёх вариантов регламентов загрузки (комплектования) информационного контента в централизованное хранилище: периодического, эпизодического, по запросу.
3.2.3. Варианты построения архитектуры модели СОТОП
В рамках эскизного проекта рассматриваются два варианта архитектурного решения по построению информационной инфраструктуры модели СОТОП: распределённый и централизованный [18].
Распределенная архитектура состоит из одинаковых и равноправных узлов, в общем случае использующих полный комплекс
функциональных возможностей по комплектованию, хранению
и доступу к информационным ресурсам.
69
В такой архитектуре для каждого узла функциональная структура включает:
− подсистему сбора (интеграции) данных;
− подсистему управления данными;
− подсистему предоставления доступа к данным;
− подсистему аналитической отчётности;
− подсистему администрирования;
− подсистему обеспечения информационной безопасности;
− УПП управления электронными фондами;
− УПП управления данными АСУ.
Особенностями такого подхода являются:
− функциональная избыточность. Многим потребителям информационных ресурсов требуется лишь доступ по чтению к консолидированным данным, при этом в поддержке функционала комплектования, оцифровки, администрирования и пр. нет необходимости.
Решением может быть типизация узлов по составу и структуре решаемых задач, и, как следствие формирование нескольких унифицированных программно-аппаратных решений;
− сложность обеспечения надежности хранения и высокого уровня доступности данных. Чем больше количество узлов в системе,
тем выше вероятность отказа одного из них и, как следствие, недоступность части информационных ресурсов. В качестве одного из
вариантов решения мог бы рассматриваться подход, основанный на
асинхронной репликации данных между узлами. Однако его реализация потребует многократного увеличения ресурсов системы
и объемов хранения данных (пропорционально числу поставщиков
информации). Кроме того, катастрофоустойчивое решение по такой
схеме также предоставляется сомнительным с точки зрения эффективности и надёжности функционирования;
− сложность организации поисковых запросов, их маршрутизации;
− сложность управления условно-постоянно (нормативно-справочной) информацией;
− высокий уровень накладных расходов, в следствии избыточности функционала, нерациональное использование ресурсов (людских, программно-технических, сетевых);
− сложность подключения новых предприятий, организации.
Фактически необходимо применять полнофункциональные решения на каждом узле (комплекты первого уровня);
− сложность организации сопровождения, обновления ПО,
управления и администрирования системой в целом;
70
− сложность организации единой процедуры контроля доступа
к информации;
− необходимость функциональных и архитектурных решений по
поддержке механизмов «распределённости», обеспечения функционирования сложной системы информационного взаимодействия
и координации множества узлов.
Централизованная архитектура.
Централизованная архитектура строится на основе консолидированного цифрового хранилища данных и документов, представляющего собой совокупность баз данных и файловых хранилищ.
Для обеспечения сохранности данных (катастрофоустойчивость)
в такой архитектуре предусмотрены территориально удаленный от
основного резервный центр хранения данных и регламентированные сценарии репликации. Предлагается в качестве резервного центра использовать один из комплектов первого уровня, развернутый
в одной из организаций-участников.
Основные преимущества централизованной архитектуры:
− лучшая управляемость, возможность организации единой системы мониторинга и администрирования всей системы
− возможность масштабирования (увеличение вычислительных
мощностей, объёмов систем долговременного хранения);
− единые подходы к развитию функциональной и инфраструктурной составляющих;
− высокая надёжность, высокий уровень доступности информационных ресурсов;
− сокращение затрат на обслуживание и модернизацию;
− использование общих принципов и единых средств защиты информационных ресурсов;
− единая точка доступа к информационным ресурсам, простота
и оперативность подключения новых поставщиков и потребителей
информационных ресурсов (задача подключения, фактически сводится к регистрации новых пользователей в системе).
В ходе эскизного проектирования, опираясь на проведённый
анализ и макетирование двух вариантов реализации структуры
модели СОТОП, выбор был сделан в пользу построения централизованной архитектуры, как в наибольшей степени отвечающей требованиям технического задания по функциональным характеристикам, составу инфраструктурных элементов и надёжности.
71
3.3. Информационное взаимодействие
в модели СОТОП
Информационное взаимодействие – распространение (обмен) информационными ресурсами между предприятиями (организациями) кооперации на всех этапах жизненного цикла РН на основе соответствующих информационных технологий.
3.3.1. Жизненный цикл изделий
Жизненный цикл изделий – это совокупность взаимосвязанных
процессов последовательного изменения состояния изделий от формирования исходных требований к ним до снятия их с эксплуатации и списания.
Стадия жизненного цикла – часть ЖЦ, характеризующаяся совокупностью выполняемых работ и их конечными результатами.
Этап жизненного цикла – часть стадии ЖЦ, выделяемая по признакам моментов контроля (контрольных рубежей), в которые предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров
изделий.
Жизненный цикл РН состоит из нескольких стадий – разработка, подготовка производства, непосредственно производство, эксплуатация и сопровождение, а также утилизация. На каждом из
них формируется различная информация, характеризующая изделие и его составные части в тот или иной момент времени: конструкторская, программная и технологическая документация, данные
о технических неисправностях экземпляра изделия; результаты его
испытаний и пр. (см. п.п. 2.1.1).
Для информационной поддержки ЖЦ используют совокупность
методов и программно-технических средств (информационных технологий), обеспечивающих решение задач управления ЖЦ в рамках программ работ по изделию.
Основные задачи информационной поддержки ЖЦ включают:
создание и сопровождение интегрированных информационных моделей изделий и системы их технической эксплуатации при разработке, подготовке производства, использование созданных моделей
на этапах производства и на стадии эксплуатации (а при необходимости, и на стадии утилизации) для обеспечения и постоянного контроля характеристик на всех стадиях ЖЦ.
72
Указанные технологии применяются для информационной
поддержки ЖЦ конкретного экземпляра изделия на всех стадиях
и этапах ЖЦ.
В общем виде ЖЦ изделия можно разбить на следующие стадии:
− разработка технических требований и/или проектирование РН;
− материально-техническое снабжение;
− разработка и подготовка технологических процессов;
− производство;
− контроль, проведение обследований и испытаний;
− упаковка и хранение;
− транспортировка на площадки запуска;
− разгрузка.
− сборка на ТК;
− проверки, испытания и техническое обслуживание;
− использование по предназначению (эксплуатация).
− послепусковая утилизация элементов и частей.
При использовании модели СОТОП для организации процессов
интеграции, хранения и обмена актуальной информацией между
всеми участниками системы информации о РН, основным объектом, предоставляющим интерфейс доступа к консолидированным
данным об изделии на всех стадиях ЖЦ, является её электронная
структура – ЭСИ.
3.3.2. Электронная структура изделия
ЭСИ представляет собой «древовидную» структуру, содержащую
детали, сборочные единицы, комплекты и комплексы, образующие
состав изделия, а также ассоциированные с каждой такой составной частью информационные ресурсы – электронные данные, соответствующие стадиям ЖЦ изделия.
Электронные данные содержат всю необходимую информацию,
характеризующую этапы производства, испытания, обслуживания, эксплуатации изделия и представляют собой электронные
документы различных форматов, графические (2D и 3D) объекты,
файлы с результатами измерений и пр. (см. п.п. 2.1.1).
В соответствии с [15], ЭСИ – конструкторский документ, выполняемый только в электронной форме и предназначенный для использования в компьютерной среде.
ЭСИ является обобщающим документом, консолидирующим все
технические данные об изделии, и предназначена для организации
73
информационного взаимодействия между автоматизированными
системами.
Информационная интеграция, как основной процесс формирования ЕИП по РН, заключается в том, что все автоматизированные
системы, применяемые на различных стадиях ЖЦ, оперируют не
традиционными документами и файлами, а формализованными
информационными моделями.
Эти модели в электронной форме, в виде информационных объектов (ИО) создают и поддерживают в актуальном состоянии единое
электронное описание изделия. Системы, которые используют те или
иные информационные объекты, извлекают их из систем хранения
данных, обрабатывают, создавая новые объекты, и помещают в централизованное хранилище. Эти процессы непосредственно контролируются и управляются посредством интерфейсов ЭСИ, поскольку
каждый информационный объект или группа ИО на всех этапах своего жизненного цикла связаны с соответствующим элементом электронной структуры изделия, образуя содержательный контекст ЭОИ.
Информационный объект представляет совокупность данных,
обладающих атрибутами (свойствами) и методами, позволяющими
определённым образом обрабатывать данные.
Контекст – организационная совокупность элементов данных
и связей между ними, созданная в рамках информационной модели
для группирования и представления (в т.ч. визуального отображения) необходимого состава информации с определённой целью.
ЭСИ используется для:
− представления информации о составе изделия и об иерархии
основных составных частей;
− представления интегрированной разнотипной информации о
свойствах (характеристиках) изделия и его частей;
− представления информации о правилах применяемости и заменяемости (в том числе и взаимозаменяемости) частей;
− классификации и формирования обозначений изделия и его составных частей;
− управления разработкой изделия;
− документирования изменений в конструкцию изделия и его частей;
− получения текстовых документов на изделие и его части (детали, сборочные единицы, комплексы, комплекты) в электронной и/
или бумажной формах.
Использование электронной структуры изделия является одним
из основных технологических вопросов от решения которого зави74
сит удобство работы с системой ее функциональная привлекательность, «дружественность» по отношению к пользователям информационных ресурсов СОТОП.
Формирование ЭСИ по конструкторским документам, выполненным с помощью САПР или PDM – систем, является одной из функций этих систем и используется при создании электронной структуры изделия. Так разработаны методики построение ЭСИ с использование стандартных средств PDM Windchill:
− ЭСИ создаётся конструктором ручным способом;
− ЭСИ создаётся конструктором в автоматизированном режиме из электронной модели сборки, разработанной в системе Creo
Elements/Pro(Pro/ENGINEER).
ЭСИ является основной единицей хранения данных об изделии
и создаётся на основе трех объектов PDM Windchill – «Документ»,
«CAD-Документ» и «Деталь» – имеющая два представления. Конструктивное представление (Design) содержит состав и документацию на изделие, разработанную сотрудниками тематического
и конструкторского подразделения. Другое представление – технологическое (Manufacturing) формируется на основе первого представления и содержит данные об изделии, разработанные сотрудниками технологического подразделения предприятия. Следует отметить, что они могут изменяться независимо друг от друга, сохраняя
при этом информационную связь между собой.
На основе ЭСИ в PLM Windchill формируются объекты «Конфигурация изделия» и «Экземпляр изделия».
Многообразие электронных документов, моделей сборок в составе которых зачастую определены не все части, входящие в конструкторские спецификации, а также сложность или отсутствие механизмов координации процесса формирования единой (интегрированной) ЭСИ в процессе проектирования ЭСИ составных частей
изделия группой разработчиков, вынуждает искать новые (более
простые и технологичные) подходы к построению консолидированной электронной структуры изделия (конструктивной и функциональной).
При этом, основной целью таких разработок является необходимость создания унифицированного описания (внутреннего стандарта) ЭСИ для использования прикладными сервисами СОТОП, поддержания процедур версионирования ЭСИ и синхронизации между
программными компонентами СОТОП.
Кроме того, формируемые промышленными автоматизированными системами ЭСИ доступны только программным модулям,
75
разработанным конкретным производителем, и в целях интеграции их в АС других производителей, потребуются серьёзные доработки.
В рамках эскизного проекта рассматриваются две основные разновидности ЭСИ: конструктивная и функциональная.
Конструктивная ЭСИ предназначена для отображения конкретных технических решений, определяющих конструкцию комплексов, сборочных единиц и комплектов.
Функциональная ЭСИ предназначена для определения назначения изделия и его составных частей.
Поскольку ЭСИ предусматривает активное взаимодействие с интерфейсами, предоставляемыми 3D моделями изделия, на этапе
создания ЭСИ должны использоваться описания и спецификации
3D моделей (их степень детализации, связь с конструкторскими
спецификациями, структуры, иерархия, состав 3D примитивов,
среды разработки, поддерживаемые 3D движки, предоставляемые
интерфейсы и пр.).
На этапе эскизного проекта предусмотрено формирование 3D модели изделия в формате 3ds.
Исходными данными для формирования ЭСИ различного назначения является состав изделия, приведенный в конструкторских
спецификациях, а также правила классификации и кодирования
составных частей изделия и документации.
Технология формирования конструктивной ЭСИ основывается
на использовании промежуточных файлов состава изделия, сформированных на основе конструкторской документации, с указанием уровня вхождения (иерархии) составных частей и включает следующие этапы:
1) формирование электронного описания ЭСИ с использованием
пакета LibreOffice (ods файлы). Электронный документ представляет совокупность служебных данных и информации о структуре и иерархии составных частей электронной структуры изделия,
оформленные в виде набора страниц. Первая страница документа
(служебная) содержит перечень определений, базовых элементов
кодификации составных частей и функциональных модулей изделия, а также ссылки на соответствующие XML файлы ЭСИ (рис. 6).
Вторая (информационная) – формализует структуру и иерархию СЧ
ЭСИ РН (рис. 7).
2) насыщение (дополнение, корректировка) конструктивной ЭСИ
контекстом, связанным с конструкторской документацией. Представление информации о ЭСИ предполагает формирование следую76
14А14-1а.К.02
14А14-1а.К.02.0001
14А14-1а.К.02.0002
14А14-1а.К.02.0003
Рис. 6. Автогенерация содержимого элементов колонки «Код»
составной части изделия
Рис. 7. Единый XML-файл описания ЭСИ изделия
77
щих данных по каждой функциональной системе и составной части
изделия:
− код уровня иерархии ЭСИ;
− код ЭСИ;
− обозначение составной части или системы;
− наименование составной части или системы;
3) расширенный формат предполагает дополнительный информационный контент по составным частям ЭСИ – атрибутику соответствующей конструкторской и эксплуатационной документации:
− наименование конструкторского документа;
− обозначение конструкторского документа;
− тип формата документа;
− наименование и размещение соответствующего файла;
− выполнение процедуры автоматической кодификации составных частей изделия с использованием макроса кодогенерации (смотри рис. 6) и в соответствии с шаблоном: «Индекс изделия. Код функционального модуля. Код конструктивного элемента. Иерархия…»
4) построение единого контекста ЭСИ, с включением созданных
модулей описания основных составных частей изделия (рис. 7).
Сформированный сводный контекст ЭСИ (обменный Xml файл)
предназначен для загрузки электронной структуры изделия в комплекс программных компонент электронного архива долговременного хранения данных СОТОП и используется как элемент навигации, комплектования и доступа к информации СОТОП для всех
организаций и подразделений кооперации.
Средства поддержки интерфейса электронной структуры изделия в рамках СОТОП реализуют следующие функции:
− обеспечение полноты и актуальности ЭСИ изделия;
− обеспечение процедур согласования ЭСИ с конструкторскими
спецификациями на изделие и данными, формируемыми АС предприятия изготовителя;
− обеспечение регламента проведения изменений ЭСИ;
− обеспечение управления конфигурацией и составом электронных фондов посредством ЭСИ;
− обеспечение преобразования информации, получаемой из различных источников во внутренний формат данных СОТОП (ЭОИ)
и привязка электронного контента к ЭСИ;
− организация доступа к информационным ресурсам СОТОП посредством интерфейсов ЭСИ;
− возможность параллельного (многопользовательского) доступа
к ресурсам;
78
79
Рис. 8. Фрагмент ЭСИ в структуре электронного каталога
− поддержка регламентов информационного взаимодействия
с использованием механизмов, предоставляемых ЭСИ;
− контроль процессов формирования модели СОТОП и её полноты.
На рис. 8 представлен фрагмент ЭСИ РН в структуре электронного каталога управления информационными ресурсами.
3.3.3. Реализация информационного взаимодействия в СОТОП
Организация информационного взаимодействия в модели СОТОП рассматривается на примере информационных сред двух основных поставщиков-потребителей консолидированных данных
Рис. 9. Инфраструктура двух основных поставщиков-потребителей
в контексте информационного взаимодействия в модели СОТОП
80
о функционировании РН (как объекта информации) на всех этапах ЖЦ. На рис. 9 представлена информационная инфраструктура
двух основных поставщиков-потребителей в контексте информационного взаимодействия.
Информационная среда представляет собой комбинацию автоматизированных информационных систем различного функционального назначения, формируемых (используемых) ими информационных ресурсов, а также процедур и регламентов информационного
взаимодействия.
Регламент взаимодействия информационных систем определяет
правила, порядок и основные процедуры, связанные с процессами
приёма и передачи информации в электронной форме по телекоммуникационным каналам связи между информационными системами.
Формирование регламента взаимодействия (регламента интеграции) необходимо для четкого определения ответственности
участников при обеспечении взаимодействия, перечня информационных объектов, расписания и способов организации взаимодействия.
3.3.3.1. Информационная среда
первого поставщика-потребителя
Например, инфраструктура информационной среды первого поставщика-потребителя может быть сформирована на основе следующих функциональных объектов (подсистем) [21]:
− электронный архив технической и нормативной документации;
− электронный документооборот технической и нормативной документации;
− единая среда проектирования изделий и их составных частей;
− единая среда управления структурой изделия и его составных
частей;
− единая среда поддержки ЖЦ изделия на стадиях разработки,
проектирования и производства.
Реализация системной платформа информационной среды основывается на решениях Microsoft и технологиях виртуализации серверной инфраструктуры и десктопов (VMware), системы хранения
данных, системы передачи данных и приложений (CitrixXenApp).
Электронный архив построен с использование модуля ЛОЦМАН
Архив (приложение к системе ЛОЦМАН:PLM).
81
Система электронного документооборота на предприятии в полной мере реализуется средствами Windchill, и поддерживает следующий набор функций:
− классификацию и хранение документов с возможностью разграничения прав доступа;
− проведение изменений и их согласование в электронном виде;
− поиск документов по атрибутам и содержанию;
− взаимодействие с системой автоматизированного проектирования CreoElements/Pro(Pro/Engineer) и многое другое.
Единая среда проектирования изделий и их составных частей
представлена:
− базовой системой САПР CreoElements/Pro (Pro/Engineer);
− САПР Компас-3D;
− САПР Altium Designer (проектирование радиоэлектронных
средств);
− САПР технологической подготовки производств (ТПП) ВЕРТИКАЛЬ (в основном используется для разрабатки технологических процессов и глубоко интегрирована с Windchill);
− Mathcad, Matlab.
Кроме того, для создания технических публикаций и руководств, ассоциативно связанных с моделями изделия используется
инструменты Arbortext.
Единая среда управления структурой изделия и его составных
частей основана на использовании Windchill PDMLink в качестве
системы управления инженерными данными. Система Windchill
PDMLink является центральным звеном информационной среды
предприятия. На Windchill PDMLink замыкаются все проектные
проработки, разработка, коррекция КД, управление конструкторским составом изделия, результаты инженерного анализа, технологический состав изделия, расцеховки, данные по ТПП (технологические процессы, ведомости оснащения, маршрутные карты и т.д.).
Единая среда поддержки ЖЦ изделия на стадиях разработки,
проектирования и производства опирается на сконцентрированную
в Windchill систематизированную информацию и является основой
для функционирования ERP-системы предприятия, в которой потоки конструкторско-технологических данных трансформируются
в задачи управления ресурсами предприятия.
Одним из основных типов документации, циркулирующей в информационной среде предприятия, является рабочая конструкторская документация (РКД).
82
РКД формирует значительную часть информационного ресурса –
набор электронных документов, основной перечень которых представлен в табл. 1.
Таблица 1
Код документа
Вид документа
ПЗ
Пояснительная записка
ТЗ
Техническое задание
ТО
Технический отчёт
ТД
Техническое задание на доработку
ТУ
Технические условия
ТР
Техническое решение
ФО
Формуляр
ПС
Паспорт
ИЭ
Инструкция по эксплуатации
ОИ
Инструкция по испытаниям
ДС
Сводная ведомость эксплуатационных документов
ВЭ
Ведомость эксплуатационных документов
ВС
Ведомость спецификаций
РО
Расчёт общий
Р01…10
Расчёт параметров системы
С1..10
Схема размещения
Э1...10
Схема электрическая
ПЭЧ
Перечень элементов
ДЖР
Журнал учёта работ
ДИЗ
Инструкция по испытаниям ЗИП
ДНО
Ведомость наземного оборудования
ДПМ
Программа телеизмерений
ДФГ
Формуляр группового комплекта
Е1
Схема деления
ВП
Ведомость покупных
ИО
Инструкция по тех. обслуживанию
ПМ
Программа и методика испытаний
83
Каждый документ в системе может быть представлен как в виде
единого многостраничного документа, так и набором его страниц.
Для представления используются как файлы-документы, являющиеся первоисточниками, так и сканированные файлы (образы),
например:
− DOC;
− DWG;
− PDF;
− TIFF;
− XLS;
− XML;
− RAR,ZIP и др.
Для сохранения отсканированных изображений используются
сжатые форматы файлов:
− для цветного и серого (полутонового) изображения – TIFF
с LZW компрессией;
− для черно-белого – TIFF с G4 компрессией.
После сканирования и проверки качества полученных изображений, все объекты оцифровки (формата TIFF) как правило конвертируются в единый файл PDF с разрешением 300 dpi.
Кроме того, в системе предусмотрено использование:
− выходных данных устройств, оборудования, протоколов информационных систем и т.п., представленных в виде файлов тестовых форматов;
− результатов видеофиксации выполнения технологических операций и процессов, данных систем видеонаблюдения в исходных
форматах.
Рассмотрены два регламента взаимодействия информационных
систем предприятия и модели СОТОП, использующие следующие
источники комплектования:
− пакеты экспорта, формируемые автоматизированными системами;
− файлы или каталоги файлов, представляющих комплекты
электронных документов с организационно-технической и технологической информацией (см п.п. 2.1.1).
Процедуры интеграции отсканированных электронных документов (при переводе бумажных архивных фондов предприятий
и организаций в цифровой вид) в модели СОТОП, после формирования комплектов экспорта, аналогичны регламенту информационного взаимодействия на основе файловых каталогов.
84
Первый регламент реализует процедуру интеграции данных
с PDM-системы Windchill (на основе пакетов экспорта) и предполагает следующую последовательность:
− комплект документации по составной части изделия в виде
пакета экспорта PDM-системы Windchill и его метаданных в согласованном формате выгружается из информационной системы предприятия;
− выгрузка производится на промежуточный сервер в согласованную структуру папок общего доступа. Может быть использован
выделенный виртуальный сервер в структуре предприятия;
− при использовании виртуального сервера предприятия процедура интеграции данных реализуется на средствах модели СОТОП
первого уровня. Пакет экспорта переносится (загружается) в логический раздел электронного каталога архива, предоставляющего
программные сервисы для работы с внешними данными. Выполняется разбор данных и метаданных пакета экспорта и конвертация
информации в XML файл. Обменный XML файл содержит описание выгруженных данных, их структуру, иерархию, взаимосвязи,
а также ссылки на файлы электронных документов. На следующем
этапе происходит загрузка (импорт), разбор и конвертация XML
данных, формирование электронного каталога архивного фонда (в
соответствии со структурой и иерархией импортируемых объектов),
заполнение регистрационных карточек, привязка документации
к ЭСИ и стадиям ЖЦ.
− при использовании варианта интеграции с использованием
промежуточного архива (модели СОТОП второго уровня), порядок
взаимодействия соответствует описанному ранее, за исключением:
подготовленный комплект документов и данных переноситься со
второго уровня на первый, в централизованное хранилище.
− при положительных результатах обработки данных пакета
импорта, выполняются публикация загруженного контента и процедура очистки содержимого папок общего доступа на промежуточном сервере.
Фрагмент данных из состава пакета импорта PDM-системы
Windchill интегрированных представлены на рис. 10.
Обменные XML файлы сохраняются в архиве модели СОТОП,
что обеспечивает возможность передачи пакетов данных повторно,
в случаях повреждения файлов или их утраты.
Каждая операция экспорта и импорта данных сопровождается
протоколированием списка передаваемых объектов, подробным
описанием выполняемых операций и сообщениями об ошибках.
85
86
Рис. 10. Данные пакета PDM-системы Windchill импортированныесодель СОТОП
Второй регламент рассмотрен на примере интеграции комплектов электронных документов с организационно-технической и технологической информацией и предполагает следующую последовательность:
− комплект документации в виде согласованной логической
структуры файловых каталогов выгружается из информационной
системы предприятия;
− выгрузка производится на промежуточный сервер в согласованную структуру папок общего доступа. Может быть использован
выделенный виртуальный сервер в структуре предприятия, либо,
модель СОТОП второго уровня (при наличии);
− обращение к папкам общего доступа и выполнение процедуры
импорта файлового каталога с документацией. В централизованном
хранилище модели СОТОП первого уровня создаётся электронный
каталог соответствующей структуры. Далее проводится процедура
комплектования, предусматривающая заполнение регистрационных карточек (атрибутирование), привязка документации к ЭСИ
и стадиям ЖЦ;
− при использовании варианта интеграции с использованием
промежуточного архива (модель СОТОП второго уровня), порядок
взаимодействия соответствует описанному ранее, за исключением:
подготовленный комплект документов и данных переноситься со
второго уровня на первый, в централизованное хранилище;
− при положительных результатах обработки набора данных
импорта, выполняются публикация загруженного контента и процедура очистки содержимого папок общего доступа на промежуточном сервере.
Пример комплекта электронной документации на изделие, импортированной в модель СОТОП, представлен на рис. 11.
Процедура интеграции согласованного информационного контента, обеспечивает выгрузку данных и документов комплектно.
При этом данные и документы комплекта должны относиться к одной составной части изделия и обеспечивать однозначную идентификацию каждого документа пакета: необходимый атрибутивный
состав для его поиска и описания, код привязки документа к составной части электронной структуры изделия и стадии ЖЦ.
87
88
Рис. 11. Комплект электронной документации импортированный в модель СОТОП
3.3.3.2. Информационная среда второго поставщика-потребителя
Например, инфраструктура информационной среды второго поставщика-потребителя может быть сформирована на основе следующих функциональных объектов (подсистем) [14]:
− единая среда интеграции информационных ресурсов;
− единая среда мониторинга и управления технологическими
процессами;
− единая среда мониторинга безопасности технического расчета
при проведении работ;
− единая среда мониторинга, управления и поддержки принятия
решений при проведении работ.
Информационная инфраструктура должна строится как многоуровневая иерархическая система, начиная с верхнего уровня –
АСУ предприятия – и заканчивая нижним уровнем – управление
технологическим оборудованием.
Реализация системной платформы информационной среды, основывается на решениях базовых информационных защищенных
компьютерных технологий с применением как зарубежных, так
и отечественных аппаратно-программных комплексов, систем сбора, хранения и передачи данных.
Единая среда интеграции информационных ресурсов (технологических, информационно-управляющих систем, данных АСУ) обеспечивает консолидацию, хранение и доступ к разнородной информации на всех этапах ЖЦИ.
Единая среда мониторинга и управления технологическими
процессами формируется комплексом программно-аппаратных
средств АСУ технологическим оборудованием (АСУ ТО) и информационно-управляющих систем и обеспечивает решение следующих
задач:
− обмен командами и сигналами со смежными системами и приём информации о текущих значениях параметров в технологических системах и агрегатах, а также информации о состоянии управляемых исполнительных механизмов;
− отображение информации о ходе технологических процессов,
находящихся под управлением АСУ ТО, в виде текстовых сообщений, мнемосхем с динамическими формами отображения управляемых механизмов, значений параметров, гистограмм, а также графиков и трендов;
− формирование управляющих воздействий на исполнительные
механизмы объектов управления и сигналов в смежные системы
89
при реализации алгоритмов автоматического, пооперационного
или ручного режимов управления;
− ручное дистанционное управление исполнительными механизмами технологических систем;
− дистанционное включение (выключение) и контроль приборного оборудования технологических систем;
− формирование архива событий, представление данных архивов в форме отчётов и их отображение на экранах операторов;
− регистрацию необходимой информации о ходе технологических процессов;
− предоставление операторам справочной информации по управлению технологическим процессом в соответствии с технологическим графиком, состоянием объекта управления и смежных систем;
− техническое диагностирование АСУ ТО и линий связи при подготовке к работе и в процессе работы, обеспечивать локализацию
места отказа с глубиной до элемента замены;
− задание необходимого комплекта технологического оборудования как объекта управления АСУ ТО в соответствии с признаками
типа изделия, выдаваемыми верхним звеном управления;
− управление операциями по жесткому последовательному алгоритму штатной работы с возможностью перехода от любой операции прямого хода на выполнение соответствующей обратной последовательности операций при отмене работы;
− исключение возможности одновременного воздействия на одни
и те же исполнительные элементы агрегатов и комплектов с органов
управления центральных и местных пультов, являющихся принадлежностью агрегатов и комплектов.
Единая среда мониторинга безопасности специалистов формируется комплексом программно-аппаратных средств системы безопасности и контроля (СБК) который обеспечивает:
− управление доступом специалистов в закрытые зоны, сооружения и помещения;
− мониторинг местонахождения специалистов на рабочих местах, в опасных помещениях, сооружениях и зонах;
− контроль выполнения планов эвакуации при нештатных и аварийных ситуациях;
− видеоконтроль местонахождения специалистов в контролируемых зонах, сооружениях, помещениях.
Единая среда мониторинга, управления и поддержки принятия
решений при проведении работ в ходе работ формируется комплексом программно-аппаратных средств АСУ.
90
АСУ обеспечивают интеграцию информационных ресурсов, взаимодействие со всеми информационными системами космодрома
и обеспечивает решение следующих основных задач:
− сбор, хранение, обработку, анализ и оценку консолидированных данных об изделии на всех этапах ЖЦ;
− управление ходом выполнения технологических процессов;
− выдачу управляющих воздействий и формирование рекомендаций на АРМ специалистов и во взаимодействующие с АСУ информационные и управляющие системы предприятия;
− получение оперативных заключений о контролируемых событиях и обеспечение информационной поддержки принимаемых решений;
− формирование отчетной документации, визуализация результатов оценки контролируемых событий на средствах отображения
информации АСУ;
− организацию электронного документооборота организационно-технической и технологической документацией;
− оперативный доступ специалистов к технической и эксплуатационной документации, результатам испытаний на всех этапах проведения работ.
Консолидация информационных ресурсов, формируемые в ходе
выполнения этапов работ, осуществляется с использованием технологий сбора и обработки потоков данных в реальном масштабе
времени, организации систем оперативного и долговременного хранения на основе распределённых и централизованных баз данных
и файловых хранилищ.
По видам информации, циркулирующей в информационной среде, различают системы хранения:
− дискретной и аналоговой информации, формируемой технологическими системами;
− данных системы диагностики технологического оборудования;
− данных хода и результатов выполнения операций технологических графиков работ;
− данных пассивной и активной (радиочастотной) идентификации специалистов;
− данных видеоконтроля за обстановкой и местонахождением
специалистов;
− электронной документации (СЭД, информационно-справочное
обеспечение);
− результатов обработки ТМИ системы телеметрических измерений.
91
АСУ в архитектуре информационной среды предприятия занимает главенствующее положение, поскольку координирует работу
и консолидирует данные всех информационных систем в ходе пусковых кампаний.
В рамках СОТОП предусматривается преобразование разнородных моделей данных в единую интегрированную (каноническую)
модель с использованием прикладных сервисов АСУ. При этом АСУ
выступает в роли интеграционной шины, которая собирает, преобразует и передаёт данные на уровень комплектования консолидированных пакетов (файлов) экспорта.
Рассмотрены четыре регламента информационного взаимодействия АСУ предприятия с моделью СОТОП, использующие следующие источники комплектования:
− пакеты экспорта технологической и измерительной информации, формируемые сервисами интеграции АСУ;
− файлы или каталоги файлов, представляющих комплекты
электронных документов с организационно-технической и технологической информацией (см п.п. 2.1.1);
− упакованные файлы оперативных баз данных, формируемых
сервисами мониторинга и оценки состояния АСУ;
− потоки технологической и измерительной информации в реальном масштабе времени.
Процедуры интеграции отсканированных электронных документов (при переводе бумажной документации в цифровой вид), после формирования комплектов экспорта, аналогичны регламенту
информационного взаимодействия на основе файловых каталогов.
Первый регламент реализует процедуру интеграции данных
АСУ в модель СОТОП на основе пакетов экспорта технологической
и измерительной информации. Предлагается реализация пакета
экспорта, включающего данные и метаданные, оформленные в виде
следующих разделов обменного XML файла:
− данные по функционированию АСУ (список активных режимов, выполняемых операций, контрольные значения основных параметров и др.);
− данные по этапам выполнения технологического графика (состав, текущие атрибуты операций (время, статус и др.));
− данные по контролю специалистов (состав, количество персонала на рабочих местах, контрольные данные эвакуации и др.).
Регламент предполагает следующую последовательность действий:
− пакет экспорта (сформированный сервисами интеграции набор
данных в виде обменного XML файла) выгружается из АСУ;
92
− выгрузка производится на промежуточный (архивный) сервер
в согласованную структуру папок общего доступа. Может быть использован сервер АСУ;
− при использовании сервера АСУ процедура комплектования реализуется на средствах модели СОТОП первого уровня, второй вариант
предусматривает использование средств модели СОТОП второго уровня;
− выполняется загрузка (импорт), разбор и конвертация данных
обменного XML файла: преобразование данных в электронные документы, в соответствии с типом раздела XML файла. Конвертация
выполняется на основе шаблона с заданным набором атрибутов.
Предусмотрено использование как непосредственно электронного
документа (например, электронной таблицы), так и создаваемой на
его основе графической экранной формы;
− далее в автоматизированном режиме заполняются регистрационные карточки созданных документов и осуществляется их привязка к ЭСИ и стадиям ЖЦ;
− при выполнении процедур комплектования на средствах модели СОТОП второго уровня, подготовленный комплект документов
и данных переноситься со второго уровня на первый, в централизованное хранилище;
− при положительных результатах обработки набора данных
импорта, выполняются публикация загруженного контента и процедура очистки содержимого папок общего доступа на промежуточном сервере.
Обменные XML файлы сохраняются в архиве, что обеспечивает возможность передачи пакетов данных повторно, в случаях повреждения файлов или их утраты.
Каждая операция экспорта и импорта данных сопровождается
протоколированием списка передаваемых объектов, подробным
описанием выполняемых операций и сообщениями об ошибках.
Пример интеграции данных АСУ в модель СОТОП представлен
на рис. 12, 13.
Второй регламент рассмотрен на примере интеграции комплектов электронных документов с организационно-технической и технологической информацией и предполагает следующую последовательность действий:
− комплект документации в виде согласованной логической
структуры файловых каталогов выгружается из АСУ;
− выгрузка производится на промежуточный (архивный) сервер
в согласованную структуру папок общего доступа. Может быть использован сервер АСУ;
93
94
Рис. 12. Данные АСУ ПП в информационной среде модели СОТОП: контроль операций
технологического графика и данных системы безопасности
95
Рис. 13. Данные АСУ в информационной среде модели СОТОП: мониторинг
и оценка процессов функционирования смежных систем
− при использовании сервера АСУ процедура комплектования
реализуется на средствах модели СОТОП первого уровня, второй вариант предусматривает использование средств модели СОТОП второго уровня;
− далее выполняется процедура комплектования, предусматривающая заполнение регистрационных карточек (атрибутирование)
и привязку документации к ЭСИ и стадиям ЖЦ;
− при выполнении процедур комплектования на средствах модели СОТОП второго уровня, подготовленный набор документов
и данных переноситься со второго уровня на первый, в централизованное хранилище;
− при положительных результатах обработки набора данных
импорта, выполняются публикация загруженного контента и процедура очистки содержимого папок общего доступа на промежуточном сервере.
Третий регламент рассмотрен на примере интеграции оперативных баз данных формируемых сервисами мониторинга и оценки состояния АСУ и предполагает следующую последовательность действий:
− файловые каталоги оперативных баз данных упаковываются
и выгружаются из АСУ на промежуточный сервер в согласованную
структуру папок общего доступа (сервер АСУ);
− на средствах комплектования выполняются распаковка, заполнение регистрационных карточек (атрибутирование) и перенос
файлов БД в логический раздел электронного каталога, содержащий набор оперативных БД;
− при выполнении процедур комплектования на средствах модели СОТОП второго уровня, подготовленный набор документов
и данных переноситься со второго уровня на первый, в централизованное хранилище;
− при положительных результатах обработки набора данных
импорта, выполняются публикация загруженного контента и процедура очистки содержимого папок общего доступа на промежуточном сервере.
Четвёртый регламент предусматривает трансляцию потоков
технологической и измерительной информации АСУ в реальном
масштабе времени в единое информационное пространство с использованием прикладных сервисов комплектов первого уровня.
Для этого, с использованием коммуникационной инфраструктуры,
организуются транспортные каналы, связывающие сервисы формирования информационных потоков АСУ с прикладными серви96
сами трансляции данных РМВ (из состава модели СОТОП первого
уровня).
Разработанные регламенты позволяют организовать интеграцию в ЕИП модели СОТОП данных любых информационных систем
классов PDM/PLM,ERP,MES, а также специализированных АСУ
модели СОТОП, обладающих программными сервисами для работы
с внешними (смежными) информационными системами. При этом
наработанные технические решения в организации информационного взаимодействия позволяют осуществлять:
− обмен данными между территориально-распределенными информационными системами;
− разрешение конфликтов неоднородности моделей данных различных информационных ресурсов;
− разрешение конфликтов именования сущностей систем, приведение к общей терминологии на уровне интеграции;
− приведение типов и структур данных к единому обменному
формату;
− выявление конфликтов обмена и обновления данных, с возможностью их анализа и исправления;
− автоматизацию процессов интеграции данных разнородных
источников информации.
Предложенные регламенты интеграции являются основой технологии управления данными, которая реализует комплекс методов, понятий (объектов), информационных моделей, правил использования, интерфейсов доступа к данным, необходимых для работы
с заданным классом данных при организации информационного
взаимодействия на всех этапах ЖЦ изделия.
97
ЗАКЛЮЧЕНИЕ
В настоящем учебном пособии рассмотрена организация
производства в ракетно-космической отрасли и технология создания модели СОТОП.
Данное учебное пособие стало логическим продолжением темы
затронутой в предыдущем учебном пособии «Организация производства на предприятиях при изготовлении прикладных автоматизированных систем мониторинга и управления различными сложными организационно-техническими объектами и процессами на
основе компьютерного моделирования и цифровой обработки сигналов».
Дано описание развертывания виртуального информационного
пространства через модели СОТОП и через, взаимосвязанные с ним,
программные комплексы руководителей различных уровней.
Представлены основные вопросы, связанные с созданием модели СОТОП, которые предназначены для моделирования сбора, обработки, хранения, отображения, документирования и доведения
технологической, измерительной и отчетной информации с целью
обеспечения эффективного управления сложными организационными и техническими процессами.
Проведено описание назначения, области применения, технических характеристик и принципов построения модели СОТОП. Дано
обоснование выбора архитектуры, структуры и ПО моделей СОТОП.
Представлены некоторые варианты алгоритмов и программ для моделей СОТОП, разработанные на протяжении нескольких лет студентами кафедры № 43 под руководством авторов учебного пособия.
В следующем учебном пособии будет продолжено рассмотрение
модели СОТОП. Будет проведен анализ данных, циркулирующих
в модели СОТОП. Будет рассмотрена аналитическая отчетность,
структура программного обеспечения, интерфейсы взаимодействия, программная платформа управления фондами.
98
ПЕРЕЧЕНЬ ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. ГОСТ Р ИСО/МЭК 15288-2005 – Национальный стандарт РФ.
Информационная технология. Системная инженерия. Процессы жизненного цикла систем. http://www.novsu.ru/file/1193269,
23.10.2017 г.
2. ГОСТ РО 1410-002-2010 – Ракетно-космическая техника. Система информации о техническом состоянии и надежности космических комплексов и входящих в их состав изделий. Основные положения: национальный стандарт Российской Федерации ограниченного распространения. http://search.rsl.ru/ru/record/ 01004918793,
23.10.2017 г.
3. ГОСТ 2.054-2013 – ЕСКД. Электронное описание изделия. Общие
положения. http://docs.cntd.ru/document/1200115350, 23.10.2017 г.
4. Агапов В. Результаты расследования аварии РН Titan 4 с КА
Milstar 2// Новости космонавтики. 1999. №9. С. 53–55.
5. Охтилев М.Ю, Соколов Б.В., Юсупов Р.М. Интеллектуальные
технологии мониторинга и управления структурной динамикой
сложных технических объектов. М.: Наука, 2006. – 410 c.
6. О. Урманов. ИПИ: шанс не отстать навсегда. Российский космос №5(29) 2008. С. 13–15.
7. А. Ю. Россиев. Разработка технологии построения системы
информации о техническом состоянии космических комплексов.
Доклад. Научная сессия ГУАП, 6–10 апреля 2009 г. СПБ.: ГУАП.,
2017. С. 47–52.
8. Методические рекомендации по электронному копированию
архивных документов и управлению полученным информационным массивом / Ю.Ю. Юмашева. М.: ВНИИДАД, 2012. – 66 c.
9. «Сравнительный анализ форматов электронных документов
постоянного (долговременного) хранения», Российский государственный гуманитарный университет (РГГУ), http://archives.ru/
sites/default/files/rekomendation-rggu-format-2013.pdf, 23.10.2017г.
10. Филатов А.Н. Мы владеем уникальной методологией нисходящего проектирования. CAD/CAM/CAE Observer. 2010. № 5 (57).
С. 10–23.
11. Филатов А.Н. Разработка методов и моделей параллельного
нисходящего проетирования ракетно-космической техники в едином информационном пространстве предприятия. Диссертация на
соискание учёной степени ктн. Самара: СГАУ, 2014. 163 с. http://www.
ssau.ru/files/resources/dis_protection/Filatov_A_N_ Razrabotka_
metodov_i_model.pdf, 23.10.2017г.
99
12. Шмелев В.В. Корпоративная информационная система автоматизированной системы управления подготовкой и пуском ракеты космического назначения. Сборник трудов ВКА имени А.Ф.
Можайского I кв. 2015 г. СПБ: ВКА имени А.Ф. Можайского. 2015.
С. 36–39.
13. Теория и практика построения автоматизированных систем
мониторинга технического состояния космических средств. Монография. Под редакцией О.В. Майдановича. Санкт-Петербург: ВКА
имени А.Ф. Можайского, 2011. 219 с.
14. Ахметов Р.Н., Васильев И.Е., Капитонов В.А., Охтилев М.Ю.,
Соколов Б.В. Автоматизированная система управления подготовкой и пуском космодрома // Авиакосмическое приборостроение.
2015. № 4. С. 3–54.
15. ГОСТ 2.053- 2013 – ЕСКД. Электронная структура изделия. Общие положения. http://docs.cntd.ru/document/1200106861,
23.10.2017 г.
16. ГОСТ 2.055- 2014 – ЕСКД «Электронная спецификация. Общие
положения. http://docs.cntd.ru/document/1200122005, 23.10.2017 г.
17. Архитектурное моделирование автоматизированных систем:
учебное пособие/ П.И. Соснин. – Ульяновск: УлГТУ, 2008. 147 с.
18. Единый виртуальный электронный паспорт космической ракеты-носителя «Союз-2». Пояснительная записка. Часть 1. Книга 1.
Назначение, принципы построения, технические характеристики /
Под общей редакцией руководителя проекта Гамова В.Ю. Изд. АО
«НИО ЦИТ «Петрокомета», 2015. 280 с.
19. ГОСТ Р 51275- 2006 – Национальный стандарт РФ. Защита
информации. Объект информатизации. Факторы, воздействующие на информацию. http://www.altell.ru/legislation/standards/
51275-2006.pdf, 23.10.2017г.
20. ГОСТ Р 56135-2014 – Национальный стандарт РФ. Управление жизненным циклом продукции военного назначения. Основные
положения. http://www.codification.rusarm.ru/ckgz/?wpfb_dl=157,
23.10.2017 г.
21. А.Н. Филатов, И.В. Никашина, В.А. Комаров. Электронный
технический документооборот конструкторской документации как
основа единого информационного пространства предприятия аэрокосмической отрасли. Изд. ГНПРКЦ «ЦСКБ_Прогресс», г. Самара.
2013. 128 с.
22. Информационная поддержка жизненного цикла изделий
машиностроения.: принципы, системы и технологии CALS/ИПИ.
учеб. пособие / А. Н. Ковшов, Ю. Ф. Назаров, И. М. Ибрагимов,
100
А. Д. Никифоров. М.: Издательский центр «Академия», 2007.
304 с.
23. Концепция развития CALS-технологий в промыщленности
России./ НИЦ CALS-технологий «Прикладная логистика»; Е.В. Судов, А.И. Левин. М., 2002. 130 с.
24. Майданович О.В. Новая интеллектуальная информационная
технология мониторинга состояния и управления космическими
средствами в реальном масштабе времени // Сборник трудов XXVII
Межведомственной научно-технической конференции космодрома
Плесецк «Научно-технические аспекты совершенствования эксплуатации существующих и испытаний перспективных образцов ракетно-космической техники в современных условиях». Космодром
«Плесецк». 2010. 181 с.
25. О Debian. Свободная операционная система. http://www.debian.
org/intro/about, 23.10.2017г.
101
ПРИЛОЖЕНИЕ А
Варианты алгоритмов моделей и комплексов программ СОТОП
Пусть необходимо разработать следующую модель СОТОП.
Сервер обрабатывает запросы, поступающие с автоматизированных рабочих мест (АРМ) с интервалами, распределенными
по экспоненциальному закону со средним значением T1 = 2 ìèí.
Вычислительная сложность запросов распределена по нормальному
закону с математическим ожиданием S1= 6 ⋅ 107 îï и среднеквадратическим отклонением S2= 4 ⋅ 105 îï. Производительность сервера по обработке запросов Q= 2 ⋅ 105 îï/ñ, ε =0,01, α =0,95.
Построить алгоритм имитационной модели с целью определения
вероятности обработки запросов за время Ò = 1 ÷àñ. Построить план
ПФЭ. Исследовать зависимость вероятности обработки запросов
от интервалов их поступления, вычислительной сложности
и производительности сервера. Рассчитать число прогонов для
наихудшего случая.
Рассмотрим варианты алгоритмов и комплексов программ
данной модели СОТОП.
Вариант 1
Код matlab
Task5.m
S1minus = 9 * 10^7;
S1plus = 3 * 10^5;
S2minus = 2 * 10^5;
S2plus = 8 * 10^5;
Qminus = 1 * 10^5;
Qplus = 5 *10^5;
t _ alpha = 1.28;
Eps = 0.01^2;
%%вычисление функций лапласа
Pmm = lapl(Qminus/S2minus);
Pmp = lapl(Qminus/S2plus);
Ppm = lapl(Qplus/S2minus);
Ppp = lapl(Qplus/S2plus);
102
%%вычисление N
Nmm = t _ alpha^2 * ((Pmm * (1-Pmm))/Eps);
N05 = t _ alpha^2 * ((0.5 * (1-0.5))/Eps);
Lapl.m (функция лапласа)
function [ output _ args ] = lapl(input _ args)
Ff =@(input _ args)exp((-input _ args.^2)/2);
output _ args =(2/sqrt(2 * pi)) .*integral(Ff,0, input _ args);
end
Результат расчета
Вариант 2
Код программы
S1=6*10^5; S2=2*10^5; Q1=6*10^5; Q2=2*10^5; t=3.30; e=0.01; f1mm=Q2/S2; f2mp=Q2/S1; f3pm=Q1/S2; 103
f4pp=Q1/S1; Pmm=2*lap(f1mm); Pmp=2*lap(f2mp); Ppm=2*lap(f3pm); Ppp=2*lap(f4pp); N =t^2*(Pmm*(1-Pmm)/e^2); Np=t^2*(0.5*(1-0.5)/e^2);
Реализация функции Лапласа
function answer = lap(arg)
syms q
L=int(exp(-(q^2/2)),q,0,arg);
answer = double(L*1/sqrt(2*pi));
end
Результат выполнения работы
Данные, которые мы подставляли в функцию Лапласа сходятся.
Также как результаты вычислений.
Вариант 3
Код программы
S2=3*10^5;
Q=5*10^5;
t=1.65;
e=0.01;
Sp=S2*1.5;
Sm=S2*0.5;
Qp=Q*1.5;
Qm=Q*0.5;
104
fmm=Qm/Sm;
fmp=Qm/Sp;
fpm=Qp/Sm;
fpp=Qp/Sp;
Pmm=2*f _ laplas(fmm);
Pmp=2*f _ laplas (fmp);
Ppm=2*f _ laplas (fpm);
Ppp=2*f _ laplas (fpp);
N = t^2*(Pmm*(1-Pmm)/e^2);
Np=t^2*(0.5*(1-0.5)/e^2);
disp(‘mm’); disp([Pmm fmm]);
disp(‘pp’); disp([Ppp fpp]);
disp(‘mm’); disp([Pmp fmp]);
disp(‘mm’); disp([Ppm fpm]);
disp(‘N’); disp(N);
disp(‘Np’); disp(Np);
f _ laplas.m
function answer = f _ laplas(arg)
syms q
L=int(exp(-(q^2/2)),q,0,arg);
answer = double(L*1/sqrt(2*pi));
end
Результат выполнения программы
105
Вариант 4
Код программы
S1=8*10^5;
S2=2*10^5;
Q1=5*10^5;
Q2=1*10^5;
t=2.58;
e=0.01;
f1mm=Q2/S2;
f2mp=Q2/S1;
f3pm=Q1/S2;
f4pp=Q1/S1;
Pmm=2*lap(f1mm);
Pmp=2*lap(f2mp);
Ppm=2*lap(f3pm);
Ppp=2*lap(f4pp);
N = t^2*(Pmm*(1-Pmm)/e^2);
Np=t^2*(0.5*(1-0.5)/e^2);
Реализация функции Лапласа
function answer = lap(arg)
syms q
L=int(exp(-(q^2/2)),q,0,arg);
answer = double(L*1/sqrt(2*pi));
end
Результат выполнения работы
Данные, подставляемые в функцию Лапласа сходятся.
106
Вариант 5
Код программы
S2minus = 3 * 10^5;
S2plus = 9 * 10^5;
Qminus = 1 * 10^5;
Qplus = 3 *10^5;
t _ alpha = 1.65;
Eps = 0.01;
P = lapl(Qminus/S2minus);
Pmp = lapl(Qminus/S2plus);
Ppm = lapl(Qplus/S2minus);
Ppp = lapl(Qplus/S2plus);
Nmm = t _ alpha^2 * ((Pmm * (1-Pmm))/Eps^2);
N05 = t _ alpha^2 * ((0.5 * (1-0.5))/Eps^2);
fprintf(‘P--: %g \n’, Pmm);
fprintf(‘P-+: %g \n’, Pmp);
fprintf(‘P+-: %g \n’, Ppm);
fprintf(‘P++: %g \n’, Ppp);
fprintf(‘N--: %g \n’, Nmm);
fprintf(‘N0.5: %g \n’, N05);
Функция лапласа:
function [ output _ args ] = lapl(input _ args)
Ff =@(input _ args)exp((-input _ args.^2)/2);
output _ args =(2/sqrt(2 * pi)) .*integral(Ff,0, input _ args);
end
Результат
107
Вариант 6
Код программы
S2minus = 2 * 10^5;
S2plus = 8 * 10^5;
Qminus = 1 * 10^5;
Qplus = 5 *10^5;
t _ alpha = 1.28;
Eps = 0.01^2;
Pmm = lapl(Qminus/S2minus);
Pmp = lapl(Qminus/S2plus);
Ppm = lapl(Qplus/S2minus);
Ppp = lapl(Qplus/S2plus);
Nmm = t _ alpha^2 * ((Pmm * (1-Pmm))/Eps);
N05 = t _ alpha^2 * ((0.5 * (1-0.5))/Eps);
Функция лапласа:
function [ output _ args ] = lapl(input _ args)
Ff =@(input _ args)exp((-input _ args.^2)/2);
output _ args =(2/sqrt(2 * pi)) .*integral(Ff,0, input _ args);
end
Результат
Вариант 7
Код программы
%Входные
T1 = 60;
T = 1;
S1Before
Q1Before
S2Before
108
данные
= 6*10^7;
= 2*10^5;
= 6*10^5;
epsilon = 0.01;
alpha=0.9;
Ta = 1.65;
%Вычисление Q и S с учетом ошибки
otkl = T1/2;
s1After = S1Before/2;
QAfter = Q1Before/2;
s2After = S2Before/2;
T1p = T1 + otkl;
T1m = T1 – otkl;
S1plus = S1Before + s1After;
S1minus = S1Before – s1After;
Qplus = Q1Before + QAfter;
Qminus = Q1Before – QAfter;
S2p = S2Before + s2After;
S2m = S2Before – s2After;
mmf
mpf
pmf
ppf
=
=
=
=
Qminus/S2m;
Qminus/S2p;
Qplus/S2m;
Qplus/S2p;
%Вычисление функции Лапласа при различных P
syms z
mm1 = 2*(int(exp(-(z^2/2)),z,0,mmf));
mm2 = 1/(sqrt(2*pi));
mm = mm1*mm2;
mp1 = 2*(int(exp(-(z^2/2)),z,0,mpf));
mp2 = 1/(sqrt(2*pi));
mp = mp1*mp2;
pm1 = 2*(int(exp(-(z^2/2)),z,0,pmf));
pm2 = 1/(sqrt(2*pi));
pm = pm2*pm1;
pp1 = 2*(int(exp(-(z^2/2)),z,0,ppf));
pp2 = 1/(sqrt(2*pi));
pp = pp1*pp2;
Nplusplus = Ta^2 *(pp*(1-pp)/epsilon^2);
109
Nminusplus = Ta^2 *(mp*(1-mp)/epsilon^2);
Nplusminus = Ta^2 *(pm*(1-pm)/epsilon^2);
Nminusminus = Ta^2 *(mm*(1-mm)/epsilon^2);
fprintf(‘N-1-1 = %g \n’,Nminusminus);
fprintf(‘---------------\n’);
fprintf(‘N-1+1 = %g \n’,Nminusplus);
fprintf(‘---------------\n’);
fprintf(‘N+1-1 = %g \n’,Nplusminus);
fprintf(‘---------------\n’);
fprintf(‘N+1+1 = %g \n’,Nplusplus);
Вариант 8
Алгоритм имитационной модели
Для построения алгоритма имитационной модели введем следующие идентификаторы:
t1 – текущее время поступления запроса;
t2 – текущее время окончания обработки запроса;
k – счетчик количества прогонов модели (реализаций);
P – вероятность обработки запросов;
M – счетчик количества обработанных запросов;
N – заданное количество прогонов модели (реализаций);
R – количество запросов за N прогонов модели;
T – время моделирования.
Алгоритм имитационной модели с целью определения вероятности обработки запросов за время Т:
Блок 1. Задаются исходные данные и начальные значения
счетчиков k, M, R.
Блок 2. Задаются начальные значения t1 и t2 для нового прогона,
счетчик прогонов увеличивается на 1.
Блок 3. Вычисляется время поступления следующего запроса.
Блок 4. Если запрос поступит после завершения времени моделирования, то завершается прогон.
Блок 5. Счетчик количества поступивших запросов увеличивается на 1.
Блок 6. Если время поступления запроса, меньше времени завершения обработки предыдущего, то запрос не обрабатывается.
Блок 7. Вычисляется время окончания обработки запроса.
Блок 8. Счетчик количества обработанных запросов увеличивается на 1.
110
Блок 9. Проверяется сделано ли нужное количество прогонов.
Блок 10. Рассчитывается вероятность обработки запроса.
Реализация алгоритма на языке matlab
k=0;M=0;R=0;S1=6*10^7;S2=2*10^5;T=3600;
T1=60;Q=6*10^5;
while(k<1000)
t1=0;t2=0;
k=k+1;
while(1)
t1=t1+exprnd(T1);
if t1 > T
break;
end
R=R+1;
if t1 > t2
t2=t1+normrnd(S1,S2)/Q;
M=M+1;
end
end
P=M/R;
end
Для составления плана полного факторного анализа выбираем
интервалы варьирования уровней факторов. T =60 ± 30 –
средний интервал поступления запросов, h1 =0.5 и h2 = 1.5. Тогда
S1 = 6×107 ± 3×107оп, S1 = 2×105 ± 1×105оп Q = 6×105 ± 3×105оп/с –
производительность сервера.
В соответствии с интервалами варьирования
T1
S1/S2
Q
T1в
(S1/S2)н
(S1/S2)в
Qн
Qв
30
90
3×107/1×105
9×107/3×105
3×105оп
9×105оп
–1
+1
–1
+1
–1
+1
T1н
P–1–1 = 2Ф(3 × 105/1 × 105) = 0.9973
P–1+1 = 2Ф(3 × 105/3 × 105)=0.68268
P+1–1 = 2Ф(9 × 105/1 × 105) = 1
P+1+1 = 2Ф(9 × 105/3 × 105) = 0.9973
P–1–1 = 0.9973, P–1+1 = 0.68268, P+1–1 = 1, P+1+1 = 0.9973.
111
Вариант 9
Код программы
function l = flaplac(x, y)
a = x / y;
syms z
l = 2 * double(int(exp(-(z ^ 2 / 2)), z, 0, a) * 1 / sqrt(2 *
pi));
end
% дано
q = 5*10^5;
s2 = 3*10^5;
ta = 1.96; % a = 0.95
e = 0.01;
% s – меньшее
% b – большее
qhalf = q / 2;
qs = q – qhalf;
qb = q + qhalf;
s2half = s2 / 2;
s2s = s2 – s2half;
s2b = s2 + s2half;
% m – минус
% p – плюс
pmm = flaplac(qs, s2s);
ppp = flaplac(qb, s2b);
pmp = flaplac(qs, s2b);
ppm = flaplac(qb, s2s);
nmm = ta^2 * (pmm * (1 – pmm) / e^2);
npp = ta^2 * (ppp * (1 – ppp) / e^2);
npm = ta^2 * (ppm * (1 – ppm) / e^2);
nmp = ta^2 * (pmp * (1 – pmp) / e^2);
fprintf(‘N-- = %g \r\n’, nmm);
fprintf(‘N++ = %g \r\n’, npp);
fprintf(‘N+- = %g \r\n’, npm);
fprintf(‘N-+ = %g \r\n’, nmp);
Вариант 10
Код программы
•
main.cpp
#include “package _ system.h”
#include <iostream>
112
#include <stdlib.h>
using namespace std;
float get _ avg _ efficiency(int runs) {
float accumulator = 0.0;
for (float i = 0; i < runs; ++i)
accumulator += get _ efficiency();
return (accumulator / runs);
}
// int main(void) {
//
for (int i = 0; i < 1000; i++)
//
cout << get _ efficiency() << endl;
// }
int main(int argc, char const *argv[]) {
int id;
switch (argc) {
case 1:
cout << get _ efficiency() << endl;
break;
case 2:
id = atoi(argv[1]);
if (id == 0)
return 1;
cout << get _ avg _ efficiency(atoi(argv[1])) << endl;
break;
default:
cout << “Incorrect number of parameters.” << endl;
}
return 0;
}
•
package _ system.cpp
#include “package _ system.h”
#include “request _ generator.h”
using namespace std;
float get _ efficiency() {
Request req = get _ request();
Request tmp _ req = get _ request();
float nreceived = 0;
float nhandled = 0;
113
float current _ time = 0;
while (current _ time + req.time _ to _ exec < ACTIVE _ DUTY _
TIME) {
nreceived++;
if (req.time _ to _ exec > tmp _ req.time _ to _ gen) { //
Запрос поступил раньше, чем закончена обработка
current _ time += tmp _ req.time _ to _ gen;
req.time _ to _ exec -= tmp _ req.time _ to _ gen; //
Откусываем “кусок” отработанного времени
} else {
nhandled++;
current _ time += tmp _ req.time _ to _ gen;
req = tmp _ req;
}
tmp _ req = get _ request();
}
return (nhandled / nreceived);
}
•
package _ system.h
#ifndef PACKAGE _ SYSTEM _ H
#define PACKAGE _ SYSTEM _ H
#include “request _ generator.h”
#ifndef STACK _ H
#define STACK _ H
#include <stack>
#endif /* end of include guard: STACK _ H */
const
const
const
const
const
float
float
float
float
float
ACTIVE _ DUTY _ TIME = 3600; // T
COMPLEXITY _ MEAN = 60000000; // S1
COMPLEXITY _ DEV = 400000; // S2
GENTIME _ MEAN = 60;
// t
PERFORMANCE = 400000;
// Q
float get _ efficiency();
#endif /* end of include guard: PACKAGE _ SYSTEM _ H */
114
request _ generator.cpp
#include “package _ system.h”
using namespace std;
default _ random _ engine generator;
exponential _ distribution<float> expdist(1/GENTIME _ MEAN);
//exponential _ distribution<float> expdist(60);
normal _ distribution<float> normdist(COMPLEXITY _ MEAN, COMPLEXITY _ DEV);
Request get _ request() {
Request retval;
retval.time _ to _ gen = expdist(generator);
retval.time _ to _ exec = abs(normdist(generator) / PERFORMANCE);
return retval;
}
•
request _ generator.h
#ifndef REQUEST _ GENERATOR _ H
#define REQUEST _ GENERATOR _ H
#ifndef RANDOM _ H
#define RANDOM _ H
#include <random>
#endif /* end of include guard: RANDOM _ H */
#ifndef CSTDLIB _ H
#define CSTDLIB _ H
#include <cstdlib>
#endif /* end of include guard: CSTDLIB _ H */
struct Request {
float time _ to _ gen;
float time _ to _ exec;
};
Request get _ request();
#endif /* end of include guard: REQUEST _ GENERATOR _ H */
115
Вариант 11
Код программы
#include
#include
#include
#include
#include
<iostream>
<stdlib.h>
<stack>
<random>
<cstdlib>
using namespace std;
const
const
const
const
const
float
float
float
float
float
T = 3600;
S1 = 60000000;
S2 = 300000;
t = 60;
Q = 500000;
struct Request {
float timeToGen;
float timeToExec;
};
default _ random _ engine generator;
exponential _ distribution<float> expdist(1/t);
normal _ distribution<float> normdist(S1, S2);
Request getRequest();
float getEfficiency();
float getAvgEfficiency(int runs);
int main(int argc, char const *argv[]) {
int id;
switch (argc) {
case 1:
cout << getEfficiency() << endl;
break;
case 2:
id = atoi(argv[1]);
if (id == 0)
return 1;
cout << getAvgEfficiency(atoi(argv[1])) << endl;
break;
116
default:
cout << “Incorrect number of parameters.” << endl;
}
return 0;
}
float getAvgEfficiency(int runs) {
float accumulator = 0.0;
for (float i = 0; i < runs; ++i)
accumulator += getEfficiency();
return (accumulator / runs);
}
float getEfficiency() {
Request req = getRequest();
Request tmp _ req = getRequest();
float nreceived = 0;
float nhandled = 0;
float current _ time = 0;
while (current _ time + req.timeToExec < T) {
nreceived++;
if (req.timeToExec > tmp _ req.timeToGen) {
current _ time += tmp _ req.timeToGen;
req.timeToExec -= tmp _ req.timeToGen;
} else {
nhandled++;
current _ time += tmp _ req.timeToGen;
req = tmp _ req;
}
tmp _ req = getRequest();
}
return (nhandled / nreceived);
}
Request getRequest() {
Request retval;
retval.timeToGen = expdist(generator);
retval.timeToExec = abs(normdist(generator) / Q);
return retval;
}
117
ПРИЛОЖЕНИЕ Б
Свидетельства о государственной регистрации программ
для моделей СОТОП
118
119
120
121
122
СОДЕРЖАНИЕ
Предисловие................................................................. 3
1. Назначение и область применения модели СОТОП........... 1.1. Система информации о техническом состоянии
и надёжности......................................................
1.2. Назначение модели СОТОП...................................
5
5
16
2. Технические характеристики
и принципы построения модели СОТОП............................ 19
2.1. Концепция построения модели СОТОП...................
19
2.1.3.1. Формирование единого информационного
пространства..................................................
29
2.1.3.2. Интеграция информационных систем..........
32
2.1.3.3. Построение модели электронного
описания изделия...........................................
37
2.1.3.4. Применение унифицированных
программных платформ. .................................
39
2.1.3.5. Использование технологий автоматизированной
разработки программного обеспечения..............
43
3. Описание и обоснование выбранной конструкции............ 56
3.1. Функциональная структура модели СОТОП.............
56
3.2. Архитектура модели СОТОП.................................
62
3.2.2.1. Варианты применения моделей СОТОП.............
67
3.3. Информационное взаимодействие
в модели СОТОП..................................................
72
3.3.3.1. Информационная среда
первого поставщика-потребителя.....................
81
3.3.3.2. Информационная среда второго поставщика-потребителя.....................................................
89
Заключение.................................................................. 98
Перечень использованной литературы.............................. 99
Приложение А. Варианты алгоритмов моделей
и комплексов программ СОТОП....................................... 102
Приложение В. Свидетельства о государственной регистрации
программ для моделей СОТОП......................................... 118
123
Учебное издание
Гамов Владислав Юрьевич
Охтилев Михаил Юрьевич
РАЗРАБОТКА МЕТОДОЛОГИЧЕСКИХ ОСНОВ
МОДЕЛИРОВАНИЯ ОБЪЕКТОВ И ПРОЦЕССОВ
В КОСМИЧЕСКОЙ ОТРАСЛИ
Учебное пособие
Публикуется в авторской редакции
Компьютерная верстка Н. Н. Караваевой
Сдано в набор 15.01.18. Подписано к печати 10.02.18. Формат 60 × 84 1/16.
Усл. печ. л. 7,15. Тираж 50 экз. Заказ № 37.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
124
Документ
Категория
Без категории
Просмотров
8
Размер файла
4 528 Кб
Теги
gamovokhtilev
1/--страниц
Пожаловаться на содержимое документа