CC BY
114
Организационные и технологические приемы подготовки разработчиков бортовых систем управления космическими аппаратами
Попов Борис Николаевич доктор технических наук, профессор кафедры "Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов"
Московского авиационного института (НИУ).
Москва, (499)158-47-69
Порешин Петр Петрович старший преподаватель кафедры "Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов"
Московского авиационного института (НИУ).
Москва, pporeshin@mai.ru, (499)158-47-69
Синицын Сергей Владимирович кандидат технических наук, доцент, нач.отдела ФГУП Московское опытно-конструкторское бюро «Марс».
Москва, 705b@mokb-mars.ru, (499)978-30-95
Сыров Анатолий Сергеевич доктор технических наук, генеральный конструктор ФГУП Московское опытно-конструкторское бюро «Марс».
Москва.
Аннотация
В работе рассматриваются организационно-технологические аспекты подготовки кадров, ориентированных на разработку систем управления космическими аппаратами. Особенностью подобных систем является длительный срок разработки, использование кросс-средств создания программного обеспечения, невозможность прямого внесения изменений в систему в процессе эксплуатации, продолжительность которой может составлять 10 - 15 лет.
The paper deals with the organizational and technological aspects of the training focused on the development of spacecraft control systems. Feature of these systems is a long-term development, the use of cross-media software development, lack of direct changes to the system in operation, the duration of which may be 10 - 15 years
Ключевые слова
подготовка кадров, системы управления, космические аппараты, базовая кафедра, среда информационной поддержки.
training, control systems, space vehicles, base chair, environment of information support.
Введение
Необходимость подготовки специалистов для создания бортовых систем управления, владеющих конкретными технологиями, применяемыми в космической
отрасли, приводят к поиску тесных контактов между высшим учебным заведением и промышленным предприятием. Такое взаимодействие может приобретать различные формы: прохождение практики на предприятии отрасли, выполнение курсовых и дипломных проектов по тематике и под руководством специалистов предприятия, чтение профильных курсов сотрудниками промышленности и т.п.
Схемой взаимодействия ВУЗ - предприятие, рассматриваемой в этой работе является организация базовой кафедры. Характерным для такой формы сотрудничества следует считать то, что значительную часть профильных предметов студентам читают специалисты предприятия - партнера, а занятия проводятся на технической базе предприятия и для закрепления теоретического материала в составе учебных заданий и лабораторных работ используются элементы промышленных технологических процессов и реальных изделий.
Данная форма взаимодействия позволяет базовому предприятию в значительной степени влиять на формирование учебного плана [1]. Объемно это выражается в профиле «специальных» дисциплин, приведенном на рис. 1. Количество предметов коррелирует с числом преподавателей - специалистов предприятия, вовлеченных в учебный процесс. На практике получается, что без учета индивидуального руководства курсовыми проектами и дипломными работами в одном семестре (четном или нечетном) должны быть задействованы от 10 до 15-ти преподавателей.
При этом возникает ряд организационных проблем, требующих разрешения при планировании работы базовой кафедры. Первая - составление учебного плана, обеспечивающего часовой нагрузкой, как выпускающую кафедру, так и обеспечивающие кафедры базового ВУЗа. Для МАИ (НИУ) это означает не менее 5-ти полных преподавательские ставки, соответственно 4500 часов нагрузки в год.
Рис. 1. Распределение предметов и часов специальных дисциплин по
семестрам
Подобная ситуация, особенно на стартовом этапе (первые 8 семестров), приводит к тому, что учебной нагрузки базовой кафедре не хватает для обоснования своего численного состава. Реально получается, что в первый год нагрузки хватает только на двух преподавателей. А ведь именно на этот период приходится масса организационной работы заведующего кафедрой и учебно-вспомогательного персонала. Кроме того, по всем объявленным в учебном плане дисциплинам уже с самого начала требуется полный комплект учебно-методических материалов, и, следовательно, необходимо вовлечение полного штата сотрудников, отвечающих за содержание и последующее чтение соответствующих курсов. Поэтому базовое
предприятие вынуждено содержать дополнительный штат преподавателей, оплачивая его за счет договоров с ВУЗом.
Вторая проблема - использование штатных сотрудников предприятия для проведения занятий по профильным дисциплинам. Как отмечалось выше, в учебном процессе оказываются задействованными порядка 20 специалистов, которые должны тратить личное время на методическую подготовку, дорогу и непосредственное проведение занятий. При этом время в дороге оказывается сопоставимо с остальными временными затратами. Сократить эти потери можно за счет переноса занятий на территорию базового предприятия. То есть приблизить место проведения занятий к месту работы преподавателей базовой кафедры.
Третья проблема - методическая. Как вовлечь студентов в реальный производственный процесс предприятия? Как правило, существуют реальные технологические ограничения, которые не позволяют допускать группу студентов к реальным промышленным установкам, или реальные технологические процессы не позволяют изменять их характеристики в достаточно широких пределах в учебных целях. Все это приводит к необходимости каждый раз искать разумный компромисс между наглядностью и реалистичностью.
Организационные основы
Опыт четырех лет совместной работы ФГУП МОКБ «Марс» и базовой кафедры № 705Б МАИ (НИУ) в области обучения разработке бортовых систем управления космическими аппаратами может служить иллюстрацией возникающих на пути базовой кафедры проблем и способов их решения при условии явной заинтересованности базового предприятия. Забегая вперед, следует отметить, что примененные на кафедре методические приемы позволили уже к концу третьего курса вовлечь в работу на предприятии более 80% обучающихся.
Процесс подготовки кадров на ФГУП МОКБ «Марс» традиционно велся в нескольких направлениях. Во-первых, это совместная работа с высшими и средними специальными учебными заведениями. Во-вторых, это плановая переподготовка кадров через институт повышения квалификации работников машиностроения и приборостроения (ИПК МАШПРИБОР). В - третьих, это подготовка кадров высшей квалификации через аспирантуру.
Сотрудничество МОКБ «Марс» и высших учебных заведений в целях подготовки кадров за последние 20 лет обрело несколько форм, среди которых:
• проведение практик студентов различных ВУЗов;
• создание и организация работы филиалов кафедр;
• создание и организация работы базовой кафедры.
Проведение учебных, производственных и преддипломных практик не является обязательной деятельностью предприятия и представляет собой особую форму договорных отношений. Предприятие имело их с МАИ, МГТУ, МЭИ и МИЭМ.
В МОКБ было создано 4 филиала кафедр МАИ и МГТУ имени Н.Э.Баумана, через которые ежегодно проходили около пятидесяти студентов. Старейшим из них является филиал кафедры «Системы приводов авиационно-космической техники» МАИ, осуществляющий учебный процесс совместно с МОКБ и в интересах МОКБ с 1991 года. Накопленный опыт позволил прийти к выводу, что пришла пора создания собственной кафедры.
Организационной основой новой формы взаимодействия послужил договор 2010 года между ФГУП МОКБ «Марс» и МАИ (НИУ) о создании на факультете «Робототехнические и интеллектуальные системы» базовой кафедры №705Б
«Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов». Далее параллельно начались работы по подготовке учебного корпуса на территории базового предприятия, формирование педагогического коллектива кафедры и подготовка учебно-методических комплексов дисциплин.
Надо заметить, что разработка систем управления беспилотных летательных аппаратов (БПЛА) и встроенного в них программного обеспечения обладает рядом особенностей, каждая из которых встречается и в других областях применения средств вычислительной техники, но по отдельности. К таковым относятся:
• отсутствие возможности непосредственного контакта с бортом автономного космического аппарата, что исключает прямой путь внесения доработок в процессе эксплуатации;
• наличие различного вида воздействий в виде излучений и длительного (до 15 лет) срока эксплуатации, что приводит к необходимости аппаратного резервирования и динамического перераспределения ресурсов вычислительного процесса в ходе эксплуатации;
• длительные сроки разработки и эксплуатации космического аппарата заставляют беспокоиться о смене персонала, участвующего в процессах разработки и поддержки функционирования изделия, а кроме того, заставляют использовать инструментальные средства информационной поддержки жизненного цикла изделия (системы конфигурационного управления);
• особенности конструкции бортовых вычислителей, которые приводят к необходимости использования инструментальной кросс-среды разработки бортового программного обеспечения, существенно отличающейся от целевой среды эксплуатации;
• решение задач стабилизации, ориентации и управления траекторией космического аппарата приводят к необходимости расширения специальной математической подготовки.
Для охвата такого широкого спектра специальных требований уже на начальном этапе функционирования базовой кафедры пришлось подготовить целый ряд учебников и пособий [2-8], охватывающих основные разделы профильных дисциплин.
При определении основы учебного плана (примерной образовательной программы) было выбрано направление подготовки 161101 «Системы управления летательными аппаратами», по которому в университете уже был накоплен значительный опыт на факультете «Системы управления, информатика и электроэнергетика». Однако ни одна из предложенных в стандарте специализаций не подходила ко всем аспектам создания систем управления БПЛА. По традиции МАИ под беспилотными понимались исключительно атмосферные летательные аппараты. По просьбе базового предприятия и при поддержке военно-космической академии им. А.Ф. Можайского ученый совет МАИ принял решение об открытии дополнительной инновационной специализации «Системы управления беспилотными летательными аппаратами» (СУ БПЛА)
Комплексное решение проблемы специальной подготовки, поддержанное руководством базового предприятия и университетом, привело к тому, что базовая кафедра получила возможность начать свои занятия со студентами уже с первого семестра. При этом объем аудиторных часов, читаемых специалистами предприятия, начинается с 8-ми часов в неделю на первом курсе постепенно увеличивается до 23-х на пятом (Рис.1).
Методические аспекты подготовки
Наиболее важным при формировании учебного плана оказалось распределение различных читаемых базовой кафедрой дисциплин по семестрам. Благодаря доброй воле разных факультетов и кафедр университета удалось найти соглашение, которое учитывает не только ориентацию выпускающей кафедры на разработку СУ БПЛА, но и интересы других преподавателей, обеспечивающих гуманитарную и общеинженерную подготовку.
Из-за отсутствия специальных знаний в области высшей математики, механики, электротехники и электроники первые семестры сформированного учебного плана пришлось посвятить практически исключительно программистской подготовке. Все начинается с общего вводного курса в специальность и курса информатики, в котором значительно усилена технологическая составляющая разработки программного обеспечения. Ограничения общего ресурса времени привели к тому, что системы программирования ограничены изучением только одного языка высокого уровня - «С», зато вопросы ведения программной документации, выработки стиля программирования и техники верификации программного кода начинают изучаться сразу с первого семестра.
Следуя рекомендациям [9], параллельно читаются курсы по дискретной математике и программным системам реального времени, рассматривающие дискретные структуры и алгоритмы их обработки. В состав рассматриваемых структур данных включены темы: списки, списки с ограниченным доступом (ШЬ, ШЪ), представление списков в последовательной и связанной памяти, деревья и правила их обходов, сортировки и методы хеширования.
Далее, за ними рассматриваются технологические комплексы разработки и верификации встроенных программных систем. Отдельное место в курсе отведено изучению принципов построения и функционирования бортовой операционной системы, в том числе той ее части, которая связана с реконфигурацией вычислительного процесса на различных фазах полета космического аппарата.
Кроме того, в рамках дисциплины "Программные системы реального времени" предусмотрено освоение инструментальных средств поддержки разработки встроенного программного обеспечения, в состав которых включены специальные кросс-системы разработки программного обеспечения, почти полностью исключающие работу программиста-кодировщика, стенды алгоритмической и полунатурной отладки, испытательные стенды аппаратуры, среда информационной поддержки разработки и т. п.
Наконец, с пятого семестра параллельно с техническими средствами навигации и управления движением начинает в полном объеме рассматриваться программно-технический комплекс управления беспилотным летательным аппаратом, и начинаются семестровые курсовые проекты, обеспечивающие индивидуальную специализацию студента.
Значительную роль в формировании списка профильных дисциплин играет тот факт, что МОКБ «МАРС», как базовое предприятие, является организацией, осуществляющей разработку как программного, так и аппаратного обеспечения системы управления беспилотного летательного аппарата. Поэтому в рамках курса «Программно-технический комплекс управления беспилотных летательных аппаратов» рассматриваются не только аспекты проектирования, но и технологические процессы изготовления бортовой системы управления.
Это приводит к тому, что классическая общеинженерная подготовка специалиста тоже должна быть изменена. Специфика отрасли такова, что каждое изделие обладает набором индивидуальных черт - отсутствие серийности в производстве. При этом отсутствие повторений отнюдь не означает отсутствие преемственности или не использование опыта предшествующих проектов, но
приводит к переносу типизации на более низкий уровень технологических операций. Аналогично этому трансформируются и многие приемы информационной поддержки производства, в котором нет тиражируемости изделий. Именно в силу этого важнейшее значение приобретает использование систем автоматизированного проектирования и систем поддержки жизненного цикла изделия от формирования концепции до летных испытаний и/или утилизации. Причем, последняя задача решается не столь тривиально, как в автомобиле или даже авиастроении.
Специфика утилизации космического аппарата приводит к построению и предварительной отладке в наземных условиях сложнейших программ посадки (приземления) БПЛА или перевода его на орбиту захоронения. В любом случае для расчета подобных маневров необходимо с высокой точностью знать все текущие параметры аппарата. Дополнительную сложность подобных расчетов может составлять частичная потеря работоспособности систем БПЛА к завершению периода его эксплуатации. Обычно решение об утилизации аппарата принимается именно вследствие его частичной неисправности.
Поэтому в планах подготовки специалиста предусмотрены читаемые сотрудниками базового предприятия следующие дисциплины: «Основы
автоматизированного проектирования», «Основы информационной поддержки изделий», «Системы менеджмента качества». В настоящий момент значительная доля времени в курсе «Основы автоматизированного проектирования» посвящена вопросам проектирования цифровых устройств и собственно вычислителя, включая их разработку, моделирование, подготовку конструкторской документации и изготовление печатных плат, меньшая — конструкторской и технологической подготовке механообработки.
Однако и алгоритмическая, и программная составляющие системы управления БПЛА также интегрированы в автоматизированную систему проектирования и, соответственно, находят свое отражение в учебных курсах «Методы повышения надежности систем управления беспилотными летательными аппаратами» и «Проектирование комплексов управления беспилотными летательными аппаратами».
Технологические приемы и инструменты
Наконец, следует отметить некоторую «архитектурную» особенность систем управления космическими аппаратами, проистекающую из той же уникальности продукции. Суть ее в том, что часто до последнего момента не известны точные параметры всего беспилотного аппарата. Причина — распараллеливание разработки управляющей и функциональной аппаратуры. Как следствие, архитектура системы управления БПЛА должна предусматривать средства параметрической настройки в достаточно широком диапазоне, позволяющие конкретизировать значения параметров объекта управления как при конечной наземной компоновке космического аппарата, так и на начальных стадиях его эксплуатации.
Вторая сторона уникальности проявляется в организации процессов отладки и верификации системы управления. Специфика этих процессов заключается в отсутствии некоторых объектов управления, так сказать, вживую. На момент проведения разработки некоторые объекты управления могут находиться в стадии проектирования. Более того, для некоторых компонент могут отсутствовать адекватные модели объектов, из-за того, что они тоже находятся в стадии конструирования и/или производства. Вопросы исследования адекватности и сертификации моделей, применяемых при разработке СУ БПЛА, составляют одну из составных частей профильных курсов, читаемых преподавателями базовой кафедры. Соответственно, будущие специалисты должны быть обучены не только технологии
верификации, но и навыкам создания тестовой оснастки, имитационных комплексов, как в реальном, так и в модельном времени.
Тестирование программного кода рассматривается в учебных курсах как процесс выполнения программного кода, направленный на выявление существующих в нем дефектов. Под дефектом здесь понимается участок программного кода, выполнение которого при определенных условиях может привести к неожиданному поведению системы (т.е. поведению, не соответствующему требованиям). Неожиданное поведение программного обеспечения системы управления может приводить к сбоям в работе всего комплекса управления и отказам, в этом случае принято говорить о существенных дефектах программного кода. Отдельные дефекты вызывают незначительные проблемы, не нарушающие процесс функционирования всей системы, но несколько затрудняющие работу с ней. В этом случае говорят о средних или малозначительных дефектах.
При проектировании системы возможные отказы классифицируются по степени опасности (по уровням критичности). Для встроенного программного обеспечения принято выделять 5 уровней критичности - от катастрофического до не влияющего на характеристики системы. Детальность процесса тестирования тем выше, чем выше уровень потенциальных отказов.
Задача тестирования при таком подходе - это определение условий, при которых проявляются дефекты системы и протоколирование этих условий. В цели тестирования обычно не входит выявление конкретных дефектных участков программного кода и никогда не входит исправление дефектов - это задача отладки, которая выполняется по результатам тестирования системы.
Цель применения процедуры тестирования программного кода - минимизация количества дефектов, в особенности существенных, в конечном продукте. Тестирование, как процесс, само по себе не может гарантировать полного отсутствия дефектов в программном коде. Однако, в сочетании с процессами верификации и валидации, направленными на устранение противоречивости и неполноты проектной документации (в частности, требований на систему), грамотно организованное тестирование дает уверенность в том, что система удовлетворяет документированным требованиям и ведет себя в соответствии с ними во всех рассмотренных ситуациях.
При разработке систем повышенной критичности, например, авиационных, космических систем управления, гарантии качества достигаются при помощи четкой организации процесса тестирования, определения его связи с остальными процессами жизненного цикла, введения количественных характеристик, позволяющих оценивать успешность тестирования.
Таким образом, в учебном процессе рассматривается первую очередь не способ получения конкретных результатов тестирования отдельной системы, а общая организация процесса тестирования, проповедуя подход «хорошо организованный процесс дает качественный результат». Такой взгляд является общим для многих международных и отраслевых стандартов качества, которые более подробно рассматриваются уже на старших семестрах. Качество разрабатываемой системы при таком подходе является следствием организованного процесса разработки и тестирования, а не самостоятельным неуправляемым результатом.
На практике верификационные процедуры приходится выполнять на нескольких уровнях. Первичные стадии, в силу уникальности производства, имеют достаточно выраженный исследовательский характер и ориентированы на контроль отдельных блоков и алгоритмов. В процессе их выполнения собираются и обрабатываются данные, используемые на более поздних стадиях в качестве эталонных значений.
Спроектированная разработчиком электронная плата после изготовления попадает на верификацию в группу разработки, где устанавливается ее соответствие
требованиям, проводится необходимая доводка. Одним из результатов этого этапа является создание тестовой оснастки, выработка и утверждение методики производственных испытаний.
Параллельно с этим процессом производится разработка и реализация в программном коде алгоритмов. На первом этапе еще не используются коды целевого процессора. Верификационные процедуры направлены на контроль необходимой функциональности, оценки скорости и точности вычислений. В результате этих испытаний оказывается возможным рассчитать диапазоны и масштабы переменных, что позволяет потом автоматически сгенерировать целевой программный код.
Последующие верификационные процедуры носят в той или иной степени комплексный характер, так как одновременно затрагивают как программную, так и аппаратную составляющие системы управления.
Технологические приемы обучения
Учебный план подготовки специалистов по системам управления летательными аппаратами со специализацией «Системы управления беспилотными летательными аппаратами, включает сквозной курс «Учебно-исследовательская работа студентов» (УИРС) в объеме 2-х часов в неделю с 3 по 9 семестры. Проведение УИРС на младших курсах осложнено отсутствием у студентов знаний по специальности. Но при этом они получили базовую подготовку по разработке ПО и дискретной математике (отношения, логика и конечные автоматы).
Для адаптации студентов к будущей специализации на кафедре «Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов» в рамках УИРС студентам предлагается выполнить проектирование и последующую реализацию некоторой упрощенной встроенной системы реального времени (ВС РВ). Например, управление пуском зенитной ракеты по показаниям радиолокационной системы наблюдения. Термин «реальное время» в данном случае означает, что внешние условия изменяются в процессе функционирования системы и под ее непосредственным воздействием.
Разработка системы разбивается в рамках сквозного курса УИРС на три этапа: логическое проектирование, программная реализация и аппаратная реализация. Важным методическим приемом является то, что исходными данными очередного этапа являются результаты предыдущего этапа, подготовленные другим студентом. Таким образом, студент не только оказывается жестко ограниченным ранее сформулированными требованиями, но и вынужден сам учитывать при написании документации интересы участников разработки, продолжающих реализацию задуманной системы. В свою очередь и ему, как члену коллектива разработчиков приходится использовать материалы, подготовленные его коллегами со всеми их особенностями и недостатками. За период выполнения учебно-исследовательской работы каждый студент знакомится последовательно с тремя различными системами управления, принимая участие в их создании на разных этапах реализации.
На первом этапе выполнения УИРС обучающимися проводится исследование предметной области, фиксируются внешние связи (датчики и исполнительные механизмы) внешней среды, определяются требования к системе. В целях упрощения восприятия интерфейсы приводятся к бинарному типу (есть сигнал -1, нет сигнала -0). Логическое проектирование алгоритма работы системы управления выполняется в рамках модели конечного автомата. Для совмещения теории и практики при формирования логической модели рекомендуется в качестве инструментального средства использовать пакет StateFlъw системы МайаЬ. Построенная логическая модель системы верифицируется на соответствие требованиям. Результаты разработки фиксируются в форме отчета и сопроводительной документации.
На следующем этапе студенту предлагается по определенным другим автором требованиям произвести реализацию и тестирование программного обеспечения системы управления. Конкретизации подлежат интерфейсы программного обеспечения с внешним миром. Автор проекта должен принять решение о способе получения данных от различных датчиков системы. Например, появление самолета противника в охраняемой зоне характеризуется прерыванием, а для получения данных «свой/чужой» необходимо обратиться к функции Who, передав ей параметры идентификатора самолета.
Разработчиком формулируются функциональные требования и проектируется архитектура ПО, выполняется планирование и проведение верификации. Наличие предварительно сформулированных требований к системе является жестким ограничением реализации и тестирования программного продукта. В основу инструментальных средств поддержки учебно-исследовательской работы на данном этапе используется среда CodeBlocks.
Выполняя в этой среде тестирование разработанного программного обеспечения ВС РВ, студент должен разработать тест-план верификации. Обычно его пункты включают ссылки на проверяемые требования, спецификацию входных воздействий на систему и список ожидаемых реакций системы управления. В дальнейшем производится адаптация типовой среды тестирования - программного модуля драйвера, который читает подготовленные в текстовом файле исходные данные и подает их на вход тестируемого модуля. Оформление данных иллюстрировано рис.2.
Control.с Lights.h Sensors.h Time.h Driver.с Control.h testl.txt x |
1 |s 1 2 / Test for Lights Control Module with startup A_C 3 / Case 1 4 / Начальное состояние светофора установлено, малый интервал 5 / Test that the initial lights are turned ON 6 / Case 2 7 /При отсутствии движения, установлен мигающий желтый на минимальный интервал 8 10 0 0 9 / Case 3 10 / Большая интенсивность получает предпочтение, но интервал сохраняется
Рис. 2. Фрагмент тестовых данных ВС РВ «Светофор»
Строка входных данных, начинающаяся с символа I, определяет значения датчиков интенсивности движения на регулируемом перекрестке. В процессе тестирования программный код ВС РВ обращается к моделям внешних устройств -датчиков, считывающих значения из входной строки. По заданным алгоритмам формирует управляющие воздействия на модели исполнительных устройств (лампочки светофора, реле временной задержки и т.п). Программный комплекс, имитирующий работу исполнительных механизмов, выводит соответствующие сообщения в протокол тестирования (Рис.3).
1 ------------ Lights Control Module Test Protocol ------------
2 Input data file = testl.txt
3 Protocol file = protl.txt
4 (1) Startu mode is 1
5 The color now is «GREEN»
6 Time Interval 30 ceconds. Total time 0 ceconds
7 / Test for Lights Control Module with startup A_C
8 / Case 1
9 / Начальное состояние светофора установлено, малый интервал
10 / Test that the initial lights are turned ON
11 / Case 2
12 /При отсутствии движения, установлен мигающий желтый на минимальный интервал
13 I А_С = 0, B_D = 0, Manual = 0
14 The color now is «BLINK»
15 Time Interval 30 ceconds. Total time 30 ceconds
16 / Case 3
17 / Большая интенсивность получает предпочтение, но интервал сохраняется
18 I А_С = 1, B_D = 0, Manual = 0
19 The color now is «GREEN»
20 Time Interval 30 ceconds. Total time 60 ceconds
Рис 3. Фрагмент протокола верификации ВС РВ «Светофор» в среде тестирования
Для поддержки коллективной работы на кафедре развернута информационная сеть, работающая под управлением операционной системы Debian. Созданная информационная среда позволяет поддерживать как индивидуальные рабочие пространства разработчиков, так и общие рабочие области, обеспечивающие возможность принимать согласованные проектные решения.
Следующий этап - аппаратная реализация по «чужой» спецификации. При этом внимание уделяется не только функциональным требованиям, но и проработке аппаратных интерфейсов. Так же как и на предыдущем этапе, внешняя аппаратура заменяется на стендах ее моделями, которые, однако, позволяют представлять звуковые и световые сигналы, различные исполнительные механизмы. В качестве инструментальных средств на данном этапе применяется среда ALTIUM DESIGNER и отладочный набор DE2 фирмы Altera.
Для информационной поддержки коллективной многошаговой разработки ВС РВ на кафедре развернута среда, автоматизирующая процесс выдачи индивидуальных работ студентам и сбор выполненных контрольных заданий преподавателем. Общая схема системы представлена на рис.4.
Выдача работ
Рабочая область преподавателя
Выполнение ы
База вариантов контольных работ
Тема 1
Тема 10
Собранные работы
Тема 1, Тема 1, Тема 2,
Вариант 1 Вариант 2 Вариант 3
Иванов Петров Сидоров
Иванов
(студент)
Сбор выполненных работ Рис.4. Схема информационной поддержки групповых занятий
Данное приложение поддерживает работу в системе четырех основных типов пользователей:
• программист - роль, относящаяся к сотруднику кафедры, который выполняет разработку прикладной инструментальной системы и расширяет ее функциональность;
• преподаватель - роль, которой предоставляются права и средства поддержания базы вариантов индивидуальных заданий, распределения вариантов работ по студентам, сбора результатов выданных работ и проверки их;
• студент - роль, которой позволяется просматривать список полученных вариантов заданий и возвращать результаты выполненных работ преподавателю;
• секретарь - роль, выполняемая сотрудником кафедры, которому предоставлены права регистрации новых пользователей в системе.
Секретарь в начале каждого семестра регистрирует новых пользователей в системе: преподавателей и студентов. При этом каждому из них присваивается свой идентификатор и пароль входа (рис. 5) .
Введите имя пользователя для добавления и нажмите Епгег или просто нажмите Епъег
для возвращения в главное меню.
з1пдхзуп
New SMB password:
Retype new SMB password: Added user sinitsyn.
Рис. 5. Пример регистрации нового пользователя
Фактически, кроме предоставления соответствующих прав доступа, каждому пользователю создается своя персональная область на сервере кафедры, которая сохраняется на все время его работы в системе. Для студентов это понимается как все время обучения их на кафедре.
Среда информационной поддержки предоставляет средства для хранения базы вариантов индивидуальных работ, сгруппированных по темам. Каждая тема должна иметь уникальный номер, каждый вариант - номер, уникальный в пределах темы.
Для поддержки работы студентов в системе каждому из них выделяется рабочая область, в которую преподавателем помещаются варианты работ, предназначенных для выполнения. Внутри рабочей области студента выделяется отдельная область, в которую он помещает результаты выполненных работ. Именно из этой области преподаватель забирает данные на проверку, перемещая их в свою рабочую область. До появления данных в области результатов работа считается невыполненной. То есть ко всем остальным данным в рабочей области студента система относится как к черновикам, не подлежащим проверке
Таким образом, в среде информационной поддержки выделяются следующие основные объекты, поддерживаемые системой:
• база индивидуальных заданий (контрольных работ) - основное хранилище информации о доступных вариантах, в котором объектом хранения является вариант, а варианты, в свою очередь, группируются по темам;
• рабочая область студента - хранилище вариантов заданий, выданных студенту, а основным объектом данных является вариант контрольного задания (области разных студентов взаимно недоступны);
• область готовых работ студента - хранилище сформированных студентом результатов работ, готовых для проверки (заполняется студентом, но не подлежит последующему изменению);
• рабочая область преподавателя - хранилище результатов работ, собранных у студентов (недоступна ни другим преподавателям, ни студентам);
• вариант индивидуальной работы (контрольного задания) - область хранения индивидуального задания студента (не подлежит изменению для роли «студент»).
В рамках системы реализована простая система оповещения об изменениях некоторых областей. Например, при появлении нового варианта задания в файл сообщений студента добавляется соответствующая запись, а при появлении новых данных результатов производится информирование преподавателя, ответственного за данную тему.
Данная система, как отмечалось выше, обеспечивает выполнение заданий по УИРС (рис. 6), облегчая контроль текущего состояния проекта.
>
Имя Дата изменения
УИРС_идЫ:5_Ехатр1е 11.06.201412:П
УИР_4 Постановки задач 11.06.201412:21
УИРС Антонюк Ю. А 11.06.2014 12:20
УИРС Воронцов 11.06.201412:20
УИРС Гузик 29.05.201412:27
УИРС Калачева Д 29.05201412:27
УИРС Новова 29.05.2014 12:27
УИРС Орлюк 29.05.201412:27
УИРС Свиридов А.Р 11.06.2014 12: Л
УИРС Таранов А. М_ 11.06.2014 12:21
УИРС Форматоров 11.06.2014 12:21
УИРС4 Лекция 1 Проектирование ПO.ppt 27.11.201317:10
Рис. 6. Структура области заданий в среде информационной поддержки
Студенту предписывается пройти определенные стадии проектирования в определенные сроки. Так, например, к концу февраля должны быть описаны интерфейсы программного модуля ВС РВ, а к середине апреля - определены функциональные требования. Контролируя области результатов, преподаватель имеет объективную картину состояния работ по каждому студенту и по группе.
Вспомогательные программные средства позволяют преподавателю получить отчет о состоянии рабочих областей на любой момент времени. Конечно, содержательный контроль содержимого областей результатов - дело преподавателя, но отсутствие возможности корректировать результаты (студент может только создать новую версию) снимает проблемы восстановления хронологии работы и позволяет проводить объективную оценку с учетом установленного графика выполнения.
В целом курс формирует у студента ясное представление об основных этапах и инструментах разработки ПО ВС РВ, давая одновременно базовые навыки работы в коллективе.
Заключение
Таким образом, работа предлагает к обсуждению структуру учебного плана и приемы его реализации, ориентированные на формирование специалистов высокой квалификации, практически владеющих технологиями базового предприятия, работающего в высокотехнологичной космической отрасли. Практическое воплощение предлагаемых организационных и технологических приемов опирается на весьма значительную взаимную заинтересованность учебного заведения и базового предприятия в достижении конечного результата.
ВУЗу приходится со своей стороны формировать потоки студентов и подстраивать расписание занятий для учета возможностей аудиторного фонда базового предприятия, фактической загруженности его производственных мощностей, используемых в качестве лабораторной базы. Кроме того, в своей организационной работе факультету и кафедрам - партнерам необходимо учитывать территориальную удаленность коллектива базовой кафедры, который большую часть своего времени проводит вне стен университета.
Базовое предприятие, со своей стороны, вынуждено создавать на своей территории дополнительный фонд помещений для проведения занятий со студентами базовой кафедры, библиотечный фонд учебной литературы по профилю подготовки, предусматривать резервы времени своих производственных комплексов для обеспечения поддержки учебного процесса. Кроме того, особенно на начальном этапе формирования кафедры (от 3-х до 5-ти лет), предприятию приходится нести дополнительное финансовое бремя для обеспечения внебюджетного финансирования преподавателей базовой кафедры из-за нехватки учебной нагрузки. Добавим сюда финансовое поощрение сотрудников, оказывающих помощь в руководстве индивидуальными проектами студентов и их дипломными работами.
Важным фактором формирования специалиста является то, что согласованное междисциплинарное взаимодействие преподавателей в рамках самостоятельной учебно-исследовательской работы студентов позволяет проводить последовательное вовлечение обучающихся в технологические циклы базового предприятия. При этом использование результатов предшествующего этапа жизненного цикла, полученных другим исполнителем, существенно приближает студента к реальным условиям производства, вовлекая его в круг коллективной разработки изделия. Полученные в процессе обучения навыки активно закрепляются в условиях работы студентов по договорам с базовым предприятием. На текущий момент более 80% обучающихся уже работают в производственных подразделениях, практически используя полученные в процессе обучения знания.
Наконец, заметим, что созданная информационная среда поддержки компьютерного выполнения индивидуальных заданий предоставляет возможность организации коллективной работы студентов под управлением преподавателя. Функционирующее под управлением системы Debian приложение поддерживает ролевую структуру пользователей с определенными правами доступа и позволяет собирать объективную информацию о хронологии выполнения студенческих проектов. Текущий опыт ее применения определил некоторые пути дальнейшего развития системы. Так в настоящее время подготавливается набор средств автоматизации вычисления рейтинговых оценок. Предполагается введение роли «инспектор» со средствами сбора обобщенных отчетов по всей совокупности тем (дисциплин), поддерживаемых системой.
Литература
1. Синицын С.В., Соколов В.Н., Попов Б.Н., Сыров А.С.. Особенности подготовки специалистов для разработки бортовых систем управления космическими аппаратами: Преподавание информационных технологий в Российской Федерации. Материалы IX Всероссийской конференции,- Саратов: ООО «Издательский центр “Наука” », 2011. - 172с.: ил., стр. 96 - 98.
2. Порешин П.П., Попов Б.Н. Дискретная математика: множества, отношения, логика, автоматы. Учебное пособие/ - М.:МОКБ Марс». 2012. - 172 с.: ил.
3. Синицын С.В., Батаев А.В., Налютин Н.Ю. Операционные системы : Учебник для студ. высш.учеб. заведений /,- М.:Издательский центр «Академия», 2010 -304с.
4. Синицын С.В., Хлытчиев О.И. Основы разработки программного обеспечения на примере языка Си. Учебник./ -2-е изд., испр. - М.: национальный открытый Университет «ИНТУИТ», 2013. - 220 с.: ил.
5. «Буран». Основы проектирования интеллектуальной системы управления орбитальным кораблем на атмосферном участке полета/.Под редакцией А.С.Сырова. - М.: Машиностроение, 2013, 276 с.: ил.
6. Проектирование и испытание бортовых систем управления: Учебное пособие под редакцией А.С.Сырова — М.: Изд-во МАИ-ПРИНТ, 2011. -344 с.: ил.
7. Система управления разгонным блоком: Учебное пособие / Андреев В.П., Бонк Р.И., Бровкин А.Г. и др./ др. под редакцией А.С.Сырова — М.: Изд-во МАИ-ПРИНТ, 2010. -272 с.: ил.
8. Бортовые системы управления космическими аппаратами: Учебное пособие / Бровкин А.Г., Бурдыгов Б.Г., Гордийко С.В. И / др. под редакцией А.С.Сырова — М.: Изд-во МАИ-ПРИНТ, 2010. -304 с.: ил.
9. Рекомендации по преподаванию программной инженерии и информатики в университетах = Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering; Computing Curricula 2001: Computer Science: пер. с англ. - М.: ИНТУИТ.РУ “Интернет-Универсистет Информационных Технологий», 2007.- 462с.: ил.
