CC BY
0
УДК 658.5
DOI: 10.24412/2071-6168-2024-1-368-369
ОСОБЕННОСТИ ПРОЦЕССА АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ВСТРАИВАЕМЫХ СИСТЕМ И ВОЗМОЖНОСТЬ ИХ РЕАЛИЗАЦИИ В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ ПРОЕКТИРОВАНИЯ
МИКРОПРОЦЕССОРНЫХ СИСТЕМ
А.Ахмад, Е.В. Ляпунцова
В настоящей работе рассматривает усовершенствованный метод формирования параметров встраиваемых систем (ВС) на основе анализа существующих описательных моделей и стандартов. Предложенная модель учитывает специфику аппаратной и программной части ВС, позволяя эффективно распределять требования между программными и аппаратными компонентами. Методика работы с требованиями, включающая итеративный процесс и построение архитектуры программного обеспечения, способствует детальной идентификации функциональных параметров микропроцессорных систем и повышению эффективности процесса проектирования. Работа также включает использование UML-диаграммы последовательности этапов и матрицы трассировки в IBM Rational RequisitePro для обеспечения последовательности изменений и проверки параметров микропроцессорных систем. Внедрение усовершенствованного метода и модели предоставляет инструментарий для более эффективного формирования параметров встраиваемых систем.
Ключевые слова: микропроцессорные системы, встраиваемые системы, параметры систем, методология проектирования, программное обеспечение, аппаратные компоненты, требования, UML-диаграмма, матрица трассировки, эффективность проектирования.
Введение. Встраиваемые системы (ВС) представляют собой особый класс систем, содержащих аппаратные и программные компоненты [1]. Процесс проектирования встраиваемых систем начинается с создания технического задания проекта, т.е. регистрации требований к системе. Далее создается архитектура системы, в которой программные и аппаратные средства разделены, что соответствует порядку проектирования микропроцессорных систем (МС). Конструкция аппаратного и программного обеспечения проектирования МИ определенным образом распределена во времени [3]. Поэтому после внедрения они должны быть отдельно проверены (Рис. 1). С одной стороны, это вызывает сложности в процессе проектирования МС, а с другой - обеспечивает существенное улучшение характеристик конечного изделия по сравнению с альтернативными вариантами конструкторских решений.
Массовое проектирования МС основан на методологии повторного использования ТЗ [2] и позволяет существенно сократить сроки проектирования за счет повторного использования ранее реализованных и протестированных программно-аппаратных компонентов системы. Кроме того, поставляемое с ними специализированное программное обеспечение, высокоуровневый язык программирования и большое количество стандартных функций и библиотек упрощают написание и отладку программного обеспечения для проектирования МС [4].
Следует отметить, что вывод на широкий рынок готовых программно-аппаратных платформ для проектирования МС поставил перед их разработчиками задачу по универсализации доступа и работы с этими устройствами. Однако, из-за шаблонного принципа построения ВС стали проблемы использования таких платформ. Так, для реализации сложного функционала системы иногда приходится совмещать выбранную платформу с платами расширения (включая адаптация системы микроконрол-леров), что приводит к увеличению стоимости и времени разработки, а это обычно не-
допустимо при проектировании микропроцессорной техники. Поэтому, чтобы правильно выбрать аппаратные и программные платформы, необходимо учитывать ряд факторов, основными из которых являются требования к МС. Тогда дальнейшее корректное распределение требований между программными и аппаратными компонентами архитектуры на этапе высокоуровневого проектирования является одним из важнейших факторов успеха при реализации узкосерийного производства МС.
Разработка спецификации
I
Разработка архитектуры МПС
I _
| Распределение задач-^
Проектирование Совместная симу- Пр°ектир°вание й части —
I
Проверка---►Интеграция^-Проверка
аппаратной части — ляция — программных
1
1
Тестирование системы
I
Производство Рис. 1. Обобщенная схема метода проектирования МС
Анализируя распределение времени по стадиям проектирования МС, представленное в работе [7], можно обнаружить, что с увеличением времени, затрачиваемого на этап высокоуровневого проектирования системы, время, затрачиваемое на дальнейшее прототипирование и тестирование, уменьшается. Однако, по мнению экспертов, существенный разрыв, существующий между требованиями к ВС и эффективностью аппаратно-программного проектирования, требуемые объемы верификации и тестирования устройств будут расти [5]. В основном проблема заключается в несогласованности существующих подходов к проектированию МС на фоне современных требований к таким системам.
Таким образом, внедрение модели ВС в разработку МС с нуля с использованием традиционного подхода к проектированию сегодня не эффективна. Именно поэтому в области проектирования МС возникает необходимость применения методологии повторного использования элементов ТЗ, которая позволит ускорить разработку проекта и тем самым сократить время выхода на рынок. Таким образом, дальнейшее развитие методов проектирования МС, а также накопление существующих конструкторских (программно-аппаратных) решений с целью повторного использования являются одними из ключевых направлений повышения эффективности автоматизированного проектирования микропроцессорных систем.
Цель статьи - обосновать подход к автоматизированному проектированию встраиваемых систем и возможность их реализации в программном обеспечении проектирования микропроцессорных систем.
Методы и материал исследования. В качестве материалов исследования ис-
пользовались средства среды разработки AVR Builder. Среда предназначена для создания полного цикла разработки. Разработка программы может производиться как на уровне ассемблера, так и на макроуровне с манипуляциями с многобайтовыми знаковыми значениями. В отличие от классического ассемблера, программа представлена в виде алгоритма с древовидными разветвлениями и отображается на плоскости в двух измерениях. Сеть условных и безусловных переходов отображается графически в удобном векторном виде. Вся логическая структура программы становится визуальной. Наглядность логической структуры снижает вероятность ошибок и сокращает время разработки. Поддерживается автоматическая перекодировка кодовых строк Windows ANSI в русифицированные буквенно-цифровые коды жидкокристаллических индикаторов [9].
Среда сочетает в себе графический редактор, компилятор алгоритмов, симуля-тор МП и МК и программатор. При использовании программатора MCU подключается к COM-порту компьютера через простой адаптер. Algorithm Builder обеспечивает отладку на чипе, которая позволяет наблюдать за содержимым реального чипа в заданной точке останова. При этом для связи MCU с компьютером используется только один контакт, по выбору пользователя. Отладка монитора может быть применена к любому типу кристалла, имеющего SRAM [9]. Поэтому проектировщикам необходимы инструменты для эффективного подбора программно-аппаратной платформы, исходя из требований к проектируемой системе. Внедрение рекомендательной системы, которая поможет разработчику работать с требованиями базовой системы разработки МС Assembler и выбирать основную программно-аппаратную платформу на начальных этапах проектирования системы МС и микроконтроллеров, поможет сократить время на поиск проектного решения.
Логическим было бы внедрение средств дистанционного инжиниринга (удаленных лабораторий, рекомендательных систем) с использованием ВС. Это позволит расширить функциональные возможности существующих программных комплексов, организовать совместное использование оборудования и программного обеспечения, повысить уровень автоматизации проектных работ, а, значит, ускорить процесс проектирования и снизить себестоимость проектируемых изделий.
На основе анализа существующих описательных моделей требований и стандартов, предусматривающих различные виды требований, предложена усовершенствованная модель формирования требований к ВС [5, 6]. В формальной форме эту модель можно представить следующим образом:
СС = { RR, LL, СС},
где RR = {rr i, rr 2, ... , rrmm} — набор параметров МС; LL = {ll 1, ll 2, ... , llnn} - набор уровней параметров МС; CC = {cci, cc 2, ... , cckk} — это множество связей между требованиями.
Как и модели параметров ВС Вигерса и Леффингвелла [5, 6], она имеет 3 уровня, однако, в отличие от предложенных, учитывает структурные особенности МС как совокупности аппаратных и программных компонентов и показывает процесс распределения параметров в требования к программно-аппаратным средствам системы.
В таблице представлены отличительные особенности предложенной модели формирования параметров МС [4] от рассмотренных выше моделей ВС Вигерса и Леффингвелла.
Таким образом, базовая модель формирования параметров ВС, которая описывает все необходимые виды параметров проектирования МС, учитывает специфические особенности аппаратной и производственной части как совокупности аппаратных и программных средств, и, соответственно, распределяет требования между программными и аппаратными компонентами. Это позволяет более полно учесть требования к ВС в программном обеспечении.
Результаты и обсуждение. Для разработанной модели формирования параметров МС предложена методика работы с требованиями к МС [4], схема последова-
тельности этапов которой приведена на рис. 2. Метод позволяет решить задачу определения, анализа и формирования параметров МС к программно-аппаратным компонентам микропроцессоров и микроконтроллеров в комплексе на стадии высокоуровневого проектирования.
В первую очередь осуществляется идентификация исходного ТЗ, разделение их на группы и фиксация параметров МС этих задач в произвольной форме. Следующим шагом является разработка сценариев использования системы путем описания рабочих процессов проектирования. Далее определяются нефункциональные требования (атрибуты качества, ограничения, требования к условиям эксплуатации, интерфейсы).
Таблица 1
Отличительные особенности моделей параметров МС_
Предлагаемая модель Модель Wiegers Модель Леффингвелла
Уровень Пользователь Система Функции Бизнес-требования Требования пользователя функциональный Потребности Функции Требования к программному обеспечению
Тыпи Микропроцессор Программное обеспечение Функциональный Нефункциональный
Интерфейсы Пользователь, Программное обеспечение, Программное обеспечение/пользователь. Пользователь, Программное обеспечение Пользовательский интерфейс.
Определение требований
Рис. 2. UML-диаграмма последовательности этапов метода работы
с требованиями
371
Определение функциональных параметров МС к использованию комплекса ПО подразумевает более детальную идентификацию и трансформацию параметров в полезную для разработчиков форму. Для программного обеспечения предусмотрено построение архитектуры и распределение параметров МС по компонентам системы. Фиксация функциональных параметров МС к программному обеспечению в спецификации параметров МС к каждому виду ПО может быть осуществлена путем представления ожидаемого поведения системы в виде «события-реакции». Эта форма удобна для дальнейшей разработки вариантов тестирования. После каждого этапа определения параметров МС разработанные ТЗ проверяются на наличие ошибок, полноты, однозначности, непротиворечивости и т.д.
Работа с требованиями — это итеративный процесс. Первый этап обычно выполняется один раз (но при необходимости дорабатывается и изменяется), остальные этапы повторяются для каждой новой версии системы.
Матрица трассировки, созданная в IBM Rational RequisitePro [2], позволяет легко определить, какие требования затронуты этим изменением, а какие необходимо проверить при изменении некоторых параметров МС. Трассировка созданных параметров МС в соответствии со схемой разработанной модели формирования параметров МС в RequisitePro выглядит так, как показано на рис. 3.
Рис. 3. Трассировка параметров МС в RequisitePro
На верхнем уровне находятся потребности заинтересованных сторон (идентификатор STRQ для этого типа параметров МС), а также системные требования (SYST), сформулированные на основе потребностей заинтересованных сторон. Сценарии использования (UC) — это описание поведения системы в терминах последовательности действий. Функциональные требования - это требования к функциональности системы, которые обычно формируются бизнес-аналитиком. Целью этих параметров МС является удовлетворение потребностей заказчика. Функциональные требования (FEAT) распределяются между различными видами сопровождения проекта на основе системных параметров МС: FEAT_HW - функциональные требования к аппаратной части производства; FEAT_SW - функциональные требования к программному обеспечению. Дополнительные требования (SUPL) — это другие требования (обычно нефункциональные), которые не могут быть охвачены вариантами использования.
Таким образом, применение усовершенствованного метода работы с требованиями позволит повысить эффективность необходимых процессов работы с требованиями, а именно определения, анализа и формирования параметров МС к программно-аппаратным компонентам ВС.
Список литературы
1. Leffingwell D., Wirding D. Managing Software Requirements: A Use Case Approach. Addison-Wesley, 2003. 402 p.
2. Rykunov М., Mokhov А. Automated Generation of Processor Architectures in Embedded Systems Design, 2010. P. 90-98.
3. Wiegers K. E. Software Requirements: 2nd Edition. Microsoft Press, 2003. 544 p.
4. Бутусов, Денис Николаевич. Автоматизация проектирования встраиваемых систем : диссертация ... кандидата технических наук : 05.13.12 / Бутусов Денис Николаевич; [Место защиты: С.-Петерб. гос. электротехн. ун-т (ЛЭТИ)].- Санкт-Петербург, 2012. 209 с.
5. Зотов В. Система команд микропроцессорного ядра MicroBlaze // Компоненты и технологии. 2004. № 1-3.
6. Зотов В. Средства автоматизированного проектирования и этапы разработки встраиваемых микропроцессорных систем на базе расширяемых процессорных платформ семейства ZYnQ-7000 AP SOC" Компоненты и Технологии, № 3 (152). 2014. pp. 79-88.
7. Зотов В. Функциональное моделирование цифровых устройств, проектируемых на базе ПЛИС фирмы Xilinx в среде САПР WebPACK ISE // Компоненты и технологии. 2002. № 7.
8. Платунов А.Е, Постников Н.П. Высокоуровневое проектирование встраиваемых систем. СПб.: НИУ ИТМО, 2011. 121 с.
Ахмад Али, аспирант, [email protected], Россия, Москва. Университет науки и технологий МИСИС,
Ляпунцова Елена Вячеславовна, д-р техн. наук, профессор, [email protected], Россия, Москва, Московский государственный технический университет им. Н.Э. Баумана
FEATURES OF THE AUTOMATED DESIGN PROCESS FOR EMBEDDED SYSTEMS AND THEIR IMPLEMENTATION IN MICROPROCESSOR SYSTEM DESIGN SOFTWARE
Ahmad Ali, E.V. Lyapuntsova
This article explores an enhanced method for shaping parameters of embedded systems (ES) based on an analysis of existing descriptive models and standards. The proposed model takes into account the specifics of the hardware and software aspects of ES, allowing for the efficient distribution of requirements between software and hardware components. The methodology for handling requirements, including an iterative process and the construction of software architecture, contributes to a detailed identification of functional parameters of microprocessor systems, enhancing the efficiency of the design process. The work also involves the use of a UML sequence diagram and a traceability matrix in IBM Rational Requi-sitePro to ensure the sequence of changes and verification of microprocessor system parameters. The implementation of the improved method and model provides a toolkit for more effective shaping of parameters in embedded systems.
Key words: microprocessor systems, embedded systems, system parameters, design methodology, software, hardware components, requirements, UML diagram, traceability matrix, design efficiency.
Ahmad Ali, postgraduate, ali-ahmad9.3@,mail.ru, Russia, Moscow, Russia, Moscow. MISIS University of Science and Technology,
Lyapuntsova Elena Vyacheslavovna, doctor of technical sciences, professor, [email protected], Russia, Moscow, Bauman Moscow State Technical University
