RU2454706C2 - Способ отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для его осуществления - Google Patents

Abstract

Изобретение относится к области обеспечения безопасности функционирования бортовой электронной системы. Техническим результатом является повышение надежности функционирования бортовой системы за счет повышения эффективности отладки программного обеспечения со сложной логикой. Способ отладки заключается в структурированном выполнении программы путем функциональной разметки нормального пути выполнения при помощи векторов состояния меток на функциональные блоки, а при обнаружении ошибки выполнять поиск функционального интервала нарушения на основании векторов состояния меток, обратное выполнение программы в этом функциональном интервале нарушения и определение и исправление ошибки. Устройство, моделирующее работу бортовой системы, содержащее процессор, осуществляющий способ отладки. 3 н. и 7 з.п. ф-лы, 3 ил.

Description

Настоящее изобретение относится к области обеспечения безопасности функционирования систем, когда работа этих систем зависит от исполнения последовательностей логических команд в вычислительном устройстве.

В частности, объектом настоящего изобретения является способ отладки функционального программного обеспечения системы, которая должна исполнять последовательности логических команд, в частности системы с повышенными требованиями безопасности, такой как бортовая электронная система, предназначенная для установки на борту летательного аппарата.

Способ позволяет разработчику получить возможность поиска и исправления ошибок в последовательностях логических команд функционального программного обеспечения бортовых систем. Настоящее изобретение находит свое предпочтительное, но не ограничительное применение в области авиации и, в частности, в области осуществления тестов функционального программного обеспечения бортовых систем.

Из соображений обеспечения безопасности системы, предназначенные для установки на борту летательного аппарата, подвергают проверкам на хорошую работу, во время которых необходимо убедиться, что указанные системы отвечают требованиям сертификации, прежде чем летательный аппарат, оборудованный такими системами, получит разрешение на полеты и тем более на коммерческую эксплуатацию.

В настоящее время до установки на борту эти системы предварительно подвергают многочисленным тестам для проверки их соответствия требованиям целостности и безопасности, предъявляемым, среди всех прочих, сертификационными органами. Этими бортовыми системами могут быть, в частности, специализированные вычислительные устройства, предназначенные для реализации функций, которые могут иметь первостепенное значение для летательного аппарата, например функций пилотирования. В дальнейшем тексте описания эти системы будут называться вычислительными устройствами.

Чаще всего в архитектуре современных систем каждое вычислительное устройство предназначено для одного применения или для нескольких однотипных применений, например для управления полетом. Каждое вычислительное устройство имеет аппаратную часть и программную часть. Аппаратная часть содержит, по меньшей мере, один центральный блок обработки (CPU) и, по меньшей мере, один блок входов/выходов, через который вычислительное устройство связано с сетью вычислительных устройств, с внешними периферийными устройствами и т.д.

Основной признак бортовых систем, часто применяемых в области авиации, связан с архитектурой как аппаратной, так и программной, которая позволяет по мере возможности избежать введения любого средства, необязательного для выполнения функций, выделенных для указанных систем.

Таким образом, в отличие от наиболее распространенных систем, вычислительное устройство в авиации не имеет сложной операционной системы. Кроме того, программное обеспечение реализуют на языке, наиболее близком к языку, воспринимаемому центральным блоком обработки, и единственными имеющимися входами/выходами являются входы/выходы, необходимые для функционирования системы, например данные, поступающие от датчиков или других элементов летательного аппарата, или данные, направляемые на приводы или другие элементы.

Преимущество этого типа архитектуры связано с тем, что работа такой системы намного легче поддается контролю. Она не зависит от сложной операционной системы, некоторые аспекты функционирования которой зависят от не контролируемых параметров и к которой в противном случае следовало бы предъявлять те же требования безопасности, что и к прикладным программам. Система является более простой и менее уязвимой, так как она содержит только средства, строго необходимые для выполнения функций, выделенных для указанной системы.

С другой стороны, работу такой системы намного труднее отслеживать. Например, система не содержит обычных интерфейсов человек/машина, таких как клавиатура и экраны, позволяющие отслеживать правильный ход последовательностей команд и воздействовать на этот ход, что затрудняет проверки, необходимые во время разработки, тестирования и квалификации программного обеспечения.

Программная часть вычислительного устройства содержит программное обеспечение, которое является специфическим для рассматриваемого применения, которое обеспечивает работу вычислительного устройства и логические команды которого соответствуют алгоритмам, определяющим функционирование системы.

Чтобы получить сертификацию системы, прежде чем ввести ее и сам летательный аппарат в эксплуатацию, осуществляют фазу аттестации вычислительного устройства.

Как известно, обычно на каждом этапе процесса реализации вычислительного устройства фаза аттестации состоит в проверке его соответствия спецификациям, разработанным для того, чтобы указанное вычислительное устройство отвечало ожидаемому функционированию системы.

Эту проверку на соответствие спецификациям производят, в частности, для программного обеспечения путем последовательных этапов от проверки наиболее простых компонентов программы до проверки всего программного обеспечения, включая все компоненты, которые должны быть интегрированы в соответствующее вычислительное устройство.

На первом этапе самые простые элементы программного обеспечения, которые можно проверить, подвергают тестам, называемым унитарными тестами. В ходе этих тестов проверяют, чтобы логические команды, то есть коды каждого из указанных программных элементов соответствовали концептуальным требованиям.

На втором этапе, называемом этапом интеграции, различные программные компоненты, каждый из которых прошел индивидуальную проверку, интегрируют для получения комплекса, в котором программные компоненты взаимодействуют друг с другом. Эти различные программные компоненты подвергают интеграционным тестам, в ходе которых проверяют, чтобы программные компоненты были совместимыми, в частности, на уровне функциональных интерфейсов между указанными компонентами.

На третьем этапе комплекс программных компонентов интегрируют в соответствующее вычислительное устройство, для которого они предназначены. При этом проводят аттестационные испытания, которые призваны подтвердить, что программное обеспечение, образованное комплексом компонентов, интегрированных в вычислительное устройство, соответствует спецификации, то есть выполняет ожидаемые функции, и что оно работает надежно и безопасно.

Чтобы гарантировать надежность программного обеспечения и его соответствие сертификационным требованиям, во время этого этапа аттестации необходимо также подтвердить, что совокупность тестов, которым было подвергнуто программное обеспечение, позволяет с определенной уверенностью сделать вывод о соответствии программного обеспечения требованиям безопасности, предъявляемым к системе, в которую включено это программное обеспечение.

Различные тесты, проводимые во время фазы аттестации на программном обеспечении, позволяют убедиться, что не может произойти какого-либо сбоя в работе указанного программного обеспечения (который может сказаться на нормальной работе вычислительных устройств и в дальнейшем на самом летательном аппарате и на его безопасности) и что, даже если произойдет какое-либо нарушение, программное обеспечение сможет его устранить.

Вместе с тем, во время фазы аттестации и особенно во время операций исследования, когда выявляются нарушения, часто необходимо убедиться, что не только входные и выходные параметры вычислительного устройства, в котором установлено программное обеспечение, отвечают ожиданиям, но что и определенные внутренние аспекты поведения программного обеспечения являются корректными.

В этом случае, учитывая специфическую архитектуру вычислительных устройств, предназначенных для применения в бортовых системах, обычно трудно отслеживать работу программного обеспечения без использования специальных устройств и методов.

Первый известный метод состоит в применении систем распределения файлов между тестируемым вычислительным устройством, содержащим установленное программное обеспечение, и соответствующей платформой и в использовании эмуляторов. Под эмулятором следует понимать устройство, позволяющее моделировать на соответствующей плате логическое функционирование вычислительного блока или процессора вычислительного устройства.

В таком варианте работы с эмулятором процессор вычислительного устройства заменяют логическом щупом, который выполняет роль интерфейса с соответствующей платой, на которой производят эмуляцию процессора.

Таким образом, можно запустить программное обеспечение, предназначенное для тестирования на вычислительном устройстве, кроме части процессора, и при помощи собственных функций соответствующей платы наблюдать за работой или за некоторыми внутренними нарушениями в работе программного обеспечения, например, при реакции на моделирование входов входных/выходных блоков в дополнение к отслеживанию выходов указанных входных/выходных блоков.

Этот первый метод имеет определенные недостатки. Действительно, каждый тип тестируемого вычислительного устройства требует наличия специального испытательного стенда или, по крайней мере, специальной конфигурации испытательного стенда. Испытательным стендом является комплекс, содержащий, в частности, средства подключения к тестируемому вычислительному устройству, средства для эмуляции процессора или процессоров вычислительного устройства или для выполнения тестовых программ.

Поскольку каждый процессор требует наличия специального эмулятора, то как для программы эмуляции, так и для щупа, подключаемого вместо процессора, необходимо увеличивать число эмуляторов в соответствии с определениями вычислительных устройств.

Кроме того, как правило, возможности исследования при помощи эмуляторов остаются ограниченными. К тому же необходимость работы на специфическом языке рассматриваемого процессора предполагает, что разработчик должен быть специалистом в программировании на машинном языке.

Кроме того, эмуляторы являются дорогими устройствами, которые выпускают в небольших количествах. Срок службы такого устройства является очень коротким (от 6 месяцев до 2 лет), тогда как поддерживать средства разработки и проверки в рабочем состоянии необходимо (регламенты, реагирование промышленности) в течение всего срока разработки самолета (20 лет и даже больше). Это выражается в проблемах морального износа, которые становится все сложнее решать.

Таким образом, это решение с использованием эмулятора не представляется идеальным, поскольку, не говоря уже об ограниченных возможностях с точки зрения исследования, оно является дорогим во внедрении и в поддержке.

На стоимость влияет также то, что, как правило, для обеспечения функциональной избыточности с точки зрения надежности проектирования используют разные модели процессоров, что влечет за собой потребность в увеличении числа эмуляторов.

Второй метод, который должен позволить отказаться от использования эмуляторов, состоит в моделировании на материнской плате работы вычислительного устройства, которое должно выполнять тестируемую программу. В этом случае тестируемое программное обеспечение должно иметь доступ к файлам материнской платы либо для считывания тестовых файлов, либо для записи результатов тестов.

Поскольку тестируемое программное обеспечение само по себе не обладает функциями для такого доступа к файлам материнской платы, необходимо тестируемое программное обеспечение изменить, чтобы ввести в него эти функции доступа.

Для передачи данных, как правило, используют системные команды запросов, которые передаются моделируемой средой тестирования. Системными командами запросов могут быть, например, запрос на открытие файла, на запись файла или на считывание файла. Системные команды запросов перехватываются системой эксплуатации материнской платы, которая преобразует их в системные запросы материнской платы.

Этот второй метод тоже имеет свои недостатки. Действительно, с учетом разнообразия файлов разработка функциональных возможностей доступа во многом зависит от материнской платы и от системы ее эксплуатации. Однако вариативность материнских плат является очень большой как в пространстве (группы разработчиков разбросаны по всему миру), так и во времени (замена материнских плат), что создает практические трудности в применении метода.

Эти трудности усугубляются тем, что разработка таких функциональных возможностей доступа к файловым системам требует высокой квалификации специалистов, которые должны уметь изменять функции системы эксплуатации, чего не могут делать специалисты по испытаниям.

Следовательно, этот метод является дорогим и сложным в применении.

Кроме того, этот метод предполагает значительную степень вмешательства в тестируемое программное обеспечение, а изменение программы с целью осуществления тестов является источником опасности нарушения работы самого программного обеспечения.

Во время фазы аттестации и проверки программного обеспечения вычислительного устройства при выполнении тестов могут выявиться ошибки, которые проявляются либо в прерывании хода выполнения функциональной программы, либо в том, что один или несколько тестов дают ошибочные результаты. В этом случае разработчик должен произвести поиск нарушений или ошибок в строках командных кодов с целью их исправления. Этот поиск производят путем выполнения, при котором последовательность точек пути выполнения имеет порядок, обратный последовательности при нормальном выполнении. Иначе говоря, просматривают в обратном порядке последовательность строк программы, в которой ведут поиск ошибки (то есть возвращаются к последовательности строк программы, которая уже была выполнена, но содержит одну или несколько ошибок), и повторно выполняют просмотренную последовательность. Этот поиск называют обратным выполнением.

Это обратное выполнение требует, чтобы в любой точке пути выполнения функциональной программы, образованной последовательностью строк команд, разработчик понимал ход команд. Однако разработчик не знает, на каком уровне пути выполнения находится ошибка. Следовательно, он не знает, на скольких строках программы необходимо осуществлять обратное выполнение. Кроме того, для бортового программного обеспечения обратное выполнение необходимо осуществлять на том же языке, что и нормальное выполнение, то есть на машинном языке. Поэтому для разработчика сложно понять в достаточной степени ход программы функционального программного обеспечения для просмотра последовательности строк и выявления ошибки. Кроме того, нет никаких средств контроля или отслеживания обратного выполнения, позволяющих разработчику понять, к какому месту в нарушенной цепочке он должен вернуться, чтобы найти ошибку или нарушение.

С учетом сложности этот поиск ошибки требует значительных затрат времени, которые могут достигать от нескольких часов до нескольких дней, что существенно повышает стоимость фазы отладки как в плане производительности, так и в плане трудовых затрат. Это связано с тем, что современные инструменты отладки не предлагают никаких средств для эффективной поддержки обратного выполнения: речь идет о возврате либо на n единиц времени (как правило, на секунду), либо на n шагов вычисления. Не существует никакой функциональной связи с логикой предназначенного для отладки программного обеспечения. Поэтому эффективность обратного выполнения существенно снижается и даже становится ничтожной, если речь идет о программном обеспечении со сложной логикой, что характерно для бортового программного обеспечения.

Настоящее изобретение призвано устранить недостатки вышеуказанных технологий. В этой связи изобретением предлагается способ отладки функционального программного обеспечения, позволяющий разработчику легко находить место ошибки или нарушения в последовательности команд, написанной разработчиком. Для этого способ в соответствии с настоящим изобретением предлагает структурировать выполнение программы функционального программного обеспечения путем функциональной разметки пути выполнения. Эту функциональную разметку осуществляют путем установки меток в специфических местах нормального пути выполнения программы, чтобы разбить программу на функциональные блоки, что позволяет разработчику находить место, от которого следует осуществлять обратное выполнение. Эту разметку можно производить интерактивно или автоматически.

В частности, объектом настоящего изобретения является способ отладки программы функционального программного обеспечения бортовой системы, содержащий следующие этапы:

a) разметка программы путем установки меток вдоль пути выполнения для разбивки указанного пути выполнения на смежные функциональные интервалы,

b) нормальное выполнение программы,

c) получение состояния выполнения программы при помощи векторов состояния меток,

d) при обнаружении ошибки:

- поиск функционального интервала нарушения на основе векторов состояния меток,

- обратное выполнение программы в этом функциональном интервале нарушения,

- определение и исправление ошибки.

Способ в соответствии с настоящим изобретением может также содержать один или несколько следующих признаков:

- ошибку обнаруживают, когда обнаруживают остановку программы в результате прекращения выполнения операции процессором.

- он содержит операцию уточнения функционального интервала, в котором находится ошибка.

- операция уточнения функционального интервала содержит определение дополнительных меток входа и выхода и/или промежуточных меток.

- этап поиска функционального интервала нарушения осуществляется автоматически.

- этап поиска функционального интервала нарушения осуществляется интерактивно при вмешательстве разработчика.

- он содержит этап записи положения каждой метки и данных о состоянии выполнения программы в файл результатов материнской платы.

Объектом настоящего изобретения является также устройство, моделирующее работу бортовой системы, установленной на борту летательного аппарата, осуществляющее описанный выше способ.

Устройство в соответствии с настоящим изобретением может содержать следующий признак:

- процессор виртуально моделируется на материнской плате тестирования и отладки.

Объектом настоящего изобретения является также рабочая программа для бортовой системы летательного аппарата, загружаемая в блок управления, содержащая последовательности команд для применения описанного выше способа, когда программу загружают и выполняют в блоке.

Настоящее изобретение будет более очевидно из нижеследующего описания, представленного в качестве неограничительного примера выполнения, со ссылками на прилагаемые фигуры, на которых:

фиг.1 - схема программы в соответствии с настоящим изобретением,

фиг.2 - функциональная схема способа в соответствии с настоящим изобретением,

фиг.3 - схема среды тестирования в фазе отладки функционального программного обеспечения бортовой системы.

Функциональное программное обеспечение состоит из набора программ. Программа содержит совокупность записанных команд, называемую в дальнейшем цепочкой команд. Способ в соответствии с настоящим изобретением предлагает размещать отметки на пути выполнения программы функционального программного обеспечения бортовой системы, чтобы на основании этих отметок определять, где находится ошибка или нарушение.

На фиг.1 схематично показаны различные фазы этого способа. Каждая фаза на фиг.1 соответствует программе функционального программного обеспечения бортовой системы на отдельном этапе способа в соответствии с настоящим изобретением. Первой фазой на фиг.1 является пример программы до применения способа в соответствии с настоящим изобретением. Эта программа, обозначенная позицией 20, содержит совокупность цепочек команд от 20-1 до 20-n. Эти цепочки команд, выполняемых в порядке их ввода, то есть от команды 20-1 до команды 20-n, образуют нормальный путь выполнения программы.

Вторая фаза на фиг.1 представляет собой программу 21, которая соответствует программе 20 после установки меток 28. Метки 28 являются виртуальными ориентирами, установленными в специфических местах программы. Предпочтительно эти места соответствуют началу и/или концу различных функций программы. Метки 28 устанавливают, например, в точке входа или в точке выхода функции программы. Если метки установлены на входе или на выходе каждой функции программы, то говорят, что установка меток выполнена согласно функциональной последовательности.

Метки можно также устанавливать в любом другом заранее определенном месте пути выполнения, например в точке сбоя программы на уровне потока данных или на уровне контрольного потока. Метки являются отметками на пути выполнения программы. В дальнейшем будет понятно, что метки образуют также отметки возобновления хода пути выполнения программы, если обнаружено одно или несколько нарушений или ошибок, что выражается либо в виде ошибочных результатов, либо в прекращении выполнения программы, либо в виде бесконечного цикла выполнения.

Нарушение или ошибка может быть функциональной. В этом случае способ выдает разработчику предложение на исправление указанного нарушения или указанной ошибки.

Нарушение или ошибка может также состоять в потере контроля за ходом программы. Такой ошибкой может быть, например, арифметическое переполнение процессора, например, в результате установки указателя в запрещенной зоне. В этом случае выполнение программы прерывается. Прерывание, связанное с арифметическим переполнением, называют прекращением выполнения операции процессором.

Предлагаемая изобретением установка функциональной последовательности позволяет обнаружить, а затем исправить этот тип ошибки, связанный с прекращением выполнения операции процессором. Для этого установка последовательности в соответствии с настоящим изобретением разбивает путь выполнения программы на смежные функциональные интервалы. Функции выполняются последовательно одна за другой. В варианте реализации изобретения метку устанавливают в начале каждой функции. Каждая метка содержит вектор состояния, который соответствует картине памяти. Этот вектор состояния показывает состояние памяти в заранее определенном месте, то есть в месте, где находится метка, что в дальнейшем позволяет перезапустить память с данными вектора состояния.

В начале хода программы все метки деактивированы. Вектор состояния каждой из этих меток является нейтральным или деактивирован, то есть не содержит никакой информации. Каждый раз после нормального выполнения одной функции метка, находящаяся на входе следующей функции, меняет свое состояние и активируется. В этом случае вектор состояния метки фиксирует состояние выполнения программы, то есть отмечает данные, записанные в памяти системы на этом уровне выполнения программы.

Установка последовательности может происходить автоматически, то есть метка устанавливается автоматически в начале каждого функционального интервала. Установка последовательности может быть также интерактивной, то есть разработчик сам выбирает место установки дополнительных меток внутри одной функции. Эти дополнительные метки могут быть метками входа, метками выхода и/или промежуточными метками. Выбор интерактивной или автоматической установки последовательности определяет сам разработчик. Интерактивная установка последовательности позволяет уточнить интервал поиска и исправления ошибки, что позволяет сократить этот интервал и, следовательно, облегчить поиск ошибки.

Третья фаза, показанная на фиг.1, представляет собой программу 22, соответствующую программе 21 во время выполнения указанной программы в нормальном режиме. Это выполнение в нормальном режиме, называемое нормальным выполнением, соответствует логическому ходу программы, команда за командой, начиная с первой командной строки 20-1.

Четвертая фаза, показанная на фиг.1, представляет собой программу 23, соответствующую программе 21, когда выделены данные о состоянии выполнения программы и о положении меток. Действительно, во время нормального выполнения программы метка, находящаяся в конце нормально выполняемой функции, активируется. Вектор состояния этой метки выделяет или фиксирует состояние памяти на этом уровне выполнения программы.

При прерывании программы последняя активированная метка указывает на функцию, в ходе выполнении которой произошла остановка программы. Вектор состояния этой метки позволяет найти состояние выполнения программы в момент начала выполнения нарушенной функции.

Для обеспечения выделения векторов состояния инструмент отслеживания нормального выполнения программы определяет переходы между метками в порядке их нормального появления, то есть согласно нормальному выполнению командных строк программы. При переходе через метку инструмент отслеживания фиксирует состояние памяти в векторе состояния последней пройденной метки и записывает эти данные в память 4 данных.

Когда происходит ошибка, разработчик осуществляет обратное выполнение программы для выявления этой ошибки внутри программы. Пятая фаза, показанная на фиг.1, представляет собой программу 24, соответствующую программе 23 во время этого обратного выполнения. Это обратное выполнение позволяет вернуться по программе в порядке, обратном нормальному ходу программы, для возобновления ее выполнения с первой командной строки функции, соответствующей последней активированной метке, то есть последней функции с зафиксированным вектором состояния.

Иначе говоря, обратное выполнение осуществляют, следуя меткам, чтобы вернуться по цепочке команд программы и определить место сбоя в цепочке команд. Таким образом, обратное выполнение можно осуществлять внутри одного функционального интервала. При обнаружении в этом функциональном интервале сбоя цепочки или ошибки разработчик выявляет ошибку или нарушение в этой цепочке, а затем производит исправление.

Благодаря меткам разработчик может легко найти нарушенную цепочку команд. После исправления ошибки разработчик может продолжить обратное выполнение для обнаружения других возможных ошибок. Действительно, способ в соответствии с настоящим изобретением позволяет структурировать путь выполнения таким образом, чтобы можно было обнаруживать и исправлять несколько ошибок в ходе одной фазы отладки программы.

Описанная выше фаза отладки, то есть фаза поиска и исправления ошибки представлена на фиг.1 в виде программы 25.

Когда ошибка зафиксирована, и разработчик решает перейти к следующей или предыдущей ошибке, он может применить интерактивную фазу. В этой интерактивной фазе программа 26 содержит интерактивную установку последовательности выполнения, при помощи которой разработчик может переходить от одного функционального интервала к другому.

На фиг.2 более подробно показаны различные этапы способа в соответствии с настоящим изобретением. На функциональной диаграмме на фиг.2 показан предварительный этап 30, на котором блок управления средой тестирования обнаруживает, была ли задействована разработчиком фаза отладки.

Если разработчик принимает решение об осуществлении отладки, блок управления средой тестирования производит на этапе 31 разметку программы, устанавливая метки вдоль пути выполнения, чтобы разбить указанный путь выполнения на смежные функциональные интервалы. Как было указано выше, каждая метка содержит активированный или деактивированный вектор состояния. Вектор состояния метки называют активированным, если были получены данные, относящиеся к состоянию выполнения программы. Таким образом, вектор состояния метки активирован, если функция, предшествующая метке, была выполнена без ошибки. В противном случае он остается деактивированным.

На этапе 32 блок управления запускает нормальное выполнение программы.

На этапе 33 блок управления отмечает данные состояния в векторах состояния меток, чтобы определить состояние выполнения программы.

На этапе 34 блок управления определяет наличие прерывания выполнения программы функционального программного обеспечения. Если программа прерывается, это значит, что было обнаружено наличие ошибки или нарушения. В этом случае применяют этап 35. Если прерывания не было, нормальное выполнение продолжается и возобновляются этапы 32 и 33.

На этапе 35 определяют, не было ли прекращения выполнения операции процессором. Если такое прекращение имело место, применяют этап 36. В противном случае применяют этап 37. В этом случае разработчику направляется сообщение о том, что выполнение программы заканчивается, так как либо была обнаружена ошибка, либо нормальное выполнение было завершено без ошибки.

После этого способ продолжается этапом 43, на котором блок управления записывает положение меток в файл результатов тестов для последующей проверки хода выполнения.

На этапе 44 файл результатов тестов закрывают. Этап 45 является конечным этапом, указывающим на завершение теста или выполнения программы.

Если на этапе 35 было обнаружено прекращение выполнения операции процессором, то на этапе 36 ведут поиск первой деактивированной метки на нормальном пути, чтобы определить функциональный интервал, в котором находится нарушенная цепочка. После этого применяют этап 38. На этапе 38 разработчик может интерактивно установить дополнительные метки входа, дополнительные метки выхода и/или промежуточные метки, чтобы уточнить интервал поиска ошибки в функциональном интервале, определенном на этапе 36. На этапе 39 обнаруживают точки сбоя в потоках данных или в контрольных потоках. Эти точки сбоя позволяют тоже уточнить интервал вокруг ошибки. После определения этих точек сбоя на этапе 40 ограничивают интервал сбоя вокруг ошибки.

Следует отметить, что этапы 38-40 представляют собой предпочтительный вариант реализации изобретения, в котором интервал вокруг ошибки сужают, чтобы облегчить поиск ошибки во время обратного выполнения.

Вместе с тем, способ может предусматривать простой переход от этапа 36 обнаружения неактивной метки к этапу 41 обратного выполнения. В этом случае разработчик должен осуществлять обратное выполнение по всей функции, в которой была обнаружена ошибка.

На этапе 41 запускают обратное выполнение, позволяющее вернуться к функции, в которой была обнаружена нарушенная цепочка команд программы. В варианте реализации изобретения обратное выполнение осуществляют между двумя последовательными метками (интервал). В наиболее распространенных случаях это соответствует началу или концу нарушенной функции. Разумеется, можно переходить с одного интервала на другой без каких-либо особых условий. В другом варианте реализации обратное выполнение осуществляют на интервале, уточненном вокруг ошибки, то есть только на части функции.

На этапе 42 разработчик устраняет ошибку, то есть определяет ошибку в нарушенном функциональном интервале и ее исправляет. После завершения этапа 42 отладки способ возвращается на этап 31, чтобы проверить правильность выполнения программы.

Если блок управления больше не обнаруживает прекращения выполнения операции процессором, блок управления направляет разработчику сообщение, указывающее на то, что фаза отладки программы завершена (этап 37).

Способ в соответствии с настоящим изобретением можно применять в тестовой среде системы, виртуально смоделированной на материнской плате. Его можно также применять на рабочем месте, подключенном к реальной бортовой системе через соответствующий эмулятор работы. В этом случае положение меток и/или векторов состояний записывается (этап 43) на носитель, доступный для разработчика, например, в файл результатов материнской платы. После записи всех положений меток файл результатов закрывают (этап 44) и тест завершается (этап 45). Производят проверку всех результатов (46). Если все результаты нормальные, наступает этап 47 завершения, показывающий, что все результаты нормальные. Если не все результаты нормальные, возобновляют этапы 36-42.

На фиг.3 показан пример блока 1 управления тестовой средой рабочей программы бортовой системы, в котором применяют способ в соответствии с настоящим изобретением. Блок 1 управления содержит процессор 2, программную память 3, память 4 данных и интерфейс входа/выхода 5. Процессор 2, программная память 3, память 4 данных и интерфейс входа/выхода 5 соединены между собой через двунаправленную шину 6 связи.

Программу 7 выполняет процессор 2, используя цепочки командных кодов, установленных в программной памяти 3. Программа 7 предназначена для управления и контроля за работой бортовой системы. Программа 7 не ограничительно содержит администратор 8 прерываний, библиотеку 9, программу-планировщик 10 и набор приложений 11.

Библиотека 9 содержит набор командных функций, активируемых программой 7. Администратор 8 прерываний предназначен для реагирования в реальном времени на неожиданные действия процессора 2, а также для обеспечения координации задач среды тестирования. Программа-планировщик 10 является служебной программой, обеспечивающей автоматическое определение приоритетного порядка при обработке задач, которые должен выполнять процессор 2 в зависимости от различных критериев приоритета и в зависимости от имеющихся в наличии ресурсов.

Программная память 3 содержит в зоне 12 команды, позволяющие произвести описанную выше функциональную разметку программы 7 и указать на положение встретившейся ошибки или нарушения с целью их исправления.

Программная память 3 содержит в зоне 13 команды для выделения векторов состояния меток в программе 7. Положение каждой активированной метки, а также вектор ее состояния записываются в память 4 данных.

Программная память 3 содержит в зоне 14 команды для запуска нормального выполнения программы 7. Выполнение программы 7 функционального программного обеспечения происходит последовательно, команда за командой, и постепенно приводит к активации векторов состояния меток. Когда в какой-либо функции появляется ошибка, выполнение программы 7 останавливается. Векторы состояния меток, которые находятся после функции, в которой появилась ошибка, не активируются. В этом случае вектор состояния последней активированной метки является ориентиром, который указывает на нарушенную функцию, то есть на функцию, в которой находится ошибка.

Программная память 3 содержит в зоне 15 команды для запуска обратного выполнения. При обнаружении ошибки обратное выполнение позволяет вернуться к функции, содержащей ошибочную команду. Разработчик ориентируется на метку, связанную с последним активированным вектором состояния, чтобы возобновить выполнение функции. Таким образом разработчик осуществляет на нарушенной функции только обратное выполнение.

Программная память 3 содержит в зоне 16 команды, позволяющие использовать данные, собранные при помощи меток. Эта команды обеспечивают отладку программы 7.

Программная память 3 содержит в зоне 17 команды, обеспечивающие переходы между функциональными интервалами. Иначе говоря, командные коды зоны 17 позволяют переходить от одного интервала к другому независимо от того, происходит ли нормальное или обратное выполнение программы 7.

Из всего вышеизложенного понятно, что функциональная разметка в соответствии с настоящим изобретением обеспечивает эффективную отладку программного обеспечения, так как представляет собой средство для определения нарушенных командных цепочек, позволяющее ограничить обратное выполнение командами только одной функции. Кроме того, она позволяет исправлять несколько ошибок в ходе одной фазы отладки.

Claims (10)

1. Способ отладки функционального программного обеспечения бортовой системы, включающий следующие этапы:
разметка (31) программы путем установки меток вдоль пути выполнения программы для разбивки указанного пути выполнения на смежные функциональные интервалы,
нормальное выполнение (32) программы,
выделение (33) состояния выполнения программы при помощи векторов состояния меток,
при обнаружении ошибки выполняют:
поиск (36) функционального интервала нарушения на основании векторов состояния меток,
обратное выполнение (41) программы в этом функциональном интервале нарушения,
определение и исправление ошибки (42).

2. Способ по п.1, характеризующийся тем, что ошибку обнаруживают, когда обнаруживают остановку программы в результате прекращения выполнения операции процессором.

3. Способ по п.1 или 2, характеризующийся тем, что содержит операцию уточнения функционального интервала, в котором находится ошибка.

4. Способ по п.3, характеризующийся тем, что операция уточнения функционального интервала содержит определение дополнительных меток входа и выхода и/или промежуточных меток.

5. Способ по п.1, характеризующийся тем, что этап поиска функционального интервала нарушения осуществляется автоматически.

6. Способ по п.1, характеризующийся тем, что этап поиска функционального интервала нарушения осуществляют интерактивно с вмешательством разработчика.

7. Способ по п.1, характеризующийся тем, что содержит этап записи положения каждой метки и данных о состоянии выполнения программы в файл результатов материнской платы.

8. Устройство, моделирующее работу бортовой системы, установленной на борту летательного аппарата, характеризующееся тем, что содержит процессор (2), осуществляющий способ по любому из пп.1-7.

9. Устройство по п.8, характеризующееся тем, что процессор (2) виртуально смоделирован на материнской плате тестирования и отладки.

10. Программная память (3), характеризующаяся тем, что установлена в блоке (1) управления, содержащем загружаемую рабочую программу (7) для бортовой системы летательного аппарата, причем программная память содержит последовательности команд (12-17), обеспечивающие осуществление способа по любому из пп.1-7 при выполнении в указанном блоке загруженной рабочей программы.

Images