CC BY
44
ОПИСАНИЕ РЕСУРСОВ ПРИ ВЫСОКОУРОВНЕВОМ ПРОЕКТИРОВАНИИ УПРАВЛЯЮЩИХ СИСТЕМ
И.В. Елькин
Большинство современных управляющих систем реального времени строится на основе микропроцессорной техники. Ее применение позволяет создавать функционально и структурно сложные комплексы. При этом условия рынка диктуют все меньшие сроки, отводимые на разработку, при меньшей стоимости. Таким образом, возникает проблема эффективного проектирования подобных управляющих систем.
Подход, зачастую применяемый в настоящее время, достаточно неформален, особенно на начальной стадии проектирования, когда требования к функциональности системы выражаются на естественном языке. Неформальному описанию свойственна неопределенность, которая не дает возможности проводить анализ системы, что может привести к некорректным или неэффективным решениям. В свете этого большую важность приобретают хорошо формализованные подходы к процессу проектирования систем управления.
В таких подходах выделяется этап высокоуровневого анализа и проектирования (или проектирования на системном уровне - system level design), с которого начинается процесс создания системы. На данном этапе создаются высокоуровневые описания -модели системы. Архитектурная модель (описание) системы высокого уровня позволяет абстрагироваться от деталей реализации системы на ранних этапах разработки и рассматривать систему как единое целое с точки зрения прикладной задачи. Такая архитектура служит фундаментом, на основе которого в дальнейшем осуществляется низкоуровневое проектирование, реализация и совершенствование системы.
Основу высокоуровневого проектирования составляют средства для создания моделей (описаний) системы - языки описания систем. Такие высокоуровневые языки позволяют:
• создавать компактные и удобные для разработчика описания систем (как в графическом, так и текстовом виде) на различных уровнях;
• использовать инструментальные средства для создания, редактирования, анализа и имитационного моделирования (симуляции) описаний;
• обеспечить возможность автоматизированного создания реализации системы (на языке реализации) на основе описаний высокого уровня;
• обеспечить возможность повторного использования проектных решений;
• обеспечить переносимость проектов между различными инструментальными средствами;
Описание закладывает основу для реализации системы и должно быть достаточно абстрактным для того, чтобы получить общее представление сложной системы и отложить принятие решений, связанных с реализацией.
Кроме того, что высокоуровневое описание служит основой для реализации системы, оно также может использоваться для обмена информацией о системе между участниками проектирования в четкой и однозначной форме.
Как уже было отмечено, современные управляющие системы строятся на основе микропроцессорной техники и представляют собой сложные программно-аппаратные комплексы. Соответственно, их разработка включает в себя проектирование как аппаратуры, так и программного обеспечения. Методы высокоуровневого проектирования можно разделить по тому, как осуществляется проектирование этих двух составляющих: 1. традиционное (раздельное) проектирование
• проектирование аппаратного обеспечения
• проектирование программного обеспечения (ПО)
2. совместное проектирование (Codesign) аппаратуры и ПО
Проектирование аппаратного обеспечения. При создании управляющей системы масштаб проектирования аппаратной составляющей может значительно отличаться.
1. Проектирование на готовой вычислительной платформе. В этом подходе в качестве вычислительных узлов используются готовые платформы. Как правило, это промышленные компьютеры или программируемые логические контроллеры (PLC), содержащие типовой набор каналов ввода-вывода и периферии.
2. Проектирование на основе специализированных контроллеров. В данном подходе разрабатываются специализированные вычислительные узлы под конкретное применение на микропроцессорной элементной базе (микропроцессоры, микроконтроллеры).
3. Полномасштабное проектирование аппаратуры. Здесь осуществляется проектирование аппаратуры «с нуля» - создание специализированных микросхем (ASIC), либо программирование микросхем программируемой логики (ПЛИС).
Для проектирования цифровых устройств широко применяются языки описания аппаратуры (xHDL). Они позволяют моделировать структуру и поведение системы и применяются для проектирования устройств на основе ПЛИС, ASIC, систем на печатных платах, тестирования цифровых систем, документирования. Наиболее распространенные языки - VHDL, Verilog.
Проектирование программного обеспечения. Проектирование программной составляющей управляющей системы во многом схоже с проектированием программного обеспечения систем общего назначения. Соответственно для проектирования ПО управляющих систем применяются те же принципы. В частности, широко применяется объектно-ориентированный подход, т.е. система представляется как набор взаимодействующих объектов, каждый из которых отвечает за решение определенной задачи. Такой подход позволяет структурировать решение, повысить устойчивость системы при изменениях и обеспечить повторное использование компонентов системы. Также для архитектуры управляющих приложений свойственна модель управления событиями, т.е. алгоритмы в отдельных компонентах системы запускаются на исполнение по получении событий. Механизм событий позволяет быстро реагировать на изменения, происходящие в системе реального времени. Использование модели конечного автомата (state-machine), когда поведение объекта системы задается автоматом с конечным числом состояний, увеличивает предсказуемость поведения системы, облегчает отладку и позволяет поддерживать высокоскоростные, управляемые событиями алгоритмы, использующиеся в управляющих системах.
При проектировании ПО используются либо специализированные языки описания (SDL и MSC для коммуникационных систем, IEC 61499 для распределенных систем управления), либо языки описания ПО общего назначения, дополненные средствами описания систем реального времени (специализированные профайлы языка моделирования UML для проектирования систем реального времени).
Совместное проектирование программного и аппаратного обеспечения. В последнее время активно разрабатывается новый подход к проектированию управляющих систем - совместное проектирование аппаратного и программного обеспечения (Codesign). Этот подход позволит полностью воплотить идею высокоуровневого (системного) проектирования. В нем проектирование на системном уровне ведется без разделения системы на аппаратную и программную составляющую, т.е. имеет место единый процесс проектирования.
На основе решений, принятых при проектировании на системном уровне, в дальнейшем осуществляется разбиение проекта системы на программную и аппаратную составляющие с последующей реализацией. Важным этапом является верификация и имитационное моделирование (симуляция) проекта системы, которые предназначена
для выявления дефектов проектирования и позволяют проектировщику оценить выбранные проектные решения.
При совместном проектировании применяются самые различные языки описания, те же, что используются при традиционном раздельном.
Проблемы высокоуровневого проектирования. Описанные выше методы проектирования систем, основанные на применении высокоуровневых архитектурных моделей, на ранних этапах позволяют разработчикам абстрагироваться от деталей реализации и сконцентрировать внимание на логических аспектах решаемой задачи. Однако, к сожалению, такой подход в чистом виде оказывается неприменимым при проектировании управляющих систем. В этом случае принятие проектных решений определяется не только требованиями прикладной задачи, но в не меньшей степени нефункциональными требованиями, а также техническими характеристиками и ограничениями вычислительной платформы, на основе которой строится система. К ним относятся:
1. жесткая детерминированность поведения;
2. работа в режиме реального времени;
3. повышенные требования к надежности и безопасности функционирования;
4. использование специализированных аппаратных средств
a. спецпроцессоры и микроконтроллеры
b. специализированные периферийные устройства
c. ограниченные ресурсы (вычислительная мощность, объем памяти);
5. как правило, распределенная архитектура системы.
Отсутствие проработанных механизмов учета технических характеристик системы не позволяет проводить формальный анализ способов реализации на ранних, "системных" этапах проекта. Как представляется, это является одной из основных причин относительно малой распространенности высокоуровневых методов проектирования на основе абстрактных описаний.
Рассмотрим общие принципы учета технических характеристик, которые следует реализовывать в рамках высокоуровневых описаний системы. В частности, сосредоточим внимание на проблеме учета ресурсов системы.
Ограничения, накладываемые техническими характеристиками, могут быть отражены с помощью понятия ресурсов системы [1]. К ресурсам системы относят как аппаратные блоки (процессоры, память, шины, устройства в/в), так и программно реализованные функции (буферы, очереди, нити операционной системы).
Ресурс можно представить как абстракцию, которая предоставляет службы прикладным компонентам системы. Службы определяются своими функциональными и нефункциональными характеристиками. Нефункциональные характеристики называют параметрами качества обслуживания (Quality of Service - QoS) [1] - они, как правило, являются количественными (время ответа, длины очередей, производительность, доступность). Их учет позволит проводить количественный анализ системы.
Методы анализа можно разделить на две категории.
Анализ временных ограничений позволяет определить, сможет ли система реального времени функционировать в рамках установленных крайних сроков (deadlines) -временных ограничений на выполнение операций. Эти методы используются при анализе систем жесткого реального времени, в которых превышение ограничений ведет к катастрофическим последствиям. Для применения такого анализа необходимо иметь точную спецификацию временных параметров и требования по загрузке системы, т.е. анализ возможен лишь для систем со статической периодической нагрузкой.
Анализ производительности основан на использовании теории массового обслуживания для предсказания времени ответа, задержек и требований к ресурсам системы. Такой анализ может использоваться для систем с недерминированной нагрузкой, меняющейся во времени по вероятностным законам. Соответственно, результаты анализа
также вероятностны и не могут давать гарантированное выполнение временных ограничений, что допустимо только для систем мягкого реального времени.
Если ввести понятие ресурса, то можно будет выделить два подхода к моделированию проектируемой управляющей системы с учетом технических характеристик:
1. использование одноранговой модели;
2. использование уровневой модели.
Рассмотрим их подробнее.
Одноранговая модель системы опирается на отношение «клиент-ресурс», в котором прикладная часть системы является клиентом, потребляющим ресурсы системы. Здесь важно, чтобы качество обслуживания, предоставляемое ресурсом, по меньшей мере, соответствовало качеству обслуживания, которое требуется клиенту. Отношения между клиентом и ресурсом, связанные с характеристиками обслуживания, называются QoS-кoнmpaкmoм (рис. 1). Ресурс, в свою очередь, может являться клиентом других ресурсов и иметь требования к качеству обслуживания. В общем случае, ресурс гарантирует качество обслуживания своим клиентам только при условии, что используемые им ресурсы обеспечивают необходимое качество.
Клиент QoS-кoнтpaкт Ресурс
Рис. 1. Отношение «Клиент-Ресурс»
Как видно, в данной интерпретации ресурсы системы представляются в виде компонентов логической модели системы наравне с прикладными компонентами. Таким образом, введение ресурсов в модель не меняет принципиально высокоуровневое описание и позволит моделировать структуру и поведение будущей системы, начиная с ранних этапов проектирования, уже с учетом технических характеристик и ресурсов системы. В частности, возможно выделение специализированных компонентов системы, которые управляют ресурсами - менеджеров ресурсов. Менеджер ресурсов осуществляет инициализацию ресурсов, выделение их по требованию клиентов в соответствии с некоторой стратегией, а также восстановление при сбоях.
Уровневая модель подразумевает четкое разделение системы на два основных уровня:
1. Прикладной уровень - логическая модель системы, которая в абстрактном виде описывает компоненты, решающие прикладную задачу системы.
2. Уровень ресурсов - модель реализации, описывающая конкретную технологию реализации прикладных компонентов системы.
Эти два уровня описывают одну и ту же систему, но с разными целями, что позволяет отделить логику системы от конкретной реализации. В принципе возможно изменение модели реализации без изменения логической модели, т.е. логическая модель адаптируется к изменяющейся аппаратной конфигурации.
Платформа - это модель ресурсов системы, которая предполагает множество вариантов конкретной реализации этой системы [2]. Однако взаимозаменяемые модели реализации должны быть совместимы, а именно должны удовлетворять требованиям качества обслуживания со стороны логической модели. Таким образом, отображение логической модели на модель реализации возможно только при соблюдении QoS-контракта. Другими словами, логическая модель системы, будучи независимой, позволяет учитывать технические характеристики платформы за счет определения требований по качеству обслуживания ресурсов системы. Ресурсы модели реализации не обязательно являются чисто аппаратными компонентами, они могут быть программным обеспечением уровня операционной системы, который, в свою очередь, использует ресурсы уровня аппаратуры.
На поздних этапах проектирования, чтобы отобразить логическое (функциональное) описание системы на конкретную платформу, необходимо установить связи между ресурсами платформы и функциональными компонентами системы. Аппаратные компоненты отображаются непосредственно на аппаратные ресурсы. Программные компоненты реализуются как задачи, использующие службы промежуточного уровня - операционной системы. Таким образом, описание системы можно представить в виде трехуровневой модели (рис. 2).
"Платформа
Рис. 2. Многоуровневая модель системы управления
1. Уровень аппаратуры - уровень аппаратных ресурсов: микропроцессорные архитектуры, программируемая логика, устройства ввода/вывода, память.
2. Уровень операционной системы - уровень программных ресурсов: ресурсы операционной системы реального времени (ОСРВ), драйверы устройств.
3. Прикладной уровень - включает компоненты, реализующие прикладные функции системы.
Оба описанных подхода могут использоваться для моделирования ресурсов системы. Однако в обоих случаях большую роль играет анализ параметров качества обслуживания ресурсов для того, чтобы характеристики предоставляемых ресурсов удовлетворяли требованиям прикладной задачи. Анализ совокупного качества обслуживания всех ресурсов системы является сложной задачей, которая не имеет общего решения по ряду причин.
• Различные характеристики обслуживания комбинируются разными способами. Например, для определения общей надежности системы необходимо знать не только надежность отдельных ее элементов, но и то, как они связаны между собой.
• Ресурсы, как правило, являются разделяемыми, что ведет к сложным взаимозависимостям между компонентами системы.
Определенные методики существуют для конкретных характеристик и применимы только в особых случаях.
Описанные выше принципы моделирования ресурсов системы при высокоуровневом проектировании могут быть положены в основу исследований по разработке конкретных методов и средств учета ресурсов (платформы) в рамках методов высокоуровневого описаний системы (языков описания). Методы учета технических характеристик системы позволят использовать формализованные методы анализа качества проектных решений и применимости тех или иных реализаций уже на ранних этапах проектирования. Разработка и внедрение таких средств является необходимым для эффективного использования методов высокоуровневого проектирования.
Литература
1. B.Selic, A Generic Framework for Modeling Resources with UML. // IEEE Computer, June 2000, pp.64-9.
A. Sangiovanni-Vincentelli, Defining Platform-based Design. // EEDesign, February 2002.
2. Rong Chen et al, Embedded System Design Using UML and Platforms. University of California, Berkeley, 2001.
Управляющее приложение
Драйверы Коммуникационная подсистема ОСРВ
Микропроцессоры Память Устройства ввода/вывода Шины
