Разработка алгоритмов поиска оптимального маршрута для БЛА при наблюдении им подвижных наземных объектов
Обзор существующих методов и подходов к планированию групповых действий. Разработка модели одиночных и групповых действий беспилотного летающего аппарата. Создание программы и ее экономическая целесообразность. Модели качества процессов конструирования.
| Рубрика | Транспорт |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 07.02.2013 |
| Размер файла | 2,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
· причина найдена, исправлена, уничтожена;
· причина не найдена.
Во втором случае отладчик может предполагать причину. Для проверки этой причины он просит разработать дополнительный тестовый вариант, который поможет проверить предположение. Таким образом, запускается итерационный процесс коррекции ошибки.
Возможные разные способы проявления ошибок:
· программа завершается нормально, но выдает неверные результаты;
· программа зависает;
· программа завершается по прерыванию;
· программа завершается, выдает ожидаемые результаты, но хранимые данные испорчены (это самый неприятный вариант).
Характер проявления ошибок также может меняться. Симптом ошибки может быть:
· постоянным;
· мерцающим;
· пороговым (проявляется при превышении некоторого порога в обработке - 200 самолетов на экране отслеживаются, а 201-й - нет);
· отложенным (проявляется только после исправления маскирующих ошибок).
В ходе отладки мы встречаем ошибки в широком диапазоне: от мелких неприятностей до катастроф. Следствием увеличения ошибок является усиление давления на отладчика. Часто из-за этого давления разработчик устраняет одну ошибку и вносит две новые ошибки.
Английский термин debugging (отладка) дословно переводится как «ловля блох», который отражает специфику процесса - погоню за объектами отладки, «блохами». Рассмотрим, как может быть организован этот процесс «ловли блох».
Различают две группы методов отладки:
· аналитические;
· экспериментальные.
Аналитические методы базируются на анализе выходных данных для тестовых прогонов. Экспериментальные методы базируются на использовании вспомогательных средств отладки (отладочные печати, трассировки), позволяющих уточнить характер поведения программы при тех или иных исходных данных.
Общая стратегия отладки - обратное прохождение от замеченного симптома ошибки к исходной аномалии (месту в программе, где ошибка совершена).
В простейшем случае место проявления симптома и ошибочный фрагмент совпадают. Но чаще всего они далеко отстоят друг от друга.
Цель отладки - найти оператор программы, при исполнении которого правильные аргументы приводят к неправильным результатам. Если место проявления симптома ошибки не является искомой аномалией, то один из аргументов оператора должен быть неверным. Поэтому надо перейти к исследованию предыдущего оператора, выработавшего этот неверный аргумент. В итоге пошаговое обратное прослеживание приводит к искомому ошибочному месту.
В разных методах прослеживание организуется по-разному. В аналитических методах - на основе логических заключений о поведении программы. Цель - шаг за шагом уменьшать область программы, подозреваемую в наличии ошибки. Здесь определяется корреляция между значениями выходных данных и особенностями поведения.
Основное преимущество аналитических методов отладки состоит в том, что исходная программа остается без изменений.
В экспериментальных методах для прослеживания выполняется:
· Выдача значений переменных в указанных точках;
· Трассировка переменных (выдача их значений при каждом изменении);
· Трассировка потоков управления (имен вызываемых процедур, меток, на которые передается управление, номеров операторов перехода).
Преимущество экспериментальных методов отладки состоит в том, что основная рутинная работа по анализу процесса вычислений перекладывается на компьютер. Многие трансляторы имеют встроенные средства отладки для получения информации о ходе выполнения программы.
Недостаток экспериментальных методов отладки - в программу вносятся изменения, при исключении которых могут появиться ошибки. Впрочем, некоторые системы программирования создают специальный отладочный экземпляр программы, а в основной экземпляр не вмешиваются. (С.А, 2003) [13]
4.3 Сертификация бортового программного обеспечения
Под понятием «программное обеспечение, критичное с точки зрения безопасности» (Safety-Critical Software - для краткости будем называть его «критичное программное обеспечение») обычно понимают такое программное обеспечение, которое влияет на поведение систем, сбой которых может повлечь риск для человеческих жизней.
Иногда этим же термином называют программы, разработанные в соответствии со специальными стандартами, принятыми для критически важных областей.
Главным препятствием, стоящим на пути применения «коробочных» программных продуктов в критических областях, является недостаточная информация о «родословной» изделий, т.е. о процессах разработки, тестирования, верификации и управления качеством и т.п. Эту проблему в значительной мере решает как лицензирование деятельности предприятий, так и сертификация соответствующей продукции на соответствие определенным требованиям, сформулированным, как правило, в виде стандартов или иных руководящих документов. К функциональной безопасности программного обеспечения имеет отношение ряд международных и национальных, общих и отраслевых стандартов, регламентирующих жизненный цикл технических систем. Основные из этих стандартов подробно рассмотрены в работе «Технологические процессы и стандарты обеспечения функциональной безопасности в жизненном цикле программных средств» (В.В Липаев). Мы же рассмотрим такой важный аспект разработки критичного программного обеспечения, как тестирование.
Тестирование является одним из видов верификации и направлено на определение того, соответствует ли программное обеспечение требованиям спецификации. Каким же образом можно понять, следует ли доверять проведенному тестированию или нет?
ГОСТ Р ИСО/МЭК 15408 (известный под названием «Общие критерии») в отношении тестирования вводит понятия «Покрытие» и «Глубина». Покрытие показывает полноту охвата тестами (т.е. покрытие тестами) функциональных возможностей объекта оценки, а глубина характеризует уровень детализации тестирования. При оценке корректности тестирования за рубежом часто используют классификацию и требования, установленные в стандарте DO-178B «Software Considerations in Airborne Systems and Equipment Certification» («Оценки программного обеспечения для сертификации бортовых авиационных систем и оборудования»), известный в Европе как ED-12B. DO-178B исходит из того, что при эксплуатации системы существуют потенциальные угрозы безопасности, возникающие при сбое программного обеспечения (например, останов двигателей самолета в полете), и возможных последствий такого сбоя.
Сертификация программного обеспечения на соответствие DO-178B, по сути дела, заключается в проверках, как реализованы средства предотвращения угроз. Очевидно, что, с одной стороны, не всегда ошибка в программе приводит к сбою системы, с другой стороны, сбой системы может произойти по причине, независящей от программы.
Поэтому сертификация программного обеспечения отдельно от системы, в состав которой она входит, не имеет смысла.
Исходя из возможных последствий сбоя, DO-178B определяет уровни опасности и соответствующие им уровни сертификации программного обеспечения (см. таблицу 4.3.1).
Таблица 4.3.1 Уровни сертификации программного обеспечения
|
Уровень |
Влияние на безопасность |
|
|
A |
Программное обеспечение, сбой которого может привести к возникновению или способствовать возникновению катастрофического сбоя самолета. |
|
|
B |
Программное обеспечение, сбой которого может создать условия или способствовать созданию условий для опасного сбоя |
|
|
C |
Программное обеспечение, сбой которого может создать условия или способствовать созданию условий для крупного сбоя |
|
|
D |
Программное обеспечение, сбой которого может создать условия или способствовать созданию условий для малозначительного сбоя |
|
|
E |
Программное обеспечение, сбой которого не может влиять на самолет или на нагрузку пилота |
DO-178B требует, чтобы каждая строка кода была выполнена в ходе тестирования.
Запрещается включение в состав приложения какого-либо дополнительного кода, не прошедшего тестирование. Для каждого уровня сертификации заданы свои требования к покрытию тестами проверяемого кода:
1. Покрытие операторов (Statement Coverage - SC) означает, что в ходе тестирования каждый оператор программы был вызван или использован не менее одного раза. Когда говорят о покрытии кода - «Code coverage» - обычно имеют ввиду именно SC.
2. Покрытие ветвей (Decision Coverage - DC) означает, что в ходе тестирования каждая точка входа в программу и выхода из нее была использована не менее одного раза так, что каждое возможное значение логических условий принималось не менее одного раза. По сути дела, это означает, что в ходе тестирования каждое логическое условие имело и значение «истина», и значение «ложь».
3. Покрытие условий и ветвей (Modified Condition/Decision Coverage - MC/DC) означает, что в ходе тестирования каждая точка входа в программу и выхода из нее была использована не менее одного раза так, что каждое решение в программе принимало все возможные значения, и при этом было показано, какое влияние оказывает на решение каждое условие независимо от остальных условий. Для сложных логических операций необходимо разрабатывать таблицы истинности, что бы определить все возможные комбинации значений «истина» и «ложь».
В таблице 3.4.2 показано, какие из требований к покрытию кода тестами предъявляются на разных уровнях сертификации:
Таблица 4.3.2 Требования к покрытию кода
|
Уровень |
Покрытие |
Требования к покрытию |
|
|
A |
MC/DC |
Уровень B + 100% MC/DC |
|
|
B |
DC |
Уровень C + 100% DC |
|
|
C |
SC |
Уровень D + 100% SC |
|
|
D |
100% покрытие требований |
||
|
E |
Нет требований |
Наверное, трудно представить себе коммерческую разработку, к которой предъявляются требования по уровню E. Сертификация же программного обеспечения по уровню D имеет родственников в российской практике: приемо-сдаточные испытания и проверка соответствия реальных возможностей декларированным. Проверки по уровням A, B и C невозможны без специализированных инструментальных средств.
Разумеется, реализация требований DO-178B (впрочем, как и других нормативных документов) приводит к существенному увеличению стоимости продуктов, что связано со значительными затратами на разработку дополнительных тестов, проведения дополнительных процедур тестирования и на разработку дополнительной технической документации. В связи с этим на рынке программного обеспечения существуют инструментальные средства, помогающие автоматизировать процесс верификации программ. Такие инструменты могут поставляться как штатные компоненты в составе интегрированных сред разработки, так и в виде специализированных инструментов. [14]
4.4 Модели качества процессов конструирования
В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон.
Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.
Базовым понятием модели СММ считается зрелость компании. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.
Напротив, в зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения.
Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов.
Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости и предусмотрен плавный, поэтапный подход к совершенствованию процессов - можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости.
Начальный уровень (уровень 1) означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный характер. Результат работы целиком и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается.
Для перехода на повторяемый уровень (уровень 2) необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов.
Следующий, определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.
С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.
Высший, оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.
Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:
· предотвращения дефектов;
· управления изменениями технологии;
· управления изменениями процесса.
Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ. [12]
Список литературы
1. Росс Клемент «Генетические алгоритмы: почему они работают? когда их применять?», Компьютерра №11/1999
2. Кормен, Т., Лейзерсон, Ч., Ривест, Р., Штайн, К «Алгоритмы: построение и анализ»/ Под ред. И.В. Красикова. - 2-е изд. - М.: Вильямс, 2005.
3. P.B. Sujit A. Sinha D. Ghose «Multiple UAV Task Allocation using Negotiation» AAMAS '06: Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems New York, NY, USA: ACM Press (2006), p. 471-478.
4. R. Nallusamy, K. Duraiswamy, R. Dhanalaksmi, P. Parthiban «Оptimization of non-linear multiple traveling salesman problem using k-means clustering, shrink wrap algorithm and meta-heuristics», International Journal of Nonlinear Science Vol.8 (2009) No.4, pp.480-487
5. Glover, F. «Tabu Search - Part I», ORSA Journal on Computing 1989 1: 3, 190-206.
6. Головко В.А. «Нейронные сети: обучение, организация и применение», М.:ИЖПР, 2001
7. Дьяконов В.П. MATLAB 7.*/R2006/2007. Самоучитель. - М.: «ДМК-Пресс», 2008.
8. СанПиН 2.2.2/2.4.2198-07 (изменение №1 к СанПиН 2.2.2/2.4.1340-03) «Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организация работы»
9. ГОСТ Р 50948-2001 «Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности»
10. Соснин П.И. Вербиченко Д.С. «Методы и средства активизации внимания в человеко-компьютерном взаимодействии»
11. Жоголев Е.А. «Лекции по технологии программирования», ВМК МГУ, 2000
12. Гагарина Л.Г. «Технология разработки программного обеспечения» М.: Форум Инфра-М, 2009
13. Орлов С.А. Технологии разработки программного обеспечения: Учебное пособие. 2-е изд. СПб.: Питер, 2003.
14. Брауде Э.Д. «Технология разработки программного обеспечения», СПб.: Питер, 2004
15. Золотарев С.В. «LynxOS-178 - коммерческая ОСРВ для авиации». - PC Week/RE, №22/2005.
Размещено на Allbest.ru
Подобные документы
Разработка и внедрение программы моделирования системы автоматического управления взлетом самолетного типа для беспилотного летательного аппарата. Обзор и анализ существующих БЛА среднего класса аэродромного базирования, выбор оптимального способа взлета.
дипломная работа [4,9 M], добавлен 07.02.2013Службы и основные организации, участвующие в аварийно-спасательных мероприятиях. Инструкция А-3 "Ожидаемая посадка аварийного воздушного судна". Процедура Б-4 "Обслуживание пострадавших". Тренировка персонала для выполнения аварийного плана аэропорта.
курсовая работа [71,2 K], добавлен 21.02.2011Условия осуществления капитального ремонта полнокомплектных автомобилей. Восстановление деталей с применением полимерных материалов, проектирование типовых и групповых технологических процессов. Разработка основных участков авторемонтных предприятий.
реферат [21,1 K], добавлен 22.04.2011Средства передачи с борта и их характеристики. Методы и алгоритмы повышения разборчивости речи. Свойства речевых сигналов и слуха, влияющие на нее. Анализ акустических шумов в кабине летательного аппарата. Разработка модели формирования "очищенной" речи.
дипломная работа [4,3 M], добавлен 19.03.2015Обоснование выбора поставщика, маршрута доставки. Характеристика проектной ситуации. Формирование блока исходных данных. Выбор поставщика и маршрута. Определение оптимального маршрута перевозки груза по наземному участку, типа автотранспортного средства.
курсовая работа [141,5 K], добавлен 12.02.2009Функции пассажирского автомобильного транспорта. Обеспечение удовлетворения потребностей населения в перевозках, качества обслуживания и эффективного использования подвижного состава. Снижение транспортных затрат. Разработка автобусного маршрута.
дипломная работа [354,9 K], добавлен 21.03.2012Понятие эргономичности пользовательского интерфейса. Подсистема создания, редактирования и визуализации маршрута беспилотного летательного аппарата на цифровой карте местности. Требования к программной архитектуре подсистемы. Средства и порядок испытаний.
дипломная работа [6,3 M], добавлен 06.07.2012Описание недостатков существующих конструкций амортизаторов. Разработка вариантов улучшения конструкций. Проект модернизации подвески трактора с вводом новых элементов. Обзор усовершенствований модели подвески трактора с гидравлическим амортизатором.
дипломная работа [8,7 M], добавлен 01.08.2011Развитие пассажирского автотранспорта. Организационное функционирование на транспортном предприятии ООО "Форсаж-Плюс". Возможности глобальных навигационных систем. Расчет рентабельности после нововведений. Разработка информационной модели предприятия.
дипломная работа [320,1 K], добавлен 23.07.2015Разработка модели транспортной сети и маршрутов движения между корреспондирующими пунктами. Сравнительный анализ маршрутов. Выбор транспортного средства на основе анализа свойств грузов, а также условий транспортировки. Разработка схем укладки грузов.
курсовая работа [8,5 M], добавлен 24.12.2012
