Валидация и верификация встраиваемого программного обеспечения на ранних ста диях проектирования Текст научной статьи по специальности «Компьютерные и информационные науки»

Карпов Михаил Владимирович, начальник отделения, khkedratnla.net, Россия, Тула, АО «КБП»

PRINCIPLES OF DESIGNING A SOFTWARE AND HARD WARE SUITE FOR DEVELOPMENT OF SOPHISTICA TED TECHNICAL SYSTEMS

Т. V. Privalova, М. V. Karpov

The article contains description and substantiation of arrangement of a software and hardware suite, which realizes the digital technology of designing a sophisticated technical product hy means of comprehensive automation of research and development on the basis of integration of software and hardware assets into a single software and hardware suite. The article deals with the main principles of designing such a suite, as well as with composition and structure of its software assets.

Key words: research and development automation, software and hardware suite.

Privalova Tatiana Vladimirovna, candidate of technical sciences, chief of section, khkedr a tiila. net, Russia, Tula, JSC «KBP»,

Karpov Mikhail Vladimirovich, chief of division, khkedr a tiila. net, Russia, Tula, JSC «KBP»

УДК 681.3.011.56

ВАЛИДАЦИЯ И ВЕРИФИКАЦИЯ ВСТРАИВАЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА РАННИХ СТАДИЯХ ПРОЕКТИРОВАНИЯ

В.М. Понятский, В.Г. Федорищева

Рассмотрена технология проверки разрабатываемой системы управления на ранней стадии проектирования с использованием инструментов MathWorks. Технология поддерживает реализацию подхода «от модели к программе» и включает процедуры создания связи модели с документом требований; проверку модели на соответствие стандартам моделирования; функциональное тестирование модели; анализ на покрытие модели тестами; проверку на ошибки проектирования; доказательство свойств модели и автоматическую генерацию тестов для 100%-го покрытия модели.

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

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

Продукты МаШШогкБ обеспечивают единую среду для разработки встраиваемого ПО, начиная от формирования требований и заканчивая созданием объектного кода и файлов прошивки микроконтроллера. Причем на всех этапах жизненного цикла проводятся тестирование и верификация проектируемого ПО: требования (спецификация), модель (выполняемая спецификация), код, объектный код (рис.1).

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

В продуктах МаШШогкБ реализована поддержка двух стандартных подходов для верификации встраиваемого ПО: верификация от модели к программе и обнаружение ошибок при выполнении в исходном коде.

ИрОЕсВД гргбг-.дти

Трзесируелиостъ ме.41ду требоэ^ниями й ЫСЩСДькЗ

ТрзссируРРЛЖТЬ ХШ.Чфу моделью И КОДПЧ /

Рис. 1. Рабочий процесс разработки программного обеспечения с помощью инструментов MathWorks

342

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

Рассмотрим первый подход к верификации на примере разработки встраиваемого ПО-блока управления следящим приводом оптико-электронной системы.

Технология валидации и верификации модели с помощью инструментов MathWorks включает следующие процедуры:

создание связи элементов модели с требованиями (трассируе-

мость);

проверку на соответствие стандартам моделирования; функциональное тестирование модели; анализ на покрытие модели тестами; проверку на ошибки проектирования; доказательство свойств модели; автоматическую генерацию тестов. Создание связи элементов модели с требованиями Simulink Verification and Validation - это пакет расширения Simulink для проведения полного комплекса тестирований и проверок систем с учетом технических требований. Требования к модели формируются на основе технического задания к разрабатываемой системе и не должны быть противоречивыми.

Для управления требованиями в Simulink Verification and Validation есть инструмент Simulink Requirements. Этот инструмент способен импортировать требования из Word, Excel или устанавливать связь с системами электронного документооборота. Simulink Requirements позволяет связать требования с блоками модели Simulink, всей моделью или кодом, сгенерированным из модели.

После установки связи элементов модели с требованиями (рис. 2), можно проанализировать требования на трассируемость, то есть отслежи-ваемость в модели.

Это возможно благодаря навигации из документа требований в модель и обратно (рис. 3).

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

¿д-"^--' ЕЯ

Рис. 2. Детализация связи блока модели с документом требований

Проверка на соответствие стандартам моделирования

Для повышения качества модели необходимо провести проверку на соответствие стандартам моделирования, например, на стандарт MathWorks Automotive Advisory Board (MAAB). MAAB является компанией, которая разрабатывает рекомендации по использованию и усовершенствованию средств управления, моделирования и генерации кода MathWorks, включая Simulink, Stateflow и Embedded Coder.

Рис. 3. Навигация из документа требований в модель

Инструкции стандарта МААВ важны для успеха проекта и работы в команде - и внутренней, и при сотрудничестве с партнерами или субподрядчиками. Соблюдение инструкций стандарта МААВ является ключевой предпосылкой к достижению: системной интеграции; четко определенных интерфейсов;

344

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

Основные требования стандарта MAAB по единому стилю моделирования:

правила именования (файлов, директорий, подсистем, блоков, портов, сигналов);

архитектура модели (разделение Simulink и Stateflow, иерархия подсистем, декомпозиция);

параметры конфигурации модели; типы данных и значения по умолчанию;

правила создания безопасных конструкций Simulink, Stateflow, Matlab Function.

Проверки на соответствие стандартам проводятся с помощью инструмента Model Advisor. На рис. 4 приведен фрагмент отчета о пройденных проверках на стандарт моделирования MAAB блока управления (ЦВС) модели оптико-электронной системы (ОЭС). Отчет содержит информацию о модели, дате создания и модификации, номере версии, результата проверки, предупреждения и ошибки, а также рекомендации по их устранению.

tt Web Browser - Model Advisor Report for vl4_2035a_faBofhaya_model_07_06_18/l|BC (Блок управления;' = : 1—i-^HHl

Model Advisor Report lor VU_M L5 a.raboctiay a_moOel_0?_06j 8/U.SC (Блок управлении) " ¡ + ЕВ Ш ЕЭ[П) »

С Л Location: 'M%85KM%BA%M%S2%ffl%ro%BF°^%BE%S^OTWE%MMD%M%Al/m •

Check (or global variables in MATU\B code used in MATLAB Function blocks Passed

No global vanables found

Check for global variables in MATLAB functions defined m Stateflow charts Passed

No MATLAB functions defined in Stateflow charts found

Check for global variables in called MATLAB functions Passed

No external MATLAB functions found

© Check usage of restricted variable names

Checks whether variable names used in MATLAB Function blocks are reserved for C/C++/MATLAB keywords Passed

No variable names conflict with reserved keywords

© Check usage of character vector Inside MATLAB Function block

Checks whether character vectors are being used inside MATLAB Function blocks Passed

No character vectors found in MATLAB Function block

Û Check usage of recommended patterns for Switch/Case statements Checks whether non-constant variables are used in Switch/Case arguments.

Passed

Non-constant vanables are not used as SwitcrvCase arguments

Рис. 4. Фрагмент отчета о проверке на стандарт моделирования МААВ блока управления модели ОЭС

345

Функциональное тестирование модели

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

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

Рис. 5. Функциональное тестирование на этапах создания ПО

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

Один из примеров выполнения функционального тестирования: тест Baseline. При выполнении этого теста выходные сигналы модели сравниваются с исходным набором сигналов (сравнение текущего результата моделирования с записанным результатом моделирования при номинальных значениях параметров модели). Сравнение текущего результата моделирования и baseline допускается в абсолютных или относительных допусках. Допуски задаются в разделе критериев тестового сценария.

Применительно к модели ОЭС тест baseline можно использовать для оценки влияния разброса параметров модели на выходные характеристики.

На рис. 6 и 7 приведены результаты выполнения функционального теста baseline для оценки влияния разброса параметра NKU.

Анализ покрытия модели тестами

Инструмент Simulink Coverage выполняет анализ покрытия модели и кода тестами и измеряет полноту тестирования в моделях и сгенерированном коде при запуске симуляции модели, а также в режимах SIL и PIL.

Test trace

Test trace

Рис. 6. Результаты выполнения функционального теста для канала ВН с номинальным значением константы МКи

Рис. 7. Результаты выполнения функционального теста для канала ВН с максимальным отклонением константы МКи

Он применяет метрики, такие, как выполнение (execution), решение (decision), состояние (condition), модифицированное покрытие состояния/решения (MCDC) и реляционное пограничное покрытие для оценки эффективности имитационного тестирования в моделях, программном обеспечении в режимах «программа в контуре» (SIL-тестирование) и «процессор в контуре» (PIL-тестирование). Можно использовать данные о покрытии для поиска пробелов в тестировании, отсутствующих требований или непредвиденных функциональных возможностей.

347

Полнота покрытия тестами - важный параметр, показывающий, что компонент модели выполняет возложенные на него функции и полностью протестирован. Покрытые на 100 % элементы модели подкрашиваются в модели зеленым цветом (рис. 8).

б

Рис. 8. Анализ на покрытие тестами блока управления модели ОЭС: а - блоки модели верхнего уровня; б - блоки диаграммы Stateflow

Если анализ покрытия элементов модели тестами показал, что покрытие модели неполное, используется режим Generate Test инструмента Simulink Design Verifier для генерации тестов для 100 %-го покрытия.

Проверка на ошибки проектирования

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

Ошибки проектирования:

мертвая логика; ошибки переполнения; деление на ноль;

нарушение ограничений и требований к системе. Simulink Design Verifier подсвечивает блоки, в которых доказано отсутствие ошибок, и блоки, в которых выявлены ошибки выполнения. Для блоков с ошибками генерируется тестовый вектор, который позволяет воспроизвести ошибку во время симуляции.

На рис.9 показаны результаты проверки блока управления модели ОЭС на наличие мертвой логики: в диаграмме Stateflow обнаружен переход, в отношении которого доказана неактивность во время моделирования.

Рис. 9. Переход с мертвой логикой в блоке управления модели ОЭС

Модель (рис. 10) обвязки представляет собой источник входных сигналов и подсистему, в которой находится модель ОЭС. Тестовые векторы в блоке Signal Builder при моделировании подтверждают наличие неактивного перехода в диаграмме Stateflow.

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

модели ОЭС

349

Доказательство свойств системы

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

На рис. 11 и 12 приведены результаты проверки утверждения, что значение сигнала внутри блока NKU не выйдет из диапазона [-1; 1].

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

Генерация тестов для 100 %-го покрытия модели дополняет функциональные тесты, основанные на требованиях (созданные вручную или собранные во время симуляции всей системы). При таком подходе Simulink Design Verifier берет информацию о существующем покрытии модели и генерирует дополнительные тестовые векторы, которые выполняют все цели покрытия, не удовлетворенные во время тестирования на основании требований.

Рис. 11. Окно результатов после проверки

После этапа валидации и верификации модель, прошедшая проверку, на подтверждение соответствия предъявляемым требованиям, соответствие стандарту моделирования, отсутствие ошибок проектирования, проведено тестирование и обеспечено 100%-е покрытие тестами, после чего

350

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

^ Results: vl4 2017b sf4 fusion 25 05 13 ED <

^ a?

BEcktc SLnm^rv

vL1_2017b_sf4_fu5mn_25_D5_lS/l4BC (Блок управленияJ^KKLIS/Praof Objective Objective: Point([T T|) VAUD

Рис. 12. Окно с результатом: блок прошел проверку

Генерация С-кода из моделей Simulink для процессоров встроенных систем осуществляется при помощи пакета Embedded Coder [1]. Генерируемый С-код может быть универсальным или специализированным, настроенным под определенный тип процессора. Процесс генерации С-кода включает следующие процедуры [1]: выбор параметров решателя; выбор целевого файла; выбор аппаратной реализации; выбор опций оптимизации кода; выбор дополнительных опций; генерацию С-кода.

Поддержка аппаратной реализации обеспечена либо фирмой MathWorks, либо фирмами-производителями микроконтроллеров. В последнем случае для генерации кода под определенный микроконтроллер необходимо установить дополнительное ПО. Например, для создания C-кода для процессора STM32F4-Discovery выбрать в браузере файл ert.tlc Embedded Coder (рис.13), предварительно установив пакет поддержки STM32F4-Discovery.

System Target File Browser: v!4 2018a sf4 fusion 25 05 18 ii i*7* J

System Target File: Description :

asap2.tlc autosar.tic ASAM-ASAP2 Data Definitic AUTOSAR

|ert.tic Embedded Coder

ert.tlc ert shrlib.tlc grt.tlc grt.tlc realtime ..tic rsim.tic rtwsfcn.tlc Create Visual C/C++ Solut 1 Embedded Coder (host-base 1 Generic Real-Time Target 1 Create Visual C/C++ Solut 1 Run on Target Hardware Rapid Simulation Target | S-Function Target

< 1

Full Name: C:\Program Files\MATLAB\R2018a\rtw\c\ert\ert.tlc

OK [ Cancel 1 [ Help ] | Apply

Рис. 13. Окно выбора целевого файла для генерации программного кода

351

Это можно сделать из меню Add-Ons -> Get Hardware Support Packages (рис. 14).

Рис. 14. Окно меню Add-Ons

На рис.15 приведен фрагмент сгенерированного кода.

18 19 29 21 22

23

24

25

26

27

28 29 39

31

32

33

34

35

36

37

38

39 49

41

42

»include 11 siun_target. h"

/* Named constants for Chart: '<S15>/Chart' */

tide-fine sf un_target_IN_AC ( (uintS_T}lU)

»defime sfun_target_IN_ACTPV ((uint3_T}2U)

»define sfun_ta rg e t_IN_ACTV ({uinta_T)3U)

«define sfun_ta rg e t_IN_IС ((uintS_T)2U) »define sfun_target_IN_NO_ACTIVE_CHILD ((uint&_T)0U)

Block signals and states (default storage) V DW_sfLin_target_T sfun_ta rget_DN]

/* External inputs (root inport signals with default storage) */ ExtU_sfun_ta rg e t_T sfun_t a rget_U;

/* External outputs (root outports fed by signals with default storage) */ ExtY_sfun_target_T sfun_targst_y;

RecL-time model V RT_MOD E L_ sf u n_t а гget_T s fu n_t a rg et_M_;

RT_nODEL_sfun_target_T *tonst sfun_target_M = &sfun_target_M_;

/;* Forward declaration for Local functions static void sfLin_target_enter_internal_AC(void)i static void rate_scheduler(void)j

Рис. 15. Фрагмент С-кода, сгенерированного из блока управления модели ОЭС

Также можно скачать библиотеки Embedded Coder Support Package for STMicroelectronics Discovery Boards и Embedded Coder Support Package for ARM Cortex-M Processors с официального сайта MathWorks и авто-

номно установить [2]. Затем выбрать аппаратную реализацию и сгенерировать С-код для блока управления (ЦВС) модели ОЭС, выбрав в контекстном меню блока C/C++ Code -> Build Subsystem.

Было проведено сравнение результатов выполнения Simulink-модели ОЭС с Simulink-моделью, в которую вместо блока управления (ЦВС) добавлен С-код (рис.16).

Результаты выполнения модели с сгенерированным кодом не отличаются от результатов моделирования непрерывной Simulink-модели.

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

Q

Inspect

В

Compare

е

в ±

i

о

©

{Filler Signals

-•¿AVE u

ii_ ШЗЧП

ВЫХРП(1} ТАП)

Телевизионный автомат (ТА) ✓ ЦВС (Блок управления}1:1{1) выхК<Р(1)

□ вн

□ ги

Integrator! :1

□! Вых Гя Вых Вн □| вых фК(2)

■/ ЦВС (Блок управления):2[2) oshibka(2}

□ ПМЙ

вых РП(2) ТА(2)

Телевизионный автомат (ТА)

вых КФ(2) Properties

:: ! щ щ | о. о, а,1ч. а. и О

I ЦВС (Блокуправления):2(1) иЦВС (Блок управления)*!: 1(1} ■ ЦВС (Блок у правпения):2(2) ЦВС (Блокулравления)1:1(2)

1

IP

1

1 1

М Vv

Рис. 16. Результаты выполнения Simulink-модели ОЭС

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

Список литературы

1. Понятский В.М., Кушников Д.В., Федорищева В.Г. Методика генерации из моделей МаНаЬ текста программ на языке С для процессоров встроенных систем // 11-я международная конференция «Системы проектирования, технологической подготовки производства и управления эта-

353

пами жизненного цикла промышленного продукта (CAD/CAM/PDM -2011)». Москва, 18-20 октября 2011 г.: Сборник материалов / под ред. Артамонова Е.И. М.: Институт проблем управления РАН, 2011. С. 83 - 87.

Понятский Валерий Мариафович, начальник отдела, khkedr a tnla.net, Россия, Тула, АО «КБП»,

Федорищева Вера Георгиевна, ведущий инженер-программист, khkedratnla.net, Россия, Тула, АО «КБП»

VALIDATION AND VERIFICA TION BUILT IN SOFTWARE AT EARLY DESIGN STA GES

V.M. Ponyatsky, V.G. Fedorishcheva

The technology of check of the developed control system at early design stage of c is considered hy use of the MathWorks tools. The technology supports approach implementation "from model to the program " and includes procedures of creation of communication of model with the document of requirements; check of model on compliance to standards of modeling; functional testing of model; the analysis on model covering tests; check on design errors; the proof ofproperties of model and automatic generation of tests for 100% covering of model.

Key words: verification, validation, traceahility, functional testing, the analysis on covering.

Ponyatsky Valery Mariafovich, the head of department, pwmruayandex. ru, Russia, Tula, JSC "KBP",

Fedorishcheva Vera Georgiyevna, the leading software engineer, Russia, khkedratnla.net, Tula, JSC "KBP"