CC BY
11ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004.94:004.415.532.3
Верификация при модельно-ориентированном проектировании с использованием среды Simulink
А.В. Туркин, А.В. Сотников,, А.В. Шипатов
Национальный исследовательский университет «МИЭТ»
Рассмотрен автоматизированный подход к решению задачи верификации, возникающей при разработке программного обеспечения с использованием среды модельно-ориентированного проектирования Simulink. Описаны две схемы верификации в режиме симуляции Processor-in-the-Loop, каждая из которых предполагает взаимодействие между Simulink, средой разработки Eclipse и операционной системой Linux, работающей на целевой платформе. Выделена наиболее эффективная схема верификации, которая может быть использована для решения поставленной задачи на аппаратной платформе с операционной системой Linux.
Ключевые слова: модельно-ориентированный подход, задача верификации, Simulink, Eclipse, GDB, SSH.
При разработке программного обеспечения для встраиваемых систем все чаще применяется модельно-ориентированный подход, при котором процесс разработки программного обеспечения можно разбить на несколько этапов: моделирование, симуляция, реализация и верификация. Под моделью программного обеспечения понимается некоторое описание алгоритмических блоков, входящих в его состав, и возможные связи между ними [1]. Решение задачи моделирования подразумевает разработку такой высокоуровневой модели, которая позволяет осуществить анализ алгоритма, представленного в виде модели программного обеспечения, без учета особенностей практической реализации. Решение второй задачи - симуляции необходимо для проверки модели на реальных данных, которые могут быть сформированы заранее или получены в процессе выполнения процедур симуляции. Третья задача, которая решается в рамках модельно-ориентированного подхода - это переход от модели к практической реализации. При ее решении должно выполняться основное требование к процессу разработки программного обеспечения, выдвигаемое в рамках рассматриваемого подхода - сохранение в неизменном виде алгоритмов, заложенных в блоки модели, а также связей между ними. Это означает, что при реализации модели на некотором языке программирования необходимо установить численную эквивалентность при таком переходе [2].
Таким образом, возникает четвертая задача в рамках модельно ориентированного подхода - задача верификации программной реализации.
Исходя из степени абстракции, при рассмотрении модельно-ориентированного подхода можно выделить два уровня представления модели. На первом уровне, назы-
© А.В. Туркин, А.В. Сотников, А.В. Шипатов, 2014
ваемом логическим, модель представляется таким образом, чтобы обеспечить наивысшую степень абстракции от физических структур хранения данных. На втором уровне, называемом уровнем реализации, модель представляет собой набор инструкций на конкретном языке программирования. Представление модели на этом уровне - это готовое к внедрению программное обеспечение.
Таким образом, процесс разработки программного обеспечения может быть представлен следующим образом:
- в результате выполнения этапов моделирования и симуляции разрабатывается модель, удовлетворяющая всем предъявляемым к программному обеспечению требованиям;
- на следующем этапе полученная модель логического уровня преобразуется в модель уровня реализации;
- на этапе верификации выполняется оценка точности такого преобразования.
Переход от логического уровня к уровню реализации является «слабым местом»
такого подхода, что связано со следующей особенностью разработки: проводить проверку эквивалентности представлений модели логического уровня и уровня реализации необходимо каждый раз, когда в модель вносятся изменения на любом из указанных уровней. Изменения на уровне реализации могут потребоваться, если необходимо выполнить незначительную корректировку конкретного программного обеспечения без изменения модели логического уровня.
Широкое распространение получил подход к автоматизированному построению модели уровня реализации (формированию исходного кода на некотором языке программирования) с использованием так называемых генераторов кода. Под верификацией в этом случае понимают автоматизированное подтверждение численной эквивалентности модели логического уровня и модели уровня реализации [2]. Таким образом можно проверить правильность результатов генерации кода, а также его компиляции.
Фактически стандартом при реализации описанного подхода является среда мо-дельно-ориентированного проектирования Simulink для динамических и встраиваемых систем [3], которая предоставляет возможность решать все описанные в рамках мо-дельно-ориентированного подхода задачи.
На этапе моделирования программное обеспечение описывается как набор блоков, связанных так называемыми сигналами Simulink. Задача моделирования решается либо с использованием стандартного набора блоков Simulink, либо с применением определенных пользователем специальных блоков - ^-функций [4]. Для работы со стандартными блоками в среде Simulink предусмотрен графический интерфейс для ввода их параметров, определяющих функциональные свойства конкретного блока. Пользовательские блоки предоставляют разработчику возможность добавлять на этапе моделирования программные модули, разработанные на таких языках программирования, как C и C++ [4]. Вместе с тем можно использовать язык, предусмотренный средой MATLAB.
Переход от логического уровня к уровню реализации может быть осуществлен с использованием пакета Embedded Coder [3], который формирует читаемый компактный код, оптимизированный для использования во встраиваемых системах, а также на платах прототипирования [5], выпускаемых многими производителями.
В работе [2] предлагается проводить верификацию с использованием автоматизированного подхода к оценке численной эквивалентности между моделью логического уровня и моделью уровня реализации. В этом случае проверка эквивалентности подразумевает симуляцию с использованием одинаковых входных тестовых данных для мо-
Верификация при модельно-ориентированном проектировании.
дели, представленной на двух уровнях абстракции, с последующим установлением идентичности их выходных данных. При правильном переходе от логического уровня к уровню реализации результаты симуляции модели в среде Simulink на любых тестовых данных не должны отличаться от выходных данных программы, исполняемой на целевой платформе. Полное тестирование при таком подходе невозможно [2], поэтому только конечный набор предварительно сформированных данных может быть использован для выполнения верификации. Такая верификация может быть осуществлена с использованием симуляций Software-in-the-Loop (SIL) и Processor-in-the-Loop (PIL). Для этих целей в Simulink предусмотрена возможность формирования соответствующих блоков.
Симуляция с использованием SIL включает компилирование и запуск программного обеспечения (модели уровня реализации) на пользовательском компьютере, в то время как PIL-симуляция предусматривает кросс-компиляцию и запуск программного обеспечения на целевой платформе или на эквивалентном по набору инструкций симу-ляторе. Рассмотрим подробно возможности Simulink в части PIL-симуляции как наиболее востребованного подхода при решении задачи верификации, когда требуется использование некоторой аппаратной платформы для непосредственного запуска модели уровня реализации.
В Simulink (посредством пакета Embedded Coder) предусмотрена возможность взаимодействия со сторонними средами разработки. В частности, поддерживается взаимодействие со средой Eclipse [6], обладающей удобным графическим интерфейсом и возможностью расширения функционала за счет ряда свободно распространяемых дополнений. При построении модели уровня реализации с использованием пакета Embedded Coder формируется готовый к компилированию проект среды Eclipse. Графический интерфейс среды Eclipse позволяет управлять настройками кросс-компилятора таким образом, что исполняемый файл, полученный в результате компиляции созданного проекта, может быть запущен на аппаратной платформе.
Во встраиваемых системах широко распространена практика использования операционной системы Linux, обладающей рядом достоинств [7], одним из которых является возможность применения свободно распространяемых программных средств.
Рассмотрим две схемы верификации, использующие PIL-симуляцию и среду разработки Eclipse. На рис. 1 представлена схема верификации первого типа.
платформа
[, GDB)
Загрузка программы Рис. 1. Схема верификации первого типа
Взаимодействие исполняемой программы со средой Eclipse осуществляется посредством наиболее часто используемого инструмента отладки - GDB (GNU Project Debugger) [8]. Полученный после компилирования проекта Eclipse исполняемый файл
помещается на целевую платформу. Для загрузки программы, а также для ее последующего запуска в режиме отладки с использованием сервера GDB применяется удаленный доступ посредством протокола SSH. Необходимо отметить, что серверы служб GDB и SSH должны быть предварительно запущены на целевой платформе. Упрощенно процесс передачи данных от Simulink к аппаратной платформе при использовании схемы верификации первого типа может быть описан следующим образом. Сформированные на стороне Simulink данные сначала передаются в Eclipse, а далее посредством GDB доставляются на целевую платформу. Обратная передача данных в Simulink также осуществляется через Eclipse с использованием GDB на этапе передачи данных от аппаратной платформы. Управление остановом и запуском программы также выполняется с применением GDB.
Схема второго типа для решения задачи верификации также основана на использовании PIL и среды разработки Eclipse. Основное ее отличие от первой (см. рис.1) заключается в том, что при взаимодействии с целевой платформой для управления запуском и остановом программы применяется GDB, а для передачи основных данных, необходимых для верификации, используется прямой канал от аппаратной платформы к Simulink, построенный на основе протоколов стека TCP/IP. Общая схема верификации этого типа представлена на рис.2.
Рис. 2. Схема верификация второго типа
Перед проведением верификации загрузка и запуск программы также осуществляются с использованием удаленного доступа посредством протокола SSH. Наличие GDB необходимо только для управления процессом верификации. После запуска программы на целевой платформе осуществляется запуск сервера, который интегрирован в программный проект среды Eclipse. Этот сервер реализован отдельно от основных блоков модели уровня реализации и не влияет на ее функционирование. Основная задача серверной части - обработка запросов от Simulink на выдачу данных, причем при применении такой схемы они будут переданы в Simulink путем прямого обмена с использованием TCP/IP.
Приведенные схемы верификации используют PIL и среду разработки Eclipse и могут применяться на различных аппаратных платформах, основные требования к которым следующие:
- работа под управлением операционной системы Linux, в которой должны быть запущены службы SSH и GDB;
Верификация при модельно-ориентированном проектировании...
- наличие возможности подключения к сети передачи данных, организованной, например, на основе технологий Ethernet.
Поставленная задача верификации может быть решена с использованием любой из приведенных выше схем при удовлетворении указанным требованиям к используемым аппаратно-программным средствам, поэтому следует оценить быстродействие каждой из них.
На быстродействие, под которым понимается количество циклов верификации в единицу времени, влияют следующие параметры: скорость обработки исходных данных в среде Simulink; скорость передачи исходных данных от Simulink к аппаратной платформе; скорость обработки полученных данных на аппаратной платформе; скорость передачи выходных данных обратно в Simulink; скорость сравнения результатов обработки. При использовании одной и той же аппаратной платформы скорость передачи данных от Simulink к аппаратной платформе и обратно будет определяющей при проведении сравнительного анализа приведенных выше схем верификации.
Для проведения сравнительного анализа в качестве аппаратной платформы использовался вычислительный модуль ElmiCORE-i.MX35-Lite [9]. Его базовым элементом является микропроцессор i.MX35 компании Freescale Semiconductor с ядром ARM 1136JF-S [7], обеспечивающим возможность использования операционной системы Linux. В своем составе указанный модуль имеет интерфейс Ethernet 10/100 BASE-T, что позволяет организовать на его основе верификацию с применением схемы любого типа.
Для оценки быстродействия каждой из описанных схем в Simulink разработана модель, основным компонентом которой является блок выделения углов на изображении в градациях серого с использованием детектора Харриса [10]. При решении задачи верификации в качестве исходных данных использовалось изображение [11] размером 512 х 512 пикселей, которое было масштабировано с коэффициентами 0,5, 0,25 и 0,125 путем применения бикубической интерполяции [12]. В результате получен набор, содержащий изображения следующих размеров: 64х64, 128x128, 256x256 и 512x512 пикселей. При проведении сравнительного анализа последовательно использовались описанные схемы верификации, для реализации каждой из которых применялась аппаратная платформа [9]. При применении отдельной схемы верификации каждое изображение из набора использовалось многократно с целью вычисления количества циклов верификации в секунду для изображения определенного размера. При проведении сравнительного анализа процессорный элемент (Freescale i.MX356) аппаратной платформы [9] был настроен на работу с частотой ядра 530 МГц, приемопередатчик Ethernet работал в режиме 100BASE-TX.
В таблице представлены данные о быстродействии каждой из схем верификации при обработке изображений из описанного выше набора. Здесь быстродействие измеряется количеством обработанных кадров в секунду.
Оценка быстродействия при решении задачи верификации с применением Processor-in-the-Loop-симуляции и среды разработки Eclipse при использовании двух типов схем взаимодействия с аппаратной платформой
Размер кадра Быстродействие схемы верификации первого типа (кадр/с) Быстродействие схемы верификации второго типа (кадр/с)
64x64 2,65 0,1250
128x128 1,33 0,0379
256x256 0,48 0,0099
512x512 0,15 0,0025
В результате анализа полученных данных, можно сделать вывод, что выгодным отличием применения схемы верификации второго типа является ее большее быстродействие. Так, например, для кадров размером 512x512 пикселей быстродействие при использовании схемы второго типа более чем в 50 раз превышает быстродействие схемы верификации первого типа. Такой результат достигается за счет прямого взаимодействия с целевой платформой посредством TCP/IP.
Преимущество схемы второго типа позволяет использовать ее для верификации моделей, реализующих алгоритмы обработки больших объемов информации, в частности видеоданных, которые на каждой из итераций PIL-симуляции должны быть переданы на целевую платформу.
Литература
1. Paterno F. Model-based design and Evaluation of interactive applications. - 2000. - 195 p.
2. Code generation verification - assessing numerical equivalence between simulink models and generated code / M. Conrad, T. Erkkinen, T. Maier-Komor et al. // 4th Conference Simulation and Testing in Algorithm and Software Development for Automobile Electronics. - 2010. - URL: http://www.mathworks.com/ tagteam/63743_SimTest10_CGV.pdf (дата обращения: 28 апреля 2014 г.)
3. The MathWorks Inc., Matlab and Simulink. - URL: http://www.mathworks.com (дата обращения: 6.02.2012).
4.Popovici K., Rousseau F., Jerraya A.A., Wolf M. Embedded software design and programming of multiprocessor system-on-chip. - London: Springer, 2010. -268 p.
5. The MathWorks Inc., Embedded Coder. - URL: http://www.mathworks.com/products/embedded-coder/?s_cid=wiki_simulink_4 (дата обращения: 1.03.2013).
6. The Eclipse Foundation. - URL: http://www.eclipse.org/ (дата обращения: 6.02.2012).
7. Yaghmour K., Masters J., Ben-Yossef G., Gerum P. Building Embedded Linux Systems. - Second ed. -Ed. O'Reilly, 2008. - 439 p.
8. Matloff N., Salzman P.J. The art of debugging with GDB, DDD, and Eclipse. - San Francisco: William Pollock, 2008. - 265 p.
9. Шипатов А.В., Сотников А.В., Туркин А.В., Сараев В.Н. Вычислительный модуль // Патент на полезную модель № 117659. - 2012.
10. Harris C., Stephens M. A combined corner and edge detector // Proc. of the 4th Alvey Vision Conference. - 1988. - Р. 147-152.
11. Wakin M. Standard Test Images. - URL: http://www.ece.rice.edu/~wakin/images/ (дата обращения: 17.12.2013).
12. Keys R. Cubic convolution interpolation for digital image processing // IEEE Transactions on Signal Processing, Acoustics, Speech and Signal Proc. - Vol. 29 (6). - 1981. - P. 1153-1160.
Статья поступила 17 октября 2013 г.
Туркин Андрей Владимирович - кандидат физико-математических наук, доцент кафедры вычислительной техники МИЭТ. Область научных интересов: распознавание образов и обработка изображений, биометрические системы безопасности, системы слежения. E-mail: turkin@olvs.miee.ru
Сотников Александр Васильевич - инженер НИИ ВС и СУ МИЭТ.Область научных интересов: цифровая обработка изображений, распознавание образов, биометрические системы безопасности, автоматическое сопровождение объектов на видеоизображениях, стохастическое моделирование систем массового обслуживания. Шипатов Андрей Владимирович - кандидат технических наук, доцент кафедры вычислительной техники МИЭТ. Область научных интересов: разработка универсальных малогабаритных высокопроизводительных средств вычислительной техники, сжатие видеоинформации, корреляционный анализ, фильтрация изображений, выделение и сопровождение объектов на видеоизображениях.
