Microsoft Word впвс book 2011 sev pa doc

1.2.2.3 Методология MDD 
Методология MDD (Model Driven Design, модельно-ориентированный 
подход) для проектирования систем реального времени и встраиваемых систем 
(MDD RTES) является развитием MDA/MDD/MDSD предложенных OMG для 
создания программного обеспечения. Данное направление в большей степени 
развивается 
европейскими 
исследовательскими 
и 
коммерческими 
организациями, в частности ассоциацией ARTEMISIA (Advanced Research & 
Technology for EMbedded Intelligence and Systems Industrial Association) [29] 

---

40 
разработчиков европейской технологической платформы GENESYS (GENeric 
Embedded SYStem platform). Достоинством данного направления является опора 
на многочисленные и широко апробированные языковые (UML) и 
инструментальные средства MDD, применение инструмента метамоделей для 
описания различных (в том числе нефункциональных!) аспектов системной 
архитектуры для различных прикладных и технологических доменов. 
Недостатки MDD RTES являются прямым следствием ее истоков: ориентация 
на создание программного обеспечения, слабая или искусственная адаптация к 
проблематике проектирования аппаратуры, ко-дизайна. 
В следующем параграфе 1.2.2.3.1 дан краткий обзор инструментария MDD 
ВсС. 
1.2.2.3.1 Инструментарий методологии проектирования ВсС MDD 
В части инфраструктуры (framework) MDD RTES наиболее развитым 
видится методологическая и инструментальная инфраструктура в рамках 
упомянутой выше технологической платформы GENESYS. В качестве 
основного языкового средства здесь используются профили OMG UML: 
MARTE (UML profile for Modeling and Analysis of Real Time and Embedded 
systems) и SysML (System Modeling Language). Кроме того предложен 
субпрофиль UML MARTE NFP (Non Functional Properties). Особый и явный 
акцент на анализ нефункциональных требований и свойств на системном 
уровне выгодно отличает платформу GENESYS от иных существующих 
технологий.
C точки зрения инструментария GENESYS предлагает очень широкий 
выбор: от пакетов UML-дизайна от Rational Software до свободно 
распространяемых средств типа Papirus (Grafical UML2 modelling), Times (Tool 
for Modeling and Implementation of Embedded Systems), MAST (Modeling and 
Analysis Suite for Real Time Application) и других. Обратной стороной такого 
разнообразия инструментальных пакетов в методологии GENESYS являются 
значительные трудозатраты и вероятность низкой эффективности сопряжения 
данных средств в рамках одной инструментальной инфраструктуры. В 
настоящее время ассоциация ARTEMISIA декларировала начало работ по 
созданию согласованного, свободно распространяемого пакета программных 
средств.
Ощутимым недостатком GENESYS (упомянутым ранее при описании 
MDD RTES в целом) является явно видимая второстепенная роль средств 
SW/HW Codesign и проектирования уровня микроархитектуры/ESL, то есть 
всего, что касается аппаратных средств. 
Также 
в 
рамках MDD RTES предлагаются 
коммерческие 
инструментальные средства. Можно назвать CoFluent 
Studio [38] и 
Mentor Graphics BridgePointUMLSuite [72]. CoFluent Studio опирается на 
собственную методологию, названную MCSE или CoMES (Codesign 
Methodology for Electronic Systems), которая декларируется как расширение 

---

41 
MDD (Enhance Model-Driven Development). Особенностью CoMES является 
четкая ориентация на создание SystemC модели ESL-уровня и последующий 
выход на проектирование аппаратных средств. Недостатком видятся не очень 
мощные средства архитектурного анализа на верхних уровнях. Пакет 
BridgePointUML Suite, наоборот, ориентирован на создание (автоматическую 
генерацию) встроенного программного обеспечения, хотя декларируются 
работы по развитию его в сторону генерации RTL-кода. 
1.2.2.4 Тенденции развития методик проектирования ВсС 
Выше упомянуты только средства, наиболее интересные и значимые для 
развития области проектирования системного уровня. Вне обсуждения осталось 
большое количество инструментов на базе SIMULINK (MathWorks), так как 
данное направление имеет более коммерческо-прикладную направленность, 
нежели развивает методы проектирования. Более полный обзор существующих 
инструментальных методологий и пакетов в области проектирования 
встраиваемых систем, прежде всего на системном уровне, можно найти в [41, 
52, 79, 67, 53].
Примечательно, что ведущие разработчики САПР в области электроники и 
встраиваемых систем имеют очень ограниченное предложение методик и
инструментов в этой области – концентрируются в основном на средствах 
(под)уровня архитектуры: TLM/RTL-design, SystemC HW/SW co-verification 
(например, System Studio (Synopsys), Palladium Series (Cadence), Vista/Visual 
Elita Series (Mentor Graphics)). Причины этого лежат, скорее всего, в области 
коммерческой эффективности: указанные фирмы продолжают поддерживать 
исследовательские работы в ожидании законченного продукта. 
В завершении попытаемся зафиксировать общие недостатки доступных 
методологий, инструментов и сред проектирования (frameworks), побуждающие 
к определенному выбору и развитию исследовательских работ в области 
системного проектирования для встраиваемых систем: 
Отдельные (особенно нефункциональные) аспекты проектирования 
рассматриваются для системы в целом, в рамках соответствующих 
общесистемных моделей: энергопотребления, надежности, информационной 
защиты и т.п. Это, естественно, объясняется внутренней сложностью и сильной 
взаимозависимостью отдельных архитектурных компонентов системы. С 
другой стороны, ограничены возможности оценки влияния конкретной 
реализации конкретного компонента на аспектные показатели (характеристики). 
Следует разработать такую структуру и форму описания архитектурных 
компонентов, которая будет в явном виде предлагать аспектные оценки (веса). 
Данный подход отразился в понятии архитектурного агрегата (АА), 
обсуждаемого в главе 2. 
Во всех рассмотренных методологиях проявляется явный приоритет 
функционального аспекта на архитектурном уровне. Нефункциональные 
аспекты либо играют роль вспомогательных (второстепенных) критериев 

---

42 
проекта, либо, многие из них, не учтены вообще. Так выпали из рассмотрения 
инструментальный и конструктивно-технологический аспект. Что касается 
приоритетов аспектов, то функциональность не всегда (не для всех 
приложений) может быть основной. Например, требования реального времени 
могут отвергать функциональные требования обязательной доставки данных по 
сети; или набирающая популярность концепция вероятностной логики может 
повышать приоритет аспекта энергопотребления над точностью вычисления 
функций. Данные вопросы должны быть учтены при разработке инструмента 
архитектурного описания системы. 
Пространство вариантов реализации архитектурных компонентов остается 
в основном в рамках HW/SW фазы runtime. Варианты Design/Run Time, 
варианты различных уровней виртуализации архитектуры не учитываются в 
рамках системного проектирования.