CC BY
58
ЕДИНОЕ ПРОЕКТНОЕ ПРОСТРАНСТВО ПЛЮС АСПЕКТНАЯ ТЕХНОЛОГИЯ - ПЕРСПЕКТИВНАЯ ПАРАДИГМА ПРОЕКТИРОВАНИЯ ВСТРАИВАЕМЫХ СИСТЕМ
А.Е. Платунов, Н.П. Постников
Анализируются проблемы проектирования встроенных вычислительных систем. Отмечается необходимость радикального изменения концепции проектирования. Вводится понятие единого проектного пространства встроенных систем. Рассматриваются основные положения аспектной технологии сквозного проектирования таких систем на основе понятия архитектурных агрегатов. Обсуждаются основополагающие термины архитектурной модели встроенной системы. Поясняются уровни А-модели встроенной системы - абстрактный, виртуальный, реализуемый.
Введение
Рост потребности в информационно-управляющих системах (ИУС) различного назначения на современном этапе заставляет разработчиков вычислительной техники активно совершенствовать способы и средства проектирования. Значительную долю ИУС составляют встроенные системы (embedded systems), которые можно определить как специализированные (заказные) вычислительные системы (ВС), непосредственно взаимодействующие с объектом контроля или управления. Проектирование встроенных систем характеризуется высокой сложностью [1, 2]. В значительной мере это определяется специфическими требованиями технического задания и, как следствие, необходимостью применения нетиповых для иных ВС технических решений.
Процесс проектирования встроенных систем относится к разряду комплексных научно-технических задач. Проблема заключается в существовании огромного количества потенциально пригодных вариантов реализации, порождаемых по одному техническому заданию. Эти варианты могут отличаться друг от друга коренным образом. Предварительная оценка вариантов реализации затруднена.
В статье анализируются проблемы проектирования встроенных вычислительных систем. Отмечается необходимость радикального изменения концепции проектирования [3]. Вводится понятие единого проектного пространства встроенных систем. Рассматриваются основные положения аспектной технологии сквозного проектирования таких систем на основе понятия архитектурных агрегатов. Обсуждаются основополагающие понятия архитектурной модели встроенной системы.
Проблемы проектирования встроенных вычислительных систем
Сложившаяся практика проектирования вычислительных систем состоит в выборе одной из канонических вычислительных платформ (ВП), на которой за счет программной надстройки решается прикладная задача. Задача делится на две части: выбирается база (платформа), база достраивается вверх (за счет программирования в широком смысле) до получения требуемой ВС. Для такого способа проектирования существуют технологические приемы и инструментальные средства. Примерами являются языки программирования, на которых описывается конечная задача, исполнительные устройства (готовые вычислительные машины) и трансляторы.
Применяется и второй вариант: выбирается ВП и наряду с достройкой вверх выполняется модификация вниз. В этом случае базовая платформа выступает и в роли прототипа. Такой способ используется реже из-за высокой трудоемкости.
Первая проблема, с которой сталкиваются разработчики ВС, состоит в следующем:
- существующие языки программирования предполагают описание задачи для идеализированной виртуальной (языковой) машины;
- транслятор отображает эту языковую машину на реальную машину, внося определенные ограничения и не учитывая многих важных технических особенностей исполнительской машины (например, особенностей системы ввода-вывода, защитных механизмов и др.);
- чтобы учесть эти ограничения и особенности, программисту необходимо помимо знаний о языковой машине иметь знания о трансляторе и об исполнительской машине.
На сегодня отсутствует единая система описания этих трех составляющих, они описываются в различных предметных пространствах и языковых стилях.
Вторая проблема - большое число задач, особенно в области систем управления физическими объектами, которые плохо укладываются в схему реализации на основе канонических ВП с языковой программно-реализуемой надстройкой. При таком подходе либо решения оказываются экономически неоптимальными, либо задача вообще не решается в рамках современных технических средств. Необходимо проектировать специализированные ВП, например, с высокой степенью параллелизма и специализацией операционных блоков. Попытка проектировать целевую ВС на такой архитектурной основе по описанной выше массовой традиционной технологии катастрофическим образом обостряет проблему нестыковки специфических требований языковой машины, трансляторов и ВП. Если для определенного класса задач традиционная схема проектирования приемлема, то для специализированных систем эффективность проектирования может сводиться к нулю (огромные проблемы с параллелизмом, с защитными механизмами, с ограничением реального времени, с тестированием и отладкой и т.д.).
Третья проблема связана с постоянно растущим объемом необходимого проектирования ВС. Разобщенность описаний, отмеченная выше, препятствует повторному использованию разработанных компонентов (аппаратных блоков, программ, реализаций алгоритмов и т.д.). Магистральным направлением в повышении эффективности проектирования, как отмечают ведущие специалисты, является закрепление результатов разработок в виде абстрактных технических решений, инвариантных к способу реализации [4, 5]. Переходу в проектировании ВС на такой уровень препятствует отсутствие соответствующей языковой базы и инструментальных средств.
Единое проектное пространство встроенных систем
Решение указанных проблем возможно через создание единого пространства проектирования ВС в терминах вычислительных абстракций (вычислительных механизмов, функциональных преобразователей, виртуальных машин, архитектурных агрегатов [6]) и, соответственно, новой парадигмы проектирования. Критериями создания такого пространства должны являться:
1. унификация традиционных трактовок hardware и software;
2. рассмотрение всех этапов проектирования ВС как эквивалента программирования;
3. представление проектируемой ВС в рамках возможно большего количества шагов проектирования (от начала) "в чисто вычислительном базисе" (в терминах вычислительных абстракций);
4. поиск решений по организации ВС в объединенном пространстве "фаза проектирования - фаза исполнения (эксплуатации)";
5. использование "аспектной технологии", которая позволяет явно проследить трансформации ключевых составляющих ВС по ходу проектирования (функциональность, инструментальный, надежностный аспект и т.д.) и учесть в процессе проектирования дополнительные факторы. Речь идет о факторах, которые
явно (или вообще) не присутствуют в ТЗ, но серьезно влияют на результаты проектирования (инструментальный аспект, возможности коллектива, доступные технологии, учет задела и интересов коллектива и др.).
Важным является тезис "платформно-ориентированного" проектирования, который формирует гибкий взгляд на понятие ВП как обобщенной виртуальной машины, зафиксированной для создания очередной функциональной надстройки.
Необходимо использование принципа реконфигурируемости архитектуры в широком (и "разумно усложняющем жизнь разработчику") смысле. Критерий реконфигурируемости в архитектуре ВС - способность к изменению вычислительной модели.
Указанные пути решения опираются на расширенную трактовку понятия "элементная база", куда входят объекты всех уровней абстракции, принадлежащие различным составляющим аспектной технологии проектирования [7].
Основы аспектной технологии проектирования встроенных систем
Центральным понятием процесса проектирования ВС является архитектура ВС -совокупность структурных и функциональных элементов ВС некоторого уровня детализации, адекватно отображающая проектируемую систему для данного уровня рассмотрения.
В аспектной технологии будем говорить о двух объектах верхнего уровня, с которыми имеет дело разработчик: архитектура проекта (framework) и архитектура продукта (проектируемой ВС). Эти архитектурные представления содержат в себе все составляющие соответственно процесса проектирования и создаваемого продукта. Такие составляющие будем именовать аспектами проектирования (или просто аспектами).
Начиная с некоторого уровня интегральной сложности проектируемой системы, все более заметной становится потребность описания такой системы в терминах технических решений и логики их взаимодействия. При этом в различных частях системы абстрактность или уровень проработки того или иного решения могут значительно различаться. Такая потребность является объективной, так как для сложной системы нет возможности оперировать относительно конкретными понятиями. В этом случае из-за очень большой детализации отдельных частей системы возникают заметные проблемы восприятия системы целиком, что приводит к фрагментарному восприятию проекта разработчиками, и в лучшем случае в результате получается далеко не оптимальная реализация, а зачастую система оказывается просто неработоспособной.
Разработчики оказываются перед сложной дилеммой: с одной стороны, необходимо уменьшать уровень детализации представления системы на верхних уровнях, с другой стороны, это может привести к потере важных характеристик (например, габариты или энергопотребление). Таким образом, понижая уровень детализации представления системы, разработчик должен по-прежнему контролировать все ее аспекты.
Еще одной объективной сложностью проектирования современных встроенных систем является значительная разнородность аспектов, которые следует учесть. Например, для таких аспектов, как габариты, энергопотребление и объем памяти (для микросхем памяти) достаточно сложно вывести единую зависимость, сводящую эти характеристики к "универсальным" единицам измерения. Разработчик может проводить поиск подходящего устройства среди доступных на рынке в настоящий момент, и очевидно, что с течением времени и развитием технологий в пространстве
[габарит] х [энергопотребление] х [объем] множество точек, представляющих собой допустимую комбинацию, заметно перемещается.
Также важным моментом при проектировании сложных встроенных систем является возможность их масштабирования или повторного использования в том или ином виде. При огромной скорости смены элементной базы и лавинообразном росте доступных ресурсов нерационально разрабатывать систему, опираясь на тот или иной микроконтроллер (или даже семейство микроконтроллеров), микросхему программируемой логики и интерфейс передачи данных. Во многих случаях использование той или иной элементной базы требуется в техническом задании (ТЗ) на разрабатываемую систему, но даже в этом случае использование конкретного элемента должно быть всего лишь ограничением, но ни в коем случае не базой при разработке системы.
Основным подходом в проектировании системы становится построение сложной, разноплановой, полнофункциональной модели системы с учетом заранее определенных ограничений и последующим отображением модели на ту или иную элементную базу.
Разноплановое, охватывающее многие (все) аспекты системы представление будем называть архитектурным представлением системы. Отдельные элементы такого представления будем называть агрегатами, так как они объединяют совершенно разнотипные аспекты представления системы. Таким образом, архитектурный агрегат (АА) представляет собой базовый элемент процесса проектирования системы. АА могут иметь различную степень абстракции, представлять собой технические решения или конкретные вычислительные узлы, определять разное количество аспектов для описываемого элемента. Модель системы, выраженную в терминах АА, будем называть А-моделъю системы.
Конкретный перечень аспектов формируется разработчиком с учетом условий проектирования. Условия определяются как техническим заданием (прямо и/или косвенно), так и стилем, возможностями и общими целями самого коллектива разработчиков. Суммируя опыт работы ряда коллективов в области создания ВС, наиболее часто выделяются следующие аспекты (список аспектов - открытый, но в каждом случае конечный):
• функциональный (в том числе решение проблем реального времени);
• надежностный;
• конструкторско - технологический;
• энергетический;
• климатический;
• инструментальный;
• повторного использования;
• организационно-экономический (стратегии проекта, попутные задачи: освоить ..., повысить квалификацию, стоимостной срез, временной срез, характеристика и производные от особенностей объекта - доступ, территориальное расположение, жизненный цикл);
• документный.
В представленном списке каждый из аспектов характеризуется:
• примитивами соответствующего множества;
• внутренней в рамках аспекта логикой работы модели;
• внешней логикой взаимодействия с другими аспектами.
Как следует из определений АА и А-модели, непосредственная работа с ней крайне затруднена. Разноплановость аспектов не позволяет построить развитую логику взаимодействия непосредственно между АА как атомарными сущностями. Логика взаимодействия АА вырождается до уровней иерархического включения/подчинения и
частного взаимодействия друг с другом, но уже на аспектном уровне. Если в А-модели между АА существует взаимодействие, то, по сути, оно начинает проявляться между определенными (одноименными) аспектами этих АА. Перечень аспектов, в которых проявляется отношение между АА, назовем спектром этого отношения. Кроме разноплановости аспектов в составе АА, различные АА в составе модели могут содержать одни аспекты и не определять другие, что также не позволяет создать сложные правила взаимодействия между АА.
АА, описывающий не все аспекты в рамках текущей А-модели, называется абстрактным архитектурным агрегатом. При создании и использовании такого агрегата разработчик абстрагируется от тех или иных характеристик системы, которые для него не важны (произвольны) или будут доопределены в последствии. Нетрудно заметить, что большинство технических решений, протоколов, интерфейсов, стандартов и являются такими абстрактными АА, из которых разработчик по факту создает систему. В противоположность абстрактному АА, у которого существует хотя бы один из неопределенных аспектов, полным назовем АА, у которого определены все аспекты.
А-модель системы позволяет разработчику отслеживать развитие различных аспектов проектируемой системы, учитывать эмпирическое влияние аспектов друг на друга, контролировать развитие системы в целом. В каждый конкретный момент разработчик может выбрать "ведущий" аспект, который будет определять дальнейшее развитие проектируемой системы.
Собственно развитие системы происходит на уровне рассмотрения отдельных аспектов. Для этого вся А-модель системы проецируется в определенное аспектное пространство. При этом для всех АА модели происходит абстрагирование от аспектов, кроме интересующего., и уничтожаются все отношения, в спектр которых не входит интересующий аспект. Получившуюся модель, описывающую текущее состояние отдельного аспекта системы, будем называть аспектной моделью системы.
Перечисленные выше аспекты представляют собой самостоятельные предметные области, так что получившаяся модель обладает важным свойством -самодостаточностью. Это значит, что разработчик имеет возможность провести полное проектирование системы, опираясь только на внутренние закономерности развития и метрики аспектной модели. Различные аспектные модели могут быть выражены различными средствами (чертежи, схемы, алгоритмы, временные диаграммы и т.д.), и даже одна и та же аспектная модель может быть выражена по-разному для разных проектов или групп разработчиков. При этом для многих аспектных моделей в настоящее время существует множество формальных и полуформальных способов описания и анализа (например, для функциональной модели можно перечислить автоматные модели, диаграммы потоков данных, диаграммы сообщений и т.д.). Для аспектных моделей можно вводить метрики и специальные характеристические функции. Их задача - дать формальную оценку модели, установить ее непротиворечивость, убедиться, что характеристики модели не выходят за внешние ограничения и удовлетворяют требованиям, накладываемым на данный аспект системы. Ввиду независимости (ортогональности) аспектов и аспектных моделей, их характеристические функции также будут ортогональны и непосредственно не будут зависеть от развития других аспектных моделей.
Полностью независимое развитие аспектов в конечном итоге невозможно, так как каждый из них - это всего лишь частный взгляд на систему в целом. Например, желание уменьшить время работы определенного алгоритма потребует повышения тактовой частоты процессора, что в свою очередь приведет к повышению энергопотребления и, в итоге, возрастанию габаритов, которые могут быть жестко ограничены в ТЗ. Выходом в такой ситуации может стать использование другого
алгоритма или вычислителя, что на первый взгляд значительно сложнее, но позволяет решить задачу.
Определяющим фактором в процессе развития А-модели, как было показано выше, становятся взаимные связи между аспектами, которые не входят в саму модель, а являются внешними факторами. Кажется, что можно было бы создать оптимальные решения в каждой аснекгной модели и получить идеальную систему. Однако это невозможно в силу ограничений, накладываемых элементной базой. Суть этих ограничений такова, что не каждый АА, являющийся объединением аспектных характеристик, может быть реализован в элементной базе, доступной разработчику.
Недоступность элементной базы может быть вызвана совершенно разными причинами: ограничениями производства печатных плат, недоступностью определенных микросхем на рынках, подготовленностью и размером коллектива, неразвитостью технологий в мировом масштабе. Другими словами, можно спроектировать идеальную систему (модель), которая в настоящий момент не может быть реализована силами коллектива. Это вовсе не означает, что эта же модель не может быть в то же самое время реализована никаким другим коллективом или что этот же коллектив не сможет реализовать ее через некоторое время, когда изменятся внешние для модели системы, но внутренние для коллектива факторы.
Таким образом, мы приходим к важнейшему свойству А-модели - ее реализуемости. Разрабатываемая встроенная система не является математической абстракцией, она должна быть реализована в определенной элементной базе и обладать определенной функциональностью. При этом зачастую не столь важно, каким образом система была спроектирована. В нашем случае модель системы, которую мы называем А-модель, состоит из архитектурных агрегатов. При этом при определении АА нигде не выдвигалось требования его реализуемости. На самом деле это требование вредно, так как автоматически привязало бы разработчика к определенной, зачастую неоправданно выбранной, элементной базе (см. выше).
Назовем полный АА, который не может быть в настоящее время реализован конкретным коллективом в доступной ему элементной базе, виртуальным. Нужно сказать, что виртуальность АА может определяться не только объективной ограниченностью элементной базы, но и субъективными ограничениями, такими как требования ТЗ, пристрастия и интересы коллектива. Большинство АА в процессе проектирования являются не только виртуальными, но зачастую даже абстрактными. О реализации модели, в состав которой входят абстрактные АА, вообще не может быть и речи, поэтому виртуальным АА имеет смысл называть только полный АА.
Рассматривая А-модель системы с точки зрения образующих ее АА можно выделить 3 типа моделей.
Абстрактная А-модель. В такой модели существует хотя бы один абстрактный АА. Модель принципиально нереализуема и требует дальнейшей доработки, если это модель конкретной целевой системы. Но у таких моделей есть свой способ применения, а именно: такие модели следует рассматривать как платформы для построения конкретных систем.
Абстрактными А-моделями, перешедшими в разряд общепринятых платформ, можно считать стандартные интерфейсы (USART, I2C), шины (PC 104, PCI, USB), протоколы (CANopen, TCP/IP), вычислительные ядра (MCS51, x86, PowerPC, JAVA), операционные системы (QNX, MS Windows) и т.д. При этом перечисленные модели описывают различные перечни аспектов, что не мешает им быть общепризнанными стандартами. Некоторые абстрактные А-модели также можно использовать в качестве повторно используемой платформы в рамках коллектива. Конкретный коллектив может зафиксировать определенное удачное решение, обозначить направление разработок, обеспечить преемственность и т.д., определив абстрактную А-модель системы и
развивая ее в тех или иных конкретных приложениях. Особенно такие модели и локальные (внутри коллектива) повторно используемые платформы интересны с хорошо проработанным инструментальным аспектом, так как именно инструментарий требует повышения коэффициента повторного использования и адаптации под конкретные проекты.
Виртуальная A-модель. В такой модели нет абстрактных АА, но существует хотя бы один виртуальный АА. Такая модель не может быть реализована из-за виртуальных АА, но она уже полностью определена и в принципе может быть реализована, если расширить доступную элементную базу. В принципе такие модели могут быть использованы и как абстрактные, но в большинстве случаев требуется доводить такие модели до реализации. Для этого нужно избавиться от виртуальных АА. Этого добиваются двумя способами: изменением модели или изменением внешних факторов. В первом случае разработчики изменяют модель (проводят процесс проектирования) до тех пор, пока виртуальных АА в ее составе не останется. Во втором случае модель остается неизменной, а меняются внешние факторы. Например, происходит уточнение ТЗ в сторону изменения ограничений; обучение коллектива; переход на другие вычислительные ядра; использование новых для коллектива технологий (например, использование микросхем программируемой логики, смена языка программирования, поверхностных монтаж и многослойные печатные платы).
Реализуемая A-модель. В данной модели нет ни одного абстрактного или виртуального АА. Такая модель может быть реализована коллективом в доступной ему элементной базе.
Заключение
Исследования в данном направлении проводятся в лаборатории микропроцессорной техники кафедры вычислительной техники СПбГУ ИТМО в рамках НИР по созданию распределенных информационно-управляющих систем при поддержке научно-производственной фирмы "ЛМТ". Создан ряд инструментальных методик для разработки сложных встроенных систем. На практике проверены основные положения предлагаемого подхода и отмечен серьезный положительный эффект [8, 9].
Однако следует отметить, что аспектная технология находится в начале своего становления. Необходимы активные исследования в части формализации данного подхода с дальнейшим развитием САПР соответствующего профиля.
Литература
1. Hardware-Software Codesign. // ШЕЕ Design & Test of Computers, January-March 2000. P. 92-99.
2. Вирт H. Аппаратная компиляция // Открытые системы. 1998. № 4-5. С. 7-12.
3. Multilanguage specification for system design and codesign. A.A. Jerraya, M. Romdliani, PH.LE Marrec, F. Hessel, P. Coste, С. Valderrama, G.F. Marchioro, J.M. Daveau, N.E. Zergainoh.
http://tima-cmp.imag.fr/Homepages/cosmos/documents/asi.ps.
4. System Level Design: Orthogonalization of Concerns and Platform-Based Design. / K. Keutzer, S. Malik, R. Newton, J.Rabaey, A. Sangiovanni-Vincentelli // IEEE Transactions on Computer-Aided Design of Circuits and Systems. 2000. Vol. 19. No. 12.
1. Formal Models for Embedded System Design. M. Sgroi, L. Lavagno, A. Sangiovanni-Vincentelli. // IEEE Design & Test of Computers. April-June 2000. P. 2-15.
6. Архитектурные абстракции в технологии проектирования встроенных вычислительных систем / Платунов А.Е. // Научно-технический вестник СПб ГИТМО(ТУ). Выпуск 6. "Информационные, вычислительные и управляющие системы". СПб.: СПб ГИТМО(ТУ), 2002. С. 76-83.
7. Проектирование встроенных вычислительных систем / А.Е. Платунов // Изв. Вузов. Приборостроение. 2003. Т46. №2. С. 5-13.
8. Комплекс технических средств для систем железнодорожной автоматики / Гавриков В.О., Платунов А.Е., Никифоров Н.Л. // Автоматика, телемеханика и связь. 1998. №11. С. 5-10.
9. Проектирование смешанных систем на микроконтроллерах и элементах реконфигурируемой аппаратуры / А. Платунов, А. Чистяков // Электронные компоненты. 2002. №8. С. 83-84, 87-89.
