Содержание к диссертации
Введение
1. Проблемы проектирования вычислительных систем 9
1.1. Введение. 9
1.2. Традиционный процесс проектирования 9
1.2.1. Кризис методик проектирования 15
1.3. Современные тенденции в проектировании встроенных систем 16
1.3.1. Hardware-Software CoDesign 17
1.3.2. Концепция платформно-ориентированного системного проектирования 19
1.3.3. Аспектная модель процесса проектирования 22
1.3.4. IRSYD 23
1.3.5. Проектирование SoC и reuse-технологии 25
1.4. Модели вычислений встроенных систем 26
1.4.1. Сеть обработки потоков данных (Dataflow Process Network) 29
1.4.2. Взаимодействующие конечные автоматы (Communicating FSM) 30
1.4.3. Модель дискретных событий (Discrete-Event) 30
1.4.4. Синхронная модель вычислений (Synchronous/Reactive) 31
1.5. Понятие распределенной информационно-управляющей системы 33
1.5.1. Абстрактные информационные системы 34
1.5.2. Абстрактные управляющие системы 35
1.5.3. Распределенность информационно-управляющих систем 36
1.5.4. Особенности распределенных информационно-управляющих систем 38
1.6. Выводы 39
1.7. Постановка задачи 41
2. Архитектурное проектирование встроенных систем 42
2.1. Введение 42
2.2. Архитектурная модель встроенных систем. 43
2.2.1. Понятие архитектуры, архитектурные агрегаты 43
2.2.2. Аспектное пространство процесса проектирования и целевой системы 45
2.2.3. Аспектные проекторы и аспектные модели. 46
2.2.4. Характеристические функции аспектних моделей, ортогональность аспектов.48
2.2.5. Классификация архитектурных моделей 50
2.3. Элементы архитектурного проектирования 54
2.3.1. Роль моделирования в архитектурном проектировании встроенных систем 54
2.3.2. Поведенческий аспект архитектурной модели 57
2.3.3. Инструментальный аспект архитектурной модели 58
2.3.4. Архитектурная платформа 60
2.3.5. Критерии архитектурного проектирования 63
2.4. Выводы 65
3. Модель вычислений распределенных информационно- управляющих систем . 67
3.1. Введение 67
3.2. Способы описания распределенных информационно-управляющих систем 67
3.2.1. Диаграммы потоков данных и управления 68
3.2.2. Целевое прикладное программирование 68
3.2.3. Аналогия с "аппаратным" блоком 70
3.3. Объектно-событийная модель вычислений РИУС 72
3.3.1. Общие положения объектно-событийной модели 72
3.3.2. Элементы объектно-событийной модели. 75
3.3.3. Расчет временных характеристик объектно-событийной модели . 90
3.4. Выводы. 99
4. Использование осмв в проектировании риус 101
4.1. Введение ЮГ
4.2. Целевые проекты. 101
4.2.1. КСЗМ. 102
4.2.2. КТЖ-2 103
4.2.3. СПКОПиУ-01Ф 104
4.3. Организация вычислительного процесса 106
4.3.1. Вычислительный процесс КСЗМ.. 106
4.3.2. Вычислительный процесс КТЖ-2 107
4.4. Реализация средств пользовательского программирования 108
4.4.1. Средства пользовательского программирования проекта КСЗМ. 111
4.4.2. Средства пользовательского программирования проекта СПКОПиУ-01Ф 113
4.5. Реализация коммуникационной среды 117
4.5.1. Коммуникационная среда проекта КТЖ-2 120
4.5.2. Коммуникационная среда проекта СПКОПиУ-01Ф:. 122
4.6. Выводы 123
5. Инструментальный аспект процесса проектирования встроенных систем . 125
5.1. Введение 125
5.2. Инструментальные средства встроенных систем 125
5.3. Инструментальный комплекс вложенной отладки РИУС 130
5.3.1. Инкапсуляция инструментальной коммуникационной среды в целевую. 133
5.3.2. Инкапсуляция целевой коммуникационной среды в инструментальную. 134
5.4. Динамические инструментальные компоненты. 137
5.5. Средства обновления ПО РИУС. 139
5.6. Реализация модели потоков данных средствами ОСМВ в рамках КМС. 142
5.7. Выводы 145
Заключение 146
Список литературы. 147
- Концепция платформно-ориентированного системного проектирования
- Распределенность информационно-управляющих систем
- Роль моделирования в архитектурном проектировании встроенных систем
- Расчет временных характеристик объектно-событийной модели
Введение к работе
Взрывной рост потребности в информационно-управляющих системах (ИУС) различного назначения на современном этапе заставляет разработчиков активно совершенствовать способы и средства проектирования. Значительную долю ИУС составляют встроенные системы (ВсС) (embedded systems), которые традиционно определяются как специализированные (заказные) микропроцессорные системы, непосредственно взаимодействующие с объектом контроля или управления и объединенные с ним единой конструкцией. ВсС находят широкое применение в бытовой электронике, промышленной автоматике, на транспорте, в телекоммуникационных системах, медицинском оборудовании, в военной и аэрокосмической технике.
Проектирование ВсС характеризуется высокой сложностью. В значительной мере это определяется специфическими требованиями технического задания и, как следствие, необходимостью применения технических решений, нетиповых для иных вычислительных систем (ВС). Дополнительную сложность при проектировании вызывают такие особенности систем, как многопроцессорная гетерогенная организация, распределенный характер вычислений, широкий диапазон вычислительных ресурсов элементной базы и т.д. Указанные особенности в большей степени характерны для распределенных .информационно-управляющих систем (РИУС), составляющих значительную часть современных ВсС.
Возрастающий спрос на ВсС различного назначения и сложности, ряд принципиально новых достижений в области вычислительной техники и интегральной технологии требуют пересмотра подходов, лежащих в основе проектирования специализированных микропроцессорных систем.
Увеличение производительности проектирования и повышение качества ВсС в первую очередь возможно за счет создания сквозной автоматизированной технологии проектирования. К настоящему моменту закрыты этапы низкоуровневой реализации (схемотехническое проектирование, конструирование, этап кодирования ПО). Актуальным является создание САПР системного уровня.
Целью работы является конкретизация и формализация базовых принципов аспектнои модели процесса проектирования и демонстрация результативности данного подхода при решении практических задач проектирования ВсС.
Для достижения указанной цели в работе решены следующие задачи:
Исследован традиционный процесс проектирования ВсС и соответствующие методики. Выявлены причины, определившие кризис проектирования ВсС.
Проанализированы современные тенденции в проектировании ВсС, определено перспективное направление развития исследований.
Определено понятие архитектурной модели вычислительных систем, которое можно рассматривать в качестве основы перспективных методик проектирования ВсС. Формализованы базовые понятия аспектной модели процесса проектирования ВсС, необходимые для построения САПР системного уровня.
В рамках аспектного подхода к процессу проектирования ВсС определена роль моделирования. Проанализированы различные модели вычислений, создана объектно-событийная модель вычислений (ОСМВ) РИУС.
Разработан математический аппарат для: расчета характеристик ОСМВ. Указаны критерии структурно-функциональной декомпозиции при синтетическом и аналитическом способе построения модели РИУС.
Предложены типовые шаблоны организации вычислительного процесса РИУС согласно ОСМВ.
Сформулировано понятие инструментального аспекта процесса проектирования ВсС. Определены основные инструментальные задачи ВсС.
Методическую базу исследования составляют положения линейной алгебры, теории вероятностей, теории множеств, формальной логики, теории конечных автоматов, теории графов, имитационного моделирования.
Научную новизну представляют:
Формализация базовых понятий аспектной модели процесса проектирования ВсС. Определение архитектурной модели и доказательство важных принципов ее построения.
Введенное понятие "архитектурной платформы", которое позиционируется как мощный инструмент повторного использования концептуальных решений в процессе проектирования ВсС.
Разработанная объектно-событийная модель вычислений РИУС, учитывающая реактивность систем, различные временные масштабы и распределенность вычислительного процесса, неоднородность элементной базы.
Предложенные методы расчета характеристик ОСМВ, формально учитывающие варианты реализации отдельных узлов модели и являющиеся
алгоритмической базой САПР РИУС. Для проведения расчетов формализованы трактовки программной и аппаратной реализации компонентов.
Разработанная трехуровневая модель интерпретатора прикладных пользовательских алгоритмов с возможностью структурно-функциональной деградации, рассчитанная на реализацию как программным, так аппаратным способом.
Введенная система требований идентификации компонентов коммуникационной среды РИУС, позволяющая гибко управлять трудоемкостью и ресурсоемкостью разработки системы в зависимости от уровня целостности и функциональной завершенности проектируемой системы.
Предложенное понятие инструментальной модели ВсС, позволяющее формально учитывать требования инструментальной поддержки в процессе проектирования.
Практическая ценность работы заключается в создании средств обеспечения прикладного пользовательского программирования РИУС, реализованного на базе трехуровневой модели прикладного интерпретатора, позволяющей легко адаптировать предложенную технологию для широкого круга ИУС различной степени сложности. Предложения по организации коммуникационной среды РИУС, учитывающие инструментальные требования,, легли в основу ряда коммуникационных протоколов, примененных в различных проектах, что позволило повысить эффективность проектирования за счет повторного использования инструментальных технологий при решении задач вложенной отладки.
Практическое воплощение результаты работы получили более чем в 20 НИР и НИОКР, в числе которых наиболее крупными и показательными следует считать: контроллер сканирующего зондового микроскопа (КСЗМ), комплекс технических средств для организации пространственно распределенных систем; промышленной автоматики (КТЖ-2), система приемно-контрольная охранно-пожарная и управления (СПКОПиУ-01Ф), многофункциональный контроллер для встроенных применений (МЕС5091), микропроцессорный контроллер локального управления CSC-1.0, комплекс технических средств железнодорожной автоматики "Тракт" и др.
Результаты работы использованы в учебных курсах кафедры Вычислительной Техники СПбГУИТМО по направлениям инженерной и магистерской подготовки (специальности 22.01.00 и 55.28.20).
Апробация работы произведена в 10 докладах на 8 конференциях. Основные результаты диссертации опубликованы в 6 работах.
Концепция платформно-ориентированного системного проектирования
Данная концепция проектирования появилась несколько лет назад в контексте комплексного системного проектирования аппаратно-программных ВсС и занимает особое место среди перспективных технологий решения задач проектирования. Основные положения данной концепции отражены в работе [84,81,74,51]. Авторы концепции утверждают, что она позволит повысить производительность проектируемых систем, снизить их стоимость, стоимость разработки, а главное - позволит повторно использовать как аппаратные, так и программные компоненты разрабатываемых систем.
Основной упор в своей работе авторы делают на качественное повышение коэффициента повторного использования на всех этапах проектирования ВсС. В жестких условиях рынка решением является: повторное использование компонент системы (плат или их частей, драйверов, интерфейсов и т.п.). Для лучшей проработки альтернативных решений, что важно для повторного использования, предлагается рассматривать систему с двух ракурсов и с различных точек зрения: функциональность (что система делает) и архитектуру (как система это делает); взаимодействие (обмен данными) и вычисления (выполнение целевой функции системы). Функциональность может определяться либо разработчиком, либо заказчиком. В первом случае в процесс разработки включается этап функционального проектирования. Архитектура определяет интерфейс и описывает функциональность реализации. При этом она должна не зависеть от реализации. Кроме архитектуры авторы вводят понятие ц-архитеткуры или микроархитектуры, ц-архитектура — функционально завершенный набор вычислительных компонент (микропроцессор, периферия, программируемая логика, память). При проектировании разработчик должен руководствоваться следующими принципами [84]: время и цена разработки определяют процесс принятия решений; проектирование должно вестись на высоком уровне абстракции; нужно делать надежные, устойчивые системы; в системе должно быть несколько сложных и много простых аппаратных компонент; программирование этих компонент будет производиться на разном уровне. В концепции платформно-ориентированного системного проектирования основным понятием является понятие платформы. Авторы выделяют аппаратную и программную платформу, они присутствуют в каждом проекте, и их объединение составляет системную платформу. Аппаратная платформа - это множество архитектур вычислительных машин, позволяющее решать поставленную задачу. При проектировании ограничения архитектуры обычно определяются в терминах производительности и размеров. Обычно в аппаратной платформе больше возможностей, чем требуется от проектируемой системы. Нет смысла использовать аппаратуру, пригодную для решения единственной задачи. Программная платформа - абстрактный уровень взаимодействия программы с аппаратурой. Основная идея - это разработка платформно-независимого API. Т.е. между программой и аппаратурой вставляется программный слой, унифицирующий работу программы с некоторым набором аппаратуры. К программной платформе относят: операционную систему (обычно ОСРВ), распределяющую аппаратный ресурс; драйверы устройств, обеспечивающие подсистему ввода/вывода; сетевую подсистему, обеспечивающую взаимодействие компонент вычислительной системы. Примерами программных платформ являются продукты фирм ISI, WindRiver, Microsoft (Windows СЕ), QSSL (QNX), POSIX [95]. Системная платформа, как уже говорилось, объединяет аппаратную и программную платформы. В начале проектирования обе платформы являются абстракциями. Причем чем выше эта абстракция, тем лучше, тем больше свободы в выборе решений по конкретизации системы. Нежелательно преждевременное разделение функций между аппаратурой и программой. Проектируемая система с добавлением ограничений (быстродействие, габариты, надежность, потребление энергии, доступное API, наиболее подходящая ОСРВ и т.п.) уточняется (актуализируется) и вариантов ее реализации остается все меньше и меньше. В итоге получается единственное решение: однозначный выбор аппаратуры и определенная программистская модель. Среди примеров применения своей методики авторами указываются как разработки сторонних фирм, так и результаты собственного проекта MESCAL. В первом случае рассмотрены система передачи видеоинформации (Philips), контроллер управления двигателем (Magneti-Marelli) и беспроводная сеть (Berkley Wireless Research Center). В каждом из примеров приводится архитектура системы, этапы выбора программной платформы, объем кода (строки кода) и т.п. Проект MESCAL (Modern Embedded Systems, Compilers, Architectures and Languages) реализуется для определения эффективности использования методики платформно-ориентированного проектирования. По результатам анализа проектов складывается ощущение, что в данном исследовании чрезмерное влияние уделяется программной платформе. Как ив большинство подобных концепций, данная концепция не обладает достаточной завершенностью, чтобы предложить разработчику относительно конкретные рецепты проектирования. Тезисы предлагаемой методики верны и известны многим разработчикам. Проблема в том, что методика говорит как проектировать, т.е. как нужно делать, а не что нужно делать. Еще одним подходом к преодолению кризиса проектирования ВсС можно считать аспектную модель процесса проектирования ВсС [24,21,74]. В рамках такого рассмотрения процесса проектирования предлагается создать единое пространство проектирования ВсС в терминах абстракций (вычислительных механизмов, функциональных преобразователей, виртуальных машин и др.). Критериями создания такого пространства должны являться [24]: Унификация традиционных трактовок hardware и software; Рассмотрение всех этапов проектирования ВсС как эквивалента программирования; Представление проектируемой ВсС в рамках возможно большего количества шагов проектирования (от начала) "в чисто вычислительном базисе" (в терминах вычислительных абстракций); Поиск решений по организации ВсС в объединенном пространстве "фаза проектирования — фаза исполнения (эксплуатации)"; Использование "аспектной технологии", которая позволяет явно проследить трансформации ключевых составляющих ВсС по ходу проектирования (функциональный, инструментальный, надежностный аспект и т.д.) и учесть в процессе проектирования дополнительные факторы. Речь идет о факторах, которые явно (или вообще) не присутствуют в ТЗ, но серьезно влияют на результаты проектирования (инструментальный аспект, возможности коллектива, доступные технологии, учет задела и интересов коллектива и др.). В аспектной технологии можно говорить о двух объектах верхнего уровня, с которыми имеет дело разработчик [74]: архитектура проекта (framework) и архитектура продукта (проектируемой ВсС). Эти архитектурные представления содержат в себе все составляющие соответственно процесса проектирования и создаваемого продукта. Такие составляющие именуются аспектами проектирования (или просто аспектами). Основным подходом в проектировании системы становится построение сложной, разноплановой, полнофункциональной модели ВсС с учетом заранее определенных ограничений и последующим отображением модели на ту или иную элементную базу. Разноплановое, охватывающее многие (все) аспекты системы, представление называется архитектурным представлением системы. Отдельные элементы такого представления называются агрегатами, т.к. они объединяют совершенно разнотипные аспекты системы. Т.о. архитектурный агрегат представляет собой базовый элемент процесса проектирования системы. Архитектурные агрегаты могут иметь различную степень абстракции, представлять собой технические решения или конкретные вычислительные узлы, определять разное количество аспектов для описываемого элемента.
Распределенность информационно-управляющих систем
В некоторых случаях внешняя среда (объект управления) ИУС может простираться в пространстве на значительные расстояния или же ввиду жестких условий эксплуатации, ограничений габаритов, климатических требований, нехватки вычислительных ресурсов невозможно сосредоточить всю систему управления на одном единственном физическом вычислителе. В этих случаях необходимо разрабатывать распределенную ИУС (РИУС).
Распределенная информационно-управляющая система выполняет свою целевую функцию, реализованную на нескольких (возможно неравноправных) связанных друг с другом вычислительных компонентах. Пространственная удаленность вычислителей, на которых реализованы вычислительные компоненты, друг от друга не играет особой роли, хотя зачастую она также имеет место.
Можно выделить два типа связи между вычислительными компонентами в составе РИУС. Вычислительные компоненты, являются слабо связанными в том случае, когда объем данных, передаваемых между ними много меньше обрабатываемого ими объема данных. С точки зрения MB на уровне декомпозиции на процессы, для такой системы интенсивность потоков данных между вычислительными компонентами значительно меньше объемов данных потоков в пределах функциональности каждого вычислительного компонента. Т.е. на уровне коммуникаций между вычислительными компонентами можно применить MB дискретных событий.
В общем случае свойство распределенности ИУС имеет два проявления: пространственная распределенность и распределенность вычислительного процесса, при этом оба проявления в значительной степени взаимосвязаны.
Пространственная распрделенность может быть вызвана территориальной разнесенностью датчиков и исполнительных устройств, которые должны быть связаны в единую систему (например, охранные системы зданий или системы автомобильной электроники).. При этом совершенно необязательно р иметь в системе распределенное управление (т.е. распределенный вычислительный процесс). Каждый; датчик и исполнительной устройство могут представлять собой достаточно простой узел, а управление всей системой может осуществляться с центрального вычислителя.
В других случаях необходимо обеспечивать распределенность вычислительного процесса в рамках одного устройства (например, блок оцифровки и фильтрации сигнала и блок передачи данных по сети). В этом случае эти разные функции можно назначить разным вычислителям, находящимся на одной плате. В конечном итоге благодаря распределенности системы разработчик вынужден работать со сложным иерархическим комплексом вычислительных узлов, объединенных некоторой коммуникационной подсистемой и решающих общую задачу.
Распределенность вычислительного процесса неявно подразумевает одновременную и параллельную работу вычислительных компонентов. Даже если функциональность каждого из компонентов может быть задана в терминах комбинаторного выражения (без сохранения собственного состояния) или последовательного выражения (с сохранением собственного состояния) вся система функционирует как согласованное взаимодействие таких вычислительных компонентов, которых в реальной ИУС может быть несколько.
Особенностью ИУС является тот факт, что в общем случае она должна взаимодействовать с внешней средой, процессы в которой протекают с определенной скоростью. Это относится как к информационным системам, т.к. скорости информационных потоков могут значительно отличаться, так и к управляющим системам, т.к. масштаб времени: протекания физических процессов в объекте управления может также существенно отличаться для различных объектов и различных рассматриваемых процессов. Сама распределенность системы предполагает работу в гетерогенной внешней среде, так что различные части системы должны функционировать в собственном масштабе времени. Это одна из основополагающих причин, по которой для РИУС неприемлемо использовать синхронную MB. Синхронная MB подразумевает наличие событий для всех сигналов в каждый момент времени по всей системе, что распространяет один масштаб времени на всю разнородную ИУС. Этот масштаб должен отражать самый быстрый процесс протекающий в системе, и его распространение на всю систему целиком приводит к неоправданным затратам при реализации системы, т.к. большую часть времени целевая система будет работать вхолостую.
Зачастую, в контексте целевой - функции к управляющей системе выдвигаются дополнительные требования формирования управляющих воздействий в жестких временных рамках. Требуемые временные рамки реакции системы, в дальнейшем будет использоваться словосочетание "требования РМВ", могут быть заданы двумя способами: в абсолютных единицах времени или относительно состояний объекта управления. Оба способа определения требований реального времени широко применяются как отдельно, так и в композиции друг с другом.
Часто требования РМВ рассматриваются на начальных этапах разработки системы, в процессе формализации ТЗ. Позже, выработанные на данном этапе требования, влияют на выбор элементной базы и способ реализации тех или иных компонентов РИУС.
Рассмотрение меток (моментов) времени в абсолютной шкале или в относительной позволяет получить две различные MB таких систем. В общем случае время является атрибутом события и может быть глобально или частично упорядоченным, приводя к соответствующей упорядоченности событий в системе. Вместе с упорядочиванием событий можно рассматривать такие характеристики как временные интервалы между отдельными событиями.
В случае MB с глобально упорядоченными временными; метками разработчик имеет дело с абсолютными временными метками. Данные метки имеют одинаковый смысл и задают единый масштаб времени для всей системы целиком. Обычно эти временные метки тем или иным образом отражают ход физического времени. Как было сказано выше, такой подход неудобен для РИУС, так как природа физических процессов, с которыми такие системы имеют дело, различна и диктует собственные индивидуальные временные масштабы. Кроме того, реализация системы с едиными синхронизированными временными метками представляет собой очень сложную техническую задачу.
MB: с частично упорядоченными временными метками позволяет описать и реализовать систему, части которой функционируют в своих собственных временных масштабах. Проблему синхронизации временных меток необходимо решать только на уровне коммуникационных связей между вычислительными компонентами таких систем. Для поддержания собственного масштаба времени различные части системы могут иметь различные времязадающие подсистемы и элементы тактирования. В некоторых случаях масштаб времени может непосредственно определяться внешней средой и быть различным для различных частей сложной РИУС.
Роль моделирования в архитектурном проектировании встроенных систем
Видно, что предложенный выше подход к проектированию ВсС базируется на широком использовании различных моделей разного уровня абстракции и направленности. Собственно сам процесс проектирования превращается в управляемый и контролируемый процесс эволюции множества моделей, подчиненный внешним ограничениям.
Моделирование системы в процессе проектирования достаточно сложный и разноплановый процесс, тесно связанный с верификацией. Моделировать проектируемую ВсС можно на разных уровнях абстракции и применять при этом различные средства и языки моделирования. Процесс проектирования ВсС имеет определенные отличия от проектирования программных комплексов или приложений баз данных. Эти отличия в основном заключаются в том, что при проектировании ВсС почти всегда необходимо разрабатывать аппаратную составляющую системы. Сложность и ответственность разработки этих компонент не меньше, а во многих случаях и больше, чем сложность программной компоненты ВсС.
При проектировании ВсС моделирование призвано решать следующие задачи: верификация (целевая и эквивалентная), виртуальное прототипирование, реализация компонентов системы (hardware и software), специфицирование и документирование разрабатываемых компонент.
В настоящее время существует несколько способов или уровней описания модели ВсС. Для проведения успешной разработки необходимо иметь модели системы различных уровней абстракции и подробности. Модели могут описывать систему в целом или отдельные вычислительные узлы системы. В таблице 2.1 приведена оценка применимости некоторых "собирательных" языковых средств для описания моделей ВсС различных уровней абстракции. UML — Unified Modeling Language [97]. Язык может быть успешно применен для моделирования всей системы целиком на высоких уровнях абстракции или отдельных программно реализуемых вычислительных узлов. Абстрактное описание вычислительного узла с помощью UML не очень удобно, т.к. собственно UML для этого не очень подходит по своим возможностям. Недостатком языка следует считать слаборазвитый инструментарий для поддержки проектирования. HLL - High Level (Programming) Language. Традиционные высокоуровневые языки программирования. Отлично подходят для описания и иногда могут быть использованы для моделирования программно реализованных узлов. Несколько хуже язык подходит для описания аппаратно реализованных узлов. HDL - Hardware Description Language. Группа языков, специально разработанная для описания аппаратуры. Постепенно по мере развития этих языков, они стали? использоваться для моделирования аппаратной системы и даже для синтеза аппаратно реализованных узлов. RTL - особая группа HDL, предназначенная для описания именно аппаратных узлов системы на уровне регистровых передач. В отдельных случаях формально можно использовать эти языки для описания и более крупных модулей. В рамках проектирования ВсС процесс моделирования выглядит следующим образом. На начальных этапах проектирования модель представляет собой высокоуровневое поведенческое описание системы. Данное описание необходимо верифицировать на адекватность решаемой целевой задаче. Собственно получение такой модели сам по себе достаточно сложный процесс, идущий параллельно с целевой верификацией и системным проектированием. Однако, после создания полной модели системы, ее необходимо "реализовать". Реализация модели заключается в следующем: Принять решение о способе реализации каждого механизма построенной модели; Получить перечень стандартных; компонентов (микропроцессоров, микроконтроллеров, интерфейсов, протоколов и т.д.), используемых в системе; Получить объектный код для программно реализованных компонент (SW реализация); Получить конфигурацию программируемой логики для аппаратно реализованных компонент (HW реализация). В процессе эволюции моделей системы можно выделить значимый момент, к которому у разработчика формируется так называемая "золотая" модель системы. "Золотая" модель - верифицированная и зафиксированная архитектурная модель системы, не ограничивающая способов реализации. "Золотая" модель может быть реализуемой А-моделью или как максимум виртуальной. Абстрактная А-модель требует дальнейшей проработки и не пригодна для реализации. Наряду с "золотой" А-моделью можно говорить и об "золотых" АСМ.
Моделирование на начальных этапах связано с доказательством адекватности разработанной архитектуры начальным требованиям. Разработчик на этих этапах вынужден применять достаточно сложные методы "функциональной" верификации. Зачастую такие методы носят полуформальный характер и. относительно слабо поддержаны инструментальными средствами. Данный тип верификации призван доказать соответствие полученных характеристик А-модели (или частных АСМ) и сформулированных в требованиях к системе характеристик.
При окончательном: формировании; "золотой" модели процесс моделирования переходит в фазу реализации. На этом этапе моделирование направлено на верификацию отдельных узлов, а не всей системы в целом, и призвано доказать эквивалентность реализаций. В конечном итоге задача разработчика доказать эквивалентность полученных при реализации характеристик и характеристик, заданных "золотой" моделью. На этом этапе преобладают сравнительно простые, но трудоемкие методы эквивалентной верификации и для большинства преобразований существуют специальные САПР.
Еще одной важной задачей "золотой" модели становится создание исходных спецификаций для разработчиков, которые занимаются конечной реализацией компонентов и узлов системы. При этом, являясь AM, "золотая" модель специфицирует не только непосредственно конечную функциональность, но и такие моменты как параметры обеспечения параллельности, допустимые; пределы энергопотребления, необходимые механизмы надежности, перечень документов, необходимый уровень инструментальной поддержки- и многое другое. Нужно отметить, что правильно организованное моделирование обеспечивает специфицирование и документирование проекта на всех этапах и различных уровнях абстракции.
Поведенческий; аспект "золотой" модели, являясь отправной точкой реализации hardware и software, представляет собой формальное поведенческое описание системы в терминах некоторой модели вычислений. В процессе реализации этой "золотой" модели постепенно получаются "синтезируемые" software и hardware описания, методы получения которых могут существенно различаться для разных узлов системы.
Инструментальный аспект, обладая высокой сложностью и всесторонним влиянием на другие аспекты проектирования, определяет потенциальный уровень сложности разработок коллектива. Исследованные в работе поведенческий и инструментальный аспекты являются необходимыми для формирования аспектной модели проектирования, применимой на практике [24].
Расчет временных характеристик объектно-событийной модели
При проектировании всей; системы целиком на начальном этапе она рассматривается как один; большой ФБ,. временные параметры которого можно взять из спецификаций на систему. По этим временным параметрам необходимо сформировать первую временную передаточную матрицу. В дальнейшем, при структурной декомпозиции ФБ, анализируя получаемое каждый раз разбиение, разработчик, опираясь на приведенные критерии (3.2) и (3.3), экспертные оценки и свой собственный опыт, составляет оптимальные временные передаточные матрицы мелких ФБ. При этом разработчик должен обеспечить корректность декомпозиции матрицы, т.е. временные передаточные матрицы мелких ФБ не должны противоречить временной передаточной матрице основного ФБ. Двигаясь таким образом, каждый раз анализируя разбиение, разработчик получает оптимальные (желаемые) временные передаточные матрицы АФБ.
Если разработчик начнет двигаться от АФБ к более крупным блокам; то на каждом; шагу он будет получать временные передаточные матрицы синтетическим способом. При таком способе получения: рассматриваемых характеристик их значения получаются с помощью конкретных аналитических выражений и инструментальных средств.
АФБ, обладающий законченной и конкретной функциональностью и отображенный на конкретный целевой узел, позволяет достаточно точно оценить его ресурсоемкость и другие параметры (процессорное время, ресурсы памяти, объем логических ячеек, энергопотребление и т.д.). Основываясь на таких конкретных данных, разработчик имеет возможность составить фактическую (для данного отображения) временную передаточную матрицу. В дальнейшем, при композиции мелких ФБ в более крупные, очередные временные передаточные матрицы будут синтезированы автоматически. При этом такие синтезированные временные передаточные матрицы будут содержать фактические данные, характерные именно для рассматриваемого отображения на целевые узлы.
Преимуществом первого способа является то, что для его осуществления нет необходимости производить отображение ФБ на целевые узлы. Разработчик конкретизирует функциональность отдельных частей системы, одновременно формируя временные требования на реализацию. Недостатком следует считать принципиальную возможность того, что для финального разбиения на АФБ не найдется реализации в элементной базе выбранной А-платформы, удовлетворяющей желаемым временным передаточным матрицам.
Преимуществами второго способа получения временных передаточных матриц-являются: оперирование фактическими временами, полученными при анализе АФБ; относительно формальный метод синтеза крупных временных передаточных матриц. К недостаткам такого метода следует отнести необходимость рассмотрения полностью проработанной модели, отображенной на целевые узлы системы и необходимость проектирования снизу вверх, что противоречит основным тенденциям стиля проектирования в настоящее время. Кроме того, полученная синтетическим методом временная передаточная матрица всей системы целиком может не удовлетворять требованиям к системе. Следует указать, что синтетический метод получения временных передаточных матриц будет отлично работать при оценке модели с целью проведения верификации. Единственным выходом в сложившейся ситуации видится совмещение указанных двух способов. Проводя аналитическое построение частных временных передаточных матриц, помимо опыта и экспертных оценок, разработчик может использовать синтетический метод получения фактических временных передаточных матриц для сложных частей модели, значительно упрощая их и наискорейшим образом приводя к АФБ. Для известных разработчику А-платформ и знакомых композиций ФБ, экспертные оценки и опыт могут дать прекрасный результат и без синтеза фактических временных передаточных матриц. Необходимо отметить, что использовать непосредственно временную передаточную матрицу ФБ не слишком удобно. Проблема заключается в том, что один и тот же АФБ, отображенный на разные узлы целевой системы, будет иметь различные временные передаточные матрицы. Это связано с тем, что в принципе одна и та же ресурсоемкость реализации алгоритма для разных физических вычислителей реально может потребовать различных ресурсов. Инвариантной к отображению ФБ на элементы вычислительной платформы является описанная выше матрица сложности генерации выходного события (3.1). Если рассмотреть пример стека виртуальных машин (таблица 3.1), в конечном итоге исполняющий алгоритм АФБ, то становится понятно, что эффективность реализации алгоритма АФБ в конечном итоге зависит от эффективности реализации каждого уровня стека в базисе нижележащего уровня. Кроме того, на этапе оценки эффективности такого рода реализаций необходимо учитывать качество используемых инструментальных средств. Видно, что эффективность реализации каждого уровня в представленном стеке виртуальных машин, непосредственно влияет на конечную эффективность реализации алгоритмов ФБ. Связь с временными параметрами А-платформы имеет только самый нижний уровень стека, а именно механизмы тактирования. Особенности предлагаемой ОСМВ в том, что описанный стек виртуальных машин принадлежит не к модели, а к А-платформе, на которую данная модель должна быть отображена. ФБ может только косвенно влиять на представленный стек виртуальных машин, а именно путем выбора прикладного языка ими языка высокого уровня, в терминах которого выражен ФБ. Однако замена прикладного языка приводит просто к конфигурированию А-платформы (смене MB). Матрица сложности генерации выходного события ФБ зависит только от алгоритма и средств его выражения. Такая матрица никак не зависят от вычислительной платформы, на которую будет отображен ФБ, и, следовательно, не изменяются при различных отображениях модели на целевые узлы. Может сложиться ситуация, когда один ФБ должен быть отображен на множество целевых узлов системы. Такая ситуация может быть вызвана двумя фактами: При понижении детализации рассмотрения модели, ФБ объединяются, образуя все более крупные структурные элементы. модели. В конце концов, сложится ситуация, когда один ФБ включает в себя задачи, решаемые на разных узлах целевой системы (например, таким блоков может быть сама РИУС в целом). В этом случае нет смысла говорить об отображении ФБ на некоторый конкретный узел целевой системы; В модели системы существуют АФБ, отображенные на несколько узлов целевой системы. При этом эти блоки действительно являются атомарными, то есть не подразумевают дальнейшей [разумной] функциональной декомпозиции.
В отличие от первого случая, который на самом деле имеет место и очень важен при моделировании, второй случай является результатом ошибочного понимания узла целевой системы. АФБ по определению имеет законченную строго определенную функциональность и некоторую реализацию. Невозможно существование АФБ, отображенного не несколько целевых узлов системы по той причине, что помимо конечной функциональности такой блок должен обладать средствами синхронизации. Заблуждения о том, что АФБ, отображенные на множество целевых узлов, существуют, связаны с неадекватным восприятием структуры вычислительной платформы, а именно ее декомпозиции на целевые узлы.
В общем случае границей узла не являются границы корпуса микросхемы или платы в составе системы. Такое "примитивное" восприятие целевого узла верно только для очень простой по функциональности элементной базы А-платформы. В настоящее время элементная база настолько функционально развита и многообразна, что в рамках одного кристалла могут существовать несколько практически независимых целевых узлов. Каждый целевой узел характеризуется независимой системой тактирования, собственной виртуальной машиной, интерфейсами обмена событиями и средствами сохранения событий.
