СПОСОБ АВТОМАТИЧЕСКОГО ГЕНЕРИРОВАНИЯ СЦЕНАРИЯ ДЛЯ ПРОВЕРКИ ПРАВИЛЬНОСТИ ФУНКЦИОНАЛЬНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ, УСТАНОВЛЕННОЙ НА БОРТУ ЛЕТАТЕЛЬНОГО АППАРАТА, И УСТРОЙСТВО ДЛЯ ПРИМЕНЕНИЯ СПОСОБА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предложенный способ содержит следующие этапы:

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

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

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

- автоматическое выполнение генерированного тестового сценария в среде выполнения тестов.

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

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

- генерирование тестового сценария осуществляют по каждой отдельной тестовой ситуации,

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

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

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

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

Устройство реализует способ в соответствии с настоящим изобретением.

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

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

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

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

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

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

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

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

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

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

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

Если был применен этап 22 записи правильных тестов, на этапе 23 происходит проверка новых тестовых ситуаций при участии и по решению разработчика. Если обнаружена новая тестовая ситуация, способ повторяют, начиная с этапа 20. Если новой тестовой ситуации не обнаружено, применяют этап 26 генерирования сценария. Этому этапу 26 предшествуют два промежуточных этапа 24 и 25. Этап 24 предназначен для установления того, что параметры среды выполнения тестов были указаны разработчиком. Эти параметры позволяют выбрать тип среды выполнения тестов, для которой необходимо генерировать тестовые сценарии. Если параметры обнаружены, на этапе 25 эти параметры учитываются для генерирования тестового сценария.

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

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

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

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

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

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

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

Процессор 2 управляется командными кодами, записанными в памяти 3 программы блока 1 управления.

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

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

В зоне 9 память 3 программы содержит команды для осуществления генерирования тестовых сценариев. Это генерирование тестовых сценариев вытекает из анализа состояний переменных в записи 12. Это генерирование тестовых сценариев представляет собой исходный код 13. Оно происходит для каждой отдельной тестовой ситуации.

В зоне 10 память 3 программы содержит команды для осуществления компиляции исходного кода 13 с целью его перевода на машинный язык. После этой компиляции осуществляют редактирование связей для преобразования исходного кода 13 (который представлен в машинном языке) в исполняемый бинарный код 14.

В зоне 11 память 3 программы содержит команды для выполнения тестового сценария с целью генерирования на выходе результатов 15 теста.