CC BY
574
РАЗРАБОТКА ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ КАК АКТУАЛИЗАЦИЯ ЦЕЛЕВОЙ ЗАДАЧИ
Р.Р. Ковязин
Потребность в проектировании информационно-управляющих систем (ИУС) продолжает активно расти. При этом процессы проектирования по-прежнему требуют совершенствования. Методики разработки программной и аппаратной компонент ИУС развиваются в разных направлениях, что не позволяет устранить противоречия между рабочими группами и вредит конечному результату - созданию системы. В статье предлагаются механизм и средства описания ИУС, объединяющие в себе фазы Design-Time и RunTime и оперирующие составными частями ИУС инвариантно к их реализации.
Введение
Информационно-управляющие системы (ИУС) являются важнейшим элементом любой современной системы автоматики. Область их применения распространяется на медицинскую и бытовую технику, телекоммуникации, транспортные и аэрокосмические системы и др. Такие отрасли, как энергетика, металлургия, теплоснабжение, не могут обойтись без средств автоматизации. Существующие системы автоматизации основываются на аналоговой и цифровой технике, релейно-контактных схемах, механических агрегатах. На текущий момент интенсивно развивающийся вид ИУС - это системы с программным управлением. Многие управляющие системы и системы автоматизации, организованные по другим принципам, модернизируются в системы с программным управлением. Примерами таких систем являются системы промышленной и железнодорожной автоматики, системы энергоснабжения, измерительные приборы и др.
За последнее десятилетие многократно увеличилась вычислительная мощность электронных компонент, используемых в вычислительных системах, в том числе в ИУС. Это позволяет современным ИУС иметь сложную организацию, использовать операционные системы реального времени, объединяться в контроллерные сети (Embedded Net), применять современные высокоскоростные проводные и беспроводные технологии связи. Но все это не отменяет трудностей реализации характерных особенностей ИУС, потому что появление новых электронных компонент позволяет ставить перед ИУС новые, более сложные задачи. Повышение вычислительной мощности устройств реализации программного управления привело к тому, что на рынке стали востребованы ИУС со сложной функциональностью.
Вместе с прогрессом электронных компонент появились новые методики разработки компонент ИУС. То, что раньше было неприемлемо из-за сложности или неэффективности реализации, сейчас уже общепринято и широко распространено. Увеличение сложности ИУС привело к тому, что повысилась требуемая квалификация разработчиков компонент ИУС. Следствием этого стала более узкая специализация разработчиков, что разделило их на два «лагеря» и стало мешать эффективному созданию ИУС. Методики проектирования каждой из компонент ИУС ограничены и содержат мало или вообще не содержат рекомендаций по организации их совместной работы для реализации программного управления системы. Критерии качества компонент не соответствуют критериям качества системы в целом. В чем-то методики проектирования компонент даже противоречат друг другу, так что успешное проектирование системы есть компромисс между ее компонентами. К этому следует добавить, что методики разработки ИУС не поспевают за темпами роста вычислительной мощности электронных компонент и требованиями рынка.
Некоторые исследователи проблем проектирования ИУС, несмотря на очевидный прогресс в области их разработки, отмечают, что этот прогресс неправильный, это тупиковый путь [1, 2]. В данной работе представлены основные положения модели актуализации. Целью ее создания было получение описания ИУС, объединяющего в себе
фазы Design-Time и Run-Time, программную и аппаратную компоненты. Модель ориентирована на ИУС с доминирующей программной компонентой (Software-Based Embedded Systems).
Процесс актуализации
Первый документ, определяющий целевую задачу любой ИУС - это техническое задание (ТЗ). Для ИУС постановщиком ТЗ является прикладной специалист. ТЗ на разработку вычислительных систем всегда является неполным, поэтому в их разработке присутствует этап проектирования. ТЗ содержит информацию о том, «что» должна выполнять система (часто неформально) и «как» она должна это делать. Неполнота ТЗ заключается в том, что даются не все указания «как», а указания «что» допускают двоякую трактовку и реализацию. Потенциально разработчики свободны в способе реализации ИУС, лишь бы она выполняла требуемые от нее функции. Указания «как» являются ограничением этой свободы: элементная база, минимальная производительность, инструментальные средства, энергопотребление, стоимость, надежность и др. Задача этапа проектирования состоит в добавлении недостающих указаний «как» и в выборе конкретных «что».
ТЗ, дополненное всеми недостающими указаниями, назовем целевым алгоритмом (ЦА). Дополнить ТЗ можно по-разному, поэтому ЦА, реализующих ТЗ, может быть несколько. Задача разработчиков ИУС заключается в реализации конкретного ЦА вычислительными средствами ИУС. В научной фантастике человек может общаться с вычислительной машиной. К сожалению, вычислительные машины не понимают человеческого языка, хотя ведутся исследования в этом направлении. Пока что для реализации ЦА требуется применение промежуточных языков. В процессе передачи «желания» человека машине ЦА претерпевает ряд преобразований из одного языка в другой, часть из которых выполняют разработчики ИУС, а часть выполняется автоматизиро-ванно инструментальными средствами и самой ИУС. Очевидно, что этот процесс не является полностью автоматизированным, поскольку инструментальные машины, с помощью которых выполняются преобразования ЦА, тоже не понимают человеческого языка. Реализация ЦА заключается в выполнении функций ТЗ с учетом его ограничений. Весь процесс преобразований «запускается» не для создания ИУС, не для создания программы, а для того, что хочет получить человек. ЦА претерпевает множество изменений, пока не преобразуется в требуемые физические сигналы: свет, движение, электричество и др. Назовем процесс преобразования ЦА в «желаемое» человеком процессом актуализации.
В качестве модели процесса актуализации ЦА будем использовать ориентированный граф (граф актуализации). Процесс состоит из разветвленной системы преобразований информации, начинающейся с ЦА и заканчивающейся конечными физическими сигналами. Вершинами графа являются трансляторы, преобразующие информацию из одной формы представления в другую. Дуги графа - это формы представления ЦА. Таким образом, последовательность трансляторов, соединенных дугами, задает последовательность преобразований ЦА. Поскольку действия разработчиков ИУС не являются формальными, мы их исключим из графа актуализации. Исходным представлением информации будем считать целевую программу (ЦП) - ЦА, записанный на каком-нибудь языке (программирования), для которого есть инструментальные средства. Сузив граф актуализации, мы оставили в нем лишь автоматические трансляторы, что позволит рассмотреть его формально и получить численные характеристики. На рис. 1 представлен пример типичного графа актуализации для ИУС с программным управлением.
Компилятор Микрок
[искретный Шаговый выход двигатель
о—-
Движение
отопления
Световая индикация
Вкл./выкл.
Релейный
выключатель
Рис. 1. Пример графа актуализации
Граф актуализации можно использовать для решения двух задач.
• Создание графа актуализации и ИУС по нему. Это является одним из способов проектирования ИУС.
• Создание графа по существующей ИУС. На основе графа можно получить характеристики для повторного использования трансляторов, модернизации и рефакторин-
Предлагаемая модель не является одной из моделей жизненного цикла вычислительных систем [3]. Они моделируют этапы существования систем, а процесс актуализации соответствует всему процессу преобразования информации и является статическим. Трансляторы, участвующие в этом процессе, могут показаться принципиально разными, но это обусловлено несовершенством вычислительных возможностей современной элементной базы.
Понятие транслятор базируется на ТБМ-модели [4]. У транслятора есть входные и выходные потоки: по входным он получает команды (сигналы), а по выходным генерирует реакции на команды. Транслятор будем называть программируемым, если он поддерживает входные сигналы, приводящие к появлению выходных сигналов (реакций). Транслятор будем называть конфигурируемым, если он поддерживает входные сигналы, приводящие к смене реакций на программирующие команды. Потоки, по которым передаются команды, приводящие к реакциям или к сменам реакций, будем называть программирующими (программами) и конфигурирующими (конфигурациями). Любой поток состоит из команд одного типа. На графе актуализации программы будем обозначать сплошными дугами, а конфигурации - пунктирными. Трансляторы будем обозначать кругами. Для актуализации ЦП ИУС некоторым трансляторам даются программирующие команды, чтобы они выполнили действия. Некоторые из этих трансляторов не способны самостоятельно актуализировать полученные команды. Они разбивают команды на части и передают их для актуализации другим трансляторам. Так команды передаются от транслятора к транслятору до тех пор, пока не дойдут до тех трансляторов, которые могут сами актуализировать полученные команды. Их суммарные реакции как раз и составляют действия ИУС, которые она должна выполнять в соответствие с ЦП. Потоки являются формами представления частей ЦП, а трансляторы -объектами, преобразующими эти формы представления, разделяющими и соединяющими их части. Трансляторы преобразуют программы и конфигурации в новые программы и конфигурации.
Если один транслятор программируется или конфигурируется другим транслятором, то он является его ресурсом. Отношение между трансляторами можно определять не через необходимость актуализации их команд. Допустим, есть транслятор А с ресурсом Б, и
га ИУС.
Трансляторы и потоки
нужно получить реакцию ресурса. Непосредственно программировать ресурс Б невозможно, потому что к нему нет доступа. Но его можно программировать через транслятор А. Даже если известны языки входных потоков ресурса Б, ему можно давать не любые команды, а только те, которые для него генерирует транслятор А, обрабатывая собственные входные команды. Аналогичным образом можно передавать команды через цепочку трансляторов. Все трансляторы, к которым можно получить доступ через команды транслятора, являются его непосредственными или опосредованными ресурсами.
Часто ИУС получают информацию из своего окружения - температура воздуха, напряжение во входных электрических цепях, действия оператора и др. С одной стороны, эти сигналы можно разделить на программирующие и конфигурирующие. С другой стороны, потоки, по которым передаются эти сигналы, не являются формой представления ЦП. Получается, что у некоторых трансляторов не все входные потоки являются формой представления ЦП. Назовем такие трансляторы смешанными, а такие потоки внешними. Транслятор, у которого присутствуют только внешние потоки, назовем 0-транслятором. Не следует путать, например, кнопку или датчик с 0-транслятором. В графе 0-транслятор не является ничьим ресурсом, но сам программирует и конфигурирует другие трансляторы. Смешанные трансляторы могут по внешним входам получать некоторую информацию извне, а по другим - команды на передачу этой информации по графу актуализации. Сама ИУС обычно является смешанным транслятором.
Любой транслятор является программируемым (0-программируемым). Если транслятор конфигурируемый, то он одновременно является и программируемым, и конфигурируемым. Конфигурируемый транслятор может менять реакции, но без подачи программирующей команды эти реакции не будут генерироваться.
Если в актуализации участвует большое число трансляторов, то можно вводить иерархию, выделяя подграфы. Граф актуализации критически зависит от иерархических уровней. Информация графа включает в себя трансляторы, потоки данных и все их команды. При введении иерархии меняется состав трансляторов и, что важно, состав их команд. Фактически команда останется прежней, но ее влияние на новый транслятор будет другим - команда может поменять тип. Начиная с самого верхнего представления ИУС как одного транслятора, можно опускаться на более детальные уровни, на которых будут появляться новые трансляторы и команды. При этом будут детализироваться не только трансляторы, но и их ресурсы. Так можно опускаться вплоть до логических элементов и электрических сигналов на их входных и выходных линиях.
Модель позволяет неограниченно детализировать граф актуализации. При этом большинству разработчиков не нужен уровень детализации одного порядка для разных фрагментов графа: разработчики инструментального программного обеспечения хорошо представляют фазу разработки, разработчики встроенного программного обеспечения - подграф программных трансляторов фазы исполнения. Чтобы иметь одинаковое (по уровню) представление обо всех частях графа актуализации, необходимо участвовать в разработке всех его трансляторов. Для современных ИУС это большая редкость, поэтому на практике граф актуализации представляется фрагментарно и отображает лишь то, что важно для разработчика, лишь то, на что он может повлиять. Формально создание полного графа актуализации затруднительно, поскольку в граф входят трансляторы, разработанные сторонними фирмами-разработчиками - электронные компоненты, библиотеки функций и др. Даже если известны их входные и выходные потоки, то внутренние связи являются закрытой информацией.
Фазы актуализации
Разделим процесс актуализации на 2 фазы и раскрасим вершины графа (трансляторы) 2-мя цветами в соответствии с принадлежностью одной из фаз:
• фаза разработки (design-time, DT) — желтая;
• фаза исполнения (run-time, RT) — зеленая.
Обе фазы участвуют в процессе актуализации ЦП, но по-разному. Фаза разработки совпадает с этапом разработки ИУС. Все формы представления ЦП на этой фазе предназначены для подготовки к его исполнению. Ни одна из форм представления на фазе разработки не пригодна для ее исполнения ИУС, как транслятором. Трансляторы фазы исполнения функционируют во время работы ИУС при каждом ее запуске. Основное отличие трансляторов этих двух фаз заключается во времени их работы. Работа RT-трансляторов - это работа системы. Работа DT-трансляторов происходит вне ИУС и до ее готовности. Очевидно, что в графе актуализации ЦП сначала попадает в фазу разработки, а затем в фазу исполнения.
DT-трансляторы преобразуют целевой алгоритм в форму, которая исполняется ИУС. Уже давно используется технология, по которой эта форма получается один раз, а исполняется много раз. Чтобы каждый раз не проделывать работу фазы разработки, нужны энергонезависимые хранилища информации. Без этих хранилищ полученную форму ЦП невозможно было бы сохранить для повторного использования, и при каждом старте нужно было бы программировать ИУС заново. Для большинства окружающих нас вычислительных систем это считается очевидной нормой, но раньше это было не так, и сейчас для некоторых видов ИУС (Evaluation Boards) это не так.
Разделение процесса актуализации на фазы позволяет дать новую трактовку широко распространенным в области разработки ИУС определениям. Одни трансляторы актуализируют целевой алгоритм внутри одной фазы, а другие переводят между фазами. Транслятор, переводящий потоки в фазу исполнения, называется компилятором. Т.е. компилятор - это тот транслятор, чьи выходные потоки могут быть актуализированы ИУС. Связанный подграф, состоящий из DT-трансляторов и заканчивающийся компилятором, называется инструментальной цепочкой. У ИУС, если она, например, многопроцессорная система, может быть несколько инструментальных цепочек. Для каждого из ее процессоров может быть своя инструментальная цепочка. Программное обеспечение ИУС (ПО ИУС) - это совокупность выходных потоков всех компиляторов, т. е. все потоки, приходящие в фазу исполнения. Традиционно под программным обеспечением понимается несколько другое, то, что создают программисты. Программисты как трансляторы вынесены за рамки графа актуализации, поэтому генерируемая ими форма представления ЦА не попадает непосредственно в фазу исполнения.
Организация фазы исполнения ИУС
Каждый RT-транслятор обладает специфической архитектурой и содержит набор команд. Изучать и использовать язык каждого транслятора для актуализации ЦП неэффективно. Для повышения эффективности программирования вводятся специальные трансляторы, через которые осуществляется программирование других трансляторов. Другими словами, на фазе исполнения выделяют такие трансляторы, чтобы остальные RT-трансляторы являлись их ресурсами. Назовем такие трансляторы базовыми (БТ). Выгода от использования БТ очевидна: программирование их ресурсов выполняется только с помощью языков БТ, а их в системе гораздо меньше, чем ресурсов. Наибольшее распространение получили следующие БТ: микропроцессоры, микроконтроллеры и программируемые логические интегральные схемы (ПЛИС).
Рассмотрим задачу программирования произвольного транслятора Т. Это можно сделать через его входной поток (рис. 2, а, поток А). Если транслятор Т доступен, как ресурс БТ, то его можно запрограммировать с помощью команд БТ (рис. 2, б, потоки Б-В). Формируется новая задача: как запрограммировать БТ, чтобы генерируемый им поток В оказался аналогичным потоку А. Можно ввести промежуточный транслятор Д.
Его задачей будет обеспечение актуализации тех функций транслятора Т, которые требуются для актуализации ЦП (рис. 2, в, потоки Г-Е-Ж). Такой транслятор назовем драйвером.
А Б В Г Д
Т БТ Т БТ ^^^ Т
Д
а) б) в)
Рис. 2. Способы программирования трансляторов
Например, последовательный канал можно программировать через регистры специального назначения, поддерживаемые микроконтроллером, а можно через драйвер последовательного канала. Вызов функций драйвера обеспечивает микроконтроллер, поэтому драйвер является ресурсом микроконтроллера. В некоторых случаях при наличии драйвера непосредственное программирование ресурса (рис. 2, е, потоки Г-Д) может быть запрещено, и единственным вариантом останется программирование через драйвер (рис. 2, в, потоки Г-Е-Ж).
Введение драйверов усложняет структуру графа актуализации, но для программирования ресурса нужно определить лишь первый программный поток. В первом случае это будет поток А, во втором - Б, а в третьем - Г. При этом поток Г через БТ может привести к программированию через поток Е и/или Д. В первом случае нужно реализовать функции для транслятора Т в его входном потоке, во втором - в потоке БТ, а в третьем случае эти функции уже реализованы драйвером и в потоке Г их нужно запустить на исполнение. Тем самым упрощается программный поток для БТ. Использование термина драйвер интуитивно более понятно для программирования микроконтроллеров и микропроцессоров. Для ПЛИС аналогом драйверов являются мегафункции. Упрощение входных потоков, которые нужно задать разработчикам ИУС, привело к увеличению сложности ее структуры. До тех пор, пока эта сложность не превысит простоту программирования потоков, будут пользоваться этим методом.
Таким образом, для упрощения программирования ресурсов ИУС вводится сеть драйверов, актуализирующая частные задачи, входящие в актуализацию ЦП. Это является одним из способов организации фазы исполнения графа актуализации. Дальнейшим развитием драйверов является появление устойчивых комбинаций драйверов, предоставляющих не только доступ к ресурсам ИУС, но и управляющих вычислительным процессом. Сначала это были библиотеки функций, затем они преобразовались в операционные системы (ОС). Программирование для ПК достигло уже такого уровня, что число функций, которые он может выполнять, столь велико, что программисты специализируются лишь на некоторых типах драйверов: разработке баз данных, WEB-интерфейсов, пользовательских приложений, приложений клиент-сервер и др. Программированием процессора ПК как БТ уже никто не занимается, потому что реализация функций, которые целесообразно решать с учетом вычислительной мощности современных ПК, слишком сложна.
Для упрощения актуализации ЦП на фазу исполнения могут быть добавлены не только драйверы, но и новые БТ. У них может быть новая архитектура, новые входные команды, более предпочтительные для актуализации ЦП. Программно реализованный БТ будем называть виртуальной машиной (ВМ). Если доступ к ресурсам обеспечивается с помощью драйверов, то они скрывают особенности ресурсов: ресурсы могут быть разными (разные модели устройств), а функции работы с ними будут одинаковыми. Программирование получается аппаратно-независимым, но зависимым от драйверов.
Программирование ВМ аналогичным образом является независимым от используемого БТ, но зависимым от самой ВМ (см. рис. 3). В программировании под ПК ВМ применяются гораздо шире, чем в ИУС. Perl, Java, Smalltalk, VBScript широко распространены, и разработчики ПО для этих ВМ востребованы.
Код
прикладной--КЗ^—^О-^
программы ВМ БТ Т
Рис. 3. Добавление виртуальной машины на фазу исполнения
Ни один транслятор не функционирует мгновенно, и это влияет на производительность фазы исполнения: чем больше в ней будет трансляторов, тем меньше будет производительность ИУС. Добавление драйверов и ВМ с целью организации вычислительного процесса понижает производительность ИУС. Добавление драйверов вносит незначительно понижение производительности, потому что драйверы добавляются между БТ и ресурсами: БТ программируется с первоначальной производительностью, а ресурсы - уже с пониженной. Добавление ВМ вносит значительное понижение производительности, потому что исходный БТ сам становится ресурсом и его программирование замедляется, а, значит, замедляется доступ ко всем его ресурсам.
Заключение
В статье представлено введение в модель актуализации. В нее входят трансляторы, функционирующие на разных фазах процесса актуализации и реализованные программно и аппаратно. Из-за ограничения объема статьи не были описаны следующие фрагменты модели:
• организация взаимодействия программных трансляторов;
• подсистема прерываний;
• системное и прикладное программное обеспечение;
• организация программного управления в соответствии с классификацией [5];
• способы построения графа актуализации.
На текущий момент в модели актуализации еще есть нерешенные вопросы, и получение ответов на них является важнейшей задачей. Для проверки модели были созданы средства автоматизированного построения графа актуализации по существующей ИУС. Практика показала, что графы современных систем слишком сложны для визуального восприятия: они насчитывают 50 и более трансляторов только на фазе исполнения и являются непланарными. Планируется автоматическая обработка графа и получение его характеристик.
Литература
1. Lee E. What's Ahead for Embedded Software? // Computer. 2000. № 9. Р. 19-28.
2. Lee E. Absolutely Positively on Time: What Would It Take? // Computer. 2005. № 7. Р. 85-87.
3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. М.: Символ-Плюс, 2000.
4. Lavagno. L, Sangiovanni-Vincentelli A., Sentovich E. Models of Computation for Embedded System Design. // System-level synthesis, 1999. Р. 45-102.
5. Ковязин Р.Р., Платунов А.Е. Программирование микроконтроллерных систем // Электронные компоненты. 2003. №4. С. 65-70.
