Microsoft Word впвс book 2011 sev pa doc

1.2.2.1 Платформно-ориентированное проектирование 
В концепции платформно-ориентированного системного проектирования 
основным понятием является понятие платформы. Авторы выделяют 
аппаратную и программную платформу, они присутствуют в каждом проекте, и 
их объединение составляет системную платформу. 
Аппаратная платформа – это множество архитектур вычислительных 
машин, позволяющее решать поставленную задачу. При проектировании 
ограничения 
архитектуры 
обычно 
определяются 
в 
терминах 
производительности и размеров. Как правило, в аппаратной платформе больше 
возможностей, чем требуется от проектируемой системы. Нет смысла 
использовать аппаратуру, пригодную для решения единственной задачи. 
Программная платформа – абстрактный уровень взаимодействия 
программы с аппаратурой. Основная идея – это разработка платформно-
независимого API. То есть между программой и аппаратурой вставляется 
программный слой, унифицирующий работу программы с некоторым набором 
аппаратуры. К программной платформе относят: 
• операционную систему (обычно ОСРВ), распределяющую аппаратный 
ресурс; 
• драйверы устройств, обеспечивающие подсистему ввода/вывода; 

---

38 
• сетевую подсистему, обеспечивающую взаимодействие компонентов 
вычислительной системы. 
Примерами программных платформ являются продукты фирм ISI, 
WindRiver, Microsoft (Windows CE), QSSL (QNX), POSIX [49]. 
Стратегия платформно-ориентированного системного проектирования 
представлена на рис. 1.8. 
Системная платформа, как уже говорилось, объединяет аппаратную и 
программную платформы. В начале проектирования обе платформы являются 
абстракциями. Причем чем выше эта абстракция, тем лучше, тем больше 
свободы в выборе решений по конкретизации системы. Нежелательно 
преждевременное разделение функций между аппаратурой и программой. 
Проектируемая система с добавлением ограничений (быстродействие, 
габариты, надежность, потребление энергии, доступное API, наиболее 
подходящая ОСРВ и т.п.) уточняется (актуализируется) и вариантов ее 
реализации остается все меньше и меньше. В итоге получается единственное 
решение: однозначный выбор аппаратуры и определенная программистская 
модель. 
Рис. 1.8. Процесс платформно-ориентированного проектирования 
Среди примеров применения своей методики авторами указываются как 
разработки сторонних фирм, так и результаты собственного проекта MESCAL. 
В первом случае рассмотрены система передачи видеоинформации (Philips), 
контроллер управления двигателем (Magneti-Marelli) и беспроводная сеть 
(Berkley Wireless Research Center). В каждом из примеров приводится 
архитектура системы, этапы выбора программной платформы, объем кода 
(строки кода) и т.п. Проект MESCAL (Modern Embedded Systems, Compilers, 
Architectures and Languages) реализуется для определения эффективности 
использования методики платформно-ориентированного проектирования. По 

---

39 
результатам анализа проектов складывается ощущение, что в данном 
исследовании чрезмерное влияние уделяется программной платформе. 
Наиболее мощным и комплексным инструментальным средством PBD на 
сегодня видится Metropolis Framework (Center for electronic system design, 
University of California at Berkeley), объединяющий методологию PBD, 
встроенный механизм представления моделей системы (Metropolis Meta Model, 
MMM), инструментальные средства разработки и отладки проектов [79]. 
Metropolis Framework поддерживает модели: функциональные, которые 
применяются в том числе и на (под)уровне миссии, архитектурные, 
относящиеся к (под)уровню (макро)архитектуры и исполняемые TLM-модели 
(Transaction Level Modelling на базе языка SystemC), покрывающие уровень 
микроархитектуры с выходом на генерацию программной или аппаратной 
реализации компонентов архитектуры. Предусмотрен механизм поддержки 
нефункциональных требований в виде специальных объектов «quantity 
manager», управляющих ресурсами, ассоциированными с процессами. 
Metropolis Framework имеет достаточно длительную историю: она базируется 
на системе Polis, созданной в 1990 году и ориентированной на специфику 
автомобилестроения, и как было декларировано, предполагается к развитию в 
рамках проекта METRO II [40] (однако следует заметить, что начиная с января 
2008 года сведения о развитии проекта Metropolis отсутствуют). 
Другим известным в разряде PBD проектом того же университета является 
система Ptolemy II. Ptolemy II ориентирован не на разработку конечных систем, 
но на исследование различных моделей вычисления, которые должны быть 
положены в основу архитектуры встраиваемых систем различного рода. 
Инструмент открытый, предлагает большую библиотеку готовых моделей и 
архитектурных компонентов, но также предоставляет возможность добавлять 
собственные. Таким образом, Ptolemy II – это инструмент исследований, но не 
проектирования. 
Из коммерческих инструментальных средств наиболее известно 
MLDesigner (Mission Level Designer, www.mldesigner.com). MLDesigner в 
большей степени поддерживает этапы (под)уровней миссии и архитектуры, 
имеет средства контроля нефункциональных требований (в терминологии 
MLDesigner – ресурсы), однако явно прослеживается ориентация пакета на 
разработку встроенного программного обеспечения, нет развитых средств 
программно/аппаратного деления и реализации компонентов архитектуры.