СПОСОБ ОБРАБОТКИ ОБЪЕМА ДАННЫХ, ИСПОЛЬЗУЕМОГО ВО ВРЕМЯ ФАЗЫ ОТЛАДКИ ФУНКЦИОНАЛЬНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ, УСТАНОВЛЕННОЙ НА БОРТУ ЛЕТАТЕЛЬНОГО АППАРАТА, И УСТРОЙСТВО ДЛЯ ЕГО ОСУЩЕСТВЛЕНИЯ Российский патент 2012 года по МПК G06F11/36 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) введение контрольных точек, связанных с каждой путевой точкой,

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

- запись в память состояния выполнения программы в месте каждой путевой точки,

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

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

- поиск путевой точки, соответствующей нарушенной функции,

- поиск исходного состояния выполнения программы,

- восстановление этого исходного состояния выполнения,

- исправление ошибки в нарушенной функции и

- повторное выполнение программы.

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

- в память данных записывают за один раз только одно состояние выполнения;

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

- поиск нарушенной функции заключается в нахождении последней активированной путевой точки;

- в память записывают список путевых точек вместе с их состоянием.

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

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

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

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

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

фиг.2а и 2b - схематичный вид устройства, в котором применяют способ в соответствии с настоящим изобретением.

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

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

Каждая метка содержит путевую точку и контрольную точку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На этапе 36 выделяют состояние выполнения программы в данном месте. Это зафиксированное состояние выполнения программы записывают в память на этапе 37.

Этап 38 является этапом обнаружения ошибки в программе. Если в программе обнаружена ошибка, применяют этап 39, если ошибка не обнаружена, применяют этап 40.

На этапе 39 выполнение программы останавливают. В этом случае на этапе 41 определяют исходное состояние выполнения программы. Это исходное состояние выполнения является последним состоянием выполнения, записанным в память данных на этапе 37.

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

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

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

На этапе 45 проверяют, завершена ли фаза отладки. Если фаза отладки завершена, программу можно выполнить полностью (этап 46). В противном случае возвращаются на этап 34 и повторяют этапы 34-45.

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

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

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

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

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

В зоне 9 программная память 3 содержит команды, позволяющие производить разметку программы 7. Разметка программы 7 позволяет установить вдоль всего пути 8 выполнения путевые точки 10. Каждая путевая точка 10 связана с функциональным интервалом. Разметка программы 7 позволяет также установить контрольные точки 11, 12, 13, 14 и 15 с учетом соответствующих путевых точек 10. В зоне 21 программная память содержит команды, обеспечивающие выполнение программы 7. Выполнение программы 7 позволяет проходить путь 8 выполнения команда за командой. Прохождение пути выполнения программы 7 подтверждает прохождение по путевым точкам 10. Прохождение путевых точек последовательно активирует контрольные точки 11, 12, 13, 14 и 15. В зоне 22 программная память 3 содержит команды для сбора данных об исходном состоянии выполнения программы 7. Активация контрольных точек 11, 12, 13, 14 и 15 позволяет последовательно выделять исходные состояния выполнения программы 7. В зоне 23 программная память 3 содержит команды для запоминания данных об исходном состоянии выполнения программы 7. Запоминание этих данных происходит в памяти 4 данных. В зоне 24 программная память 3 содержит команды, позволяющие восстановить сохраненные в памяти данные о состоянии выполнения. На фиг.2b более подробно показана память 4 данных.

Настоящее изобретение относится к способу обработки объема данных, используемых во время фазы отладки программы функционального программного обеспечения бортовой системы. Техническим результатом является минимизация необходимого объема памяти и времени отладки. Способ включает следующие этапы: а) разбивка (32) пути выполнения указанной рабочей программы на функциональные интервалы путем установки путевых точек в каждой функции программы, b) установка (33) контрольных точек, связанных с каждой путевой точкой, с) нормальное выполнение программы, при котором осуществляют: запись в память состояния выполнения программы в месте каждой путевой точки; при этом запись в память состояния выполнения приводит к стиранию состояния выполнения, ранее записанного для указанной путевой точки; при обнаружении ошибки осуществляют: поиск путевой точки, соответствующей нарушенной функции; поиск (41) исходного состояния выполнения программы; восстановление (42) этого исходного состояния выполнения; исправление (44) ошибки в нарушенной функции и повторное выполнение программы. 2 н. и 6 з.п. ф-лы, 2 ил.

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

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

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

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

5. Способ по п.3, характеризующийся тем, что в память записывают список путевых точек вместе с их состоянием.

6. Способ по п.4, характеризующийся тем, что в память записывают список путевых точек вместе с их состоянием.

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

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