CC BY-NC-ND
29
ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ И РЕАЛИЗАЦИИ БЮДЖЕТНЫХ РАСПРЕДЕЛЁННЫХ СИСТЕМ МОНИТОРИНГА И УПРАВЛЕНИЯ ОБОРУДОВАНИЕМ ЭЛЕКТРОСВЯЗИ
М.Л. Зубов,
старший преподаватель Нижегородского филиала ГУ-ВШЭ, zubov@hse.nnov.ru
Статья посвящена рассмотрению вопросов построения бюджетных систем мониторинга и управления оборудованием электросвязи. Дается характеристика этих систем, приводится обзор технологий, методик и подходов, пригодных для создания систем управления и мониторинга при выполнении условий накладываемых ограничений.
^ Л
Введение
Автоматизированные системы управления и мониторинга (СМУ) уже нашли своё место . во всех областях деятельности человека. Полезность СМУ, а так же и то, что их роль с каждым годом будет расти, уже не вызывает сомнений. Не смотря на то, что СМУ разрабатываются и используются в течение продолжительного времени, и еще имеется много вопросов, требующих детального исследования. При этом вопросы экономического характера являются наиболее актуальными. К ним относятся как оценка экономической целесообразности внедрения СМУ, так и оценки затрат на всех этапах жизненного цикла системы.
По мере разработки, внедрения и эксплуатации СМУ в различных предметных областях были получены типовые подходы к проектированию СМУ. Примером достаточно хорошо проработанных предметных областей могут служить системы контроля и управления технологическими процессами, охранные системы, системы управления безопасностью полетов и др. Объединяет выше перечисленные предметные области то, что СМУ являются неотъемлемой частью бизнес-процессов, и использование СМУ мотивируется не только экономическими факторами.
Другой класс СМУ — это системы, создание которых мотивировано исключительно экономическими
факторами. Примером может служить учёт и контроль энергоресурсов. Очевидно, что если экономический эффект от внедрения равен нулю, система не будет создана. Создание систем этого класса сопряжено с определёнными трудностями. В частности, необходимо экономическое обоснование создания системы, которое в свою очередь строится на основе прогнозов затрат как на создание системы, так и на эксплуатацию. Прогнозы должны строиться на основе анализа моделей, описывающих этапы жизненного цикла (ЖЦ) систем. К сожалению, не существует полного набора моделей (для всех этапов ЖЦ) для выполнения анализа и получения точных прогнозов. На данный момент единственной моделью, широко используемой для оценки стоимости, является статистическая модель COCOMO (Constructive Cost Model), предложенная Барри Боэмом в 1981 г. [1]. К сожалению, для вывода формул использовались данные о выполнении реальных программных проектов, ориентированных на конечного пользователя. Доступных данных о результатах создания сложных распределенных систем, к которым относятся СМУ, на момент создания просто не было. Данные о проектах, имеющих как программную, так и аппаратную компоненты, также не учитывались.
Трудности, возникающие в проведении исследований, и проблемы построения моделей, позволяющих получать оценки затрат с приемлемой
точностью, вынуждают искать пути создания системы с предсказуемым уровнем затрат. Ниже описываются подходы и методики, позволяющие создавать БС с заданным качеством при минимальных затратах и сроках разработки за счет введения ограничений на процесс создания системы, её архитектуру и принимаемые дизайнерские решения.
Бюджетные системы мониторинга и управления оборудованием электросвязи
Бюджетная система (БС) — это система, удовлетворяющая критерию экономической целесообразности при экономическом эффекте использования больше или равном нулю. С точки зрения экономического эффекта БС находятся в пограничном слое между понятиями «выгодно» и «не выгодно». Задачи, решаемые БС, имеют вспомогательный характер и не ориентированы на массового потребителя. БС не влияют на процесс основной деятельности предприятия (предоставления услуг или производства). Другими словами, извлечение или повышение прибыли от использования системы не является основополагающим критерием, влияю -щим на принятие решения о создании системы.
Перечислим примеры бюджетных систем:
♦ система управления электроосвещением;
♦ система контроля присутствия опасных газов;
♦ система контроля резервного электропитания;
♦ система контроля температуры в различных точках помещения и др.
Приведённые примеры объединяет то, что нет явных факторов, мотивирующих автоматизацию этих задач. И постановка задачи, и набор требований имеют частный характер. Для пояснения последнего утверждения можно привести следующий пример реальной системы, касающийся контроля опасных газов. В результате утечки газа, особенностей расположения газопровода и здания время от времени газ проникает в помещение. По ряду причин проблема не может быть решена полностью. В результате появилась задача контроля присутствия опасных газов в точке, располагающейся на расстоянии до 1,5 километров от точки наблюдения. Похожие особенности можно привести по остальным примерам.
Из всего спектра областей применения БС мы рассматриваем системы мониторинга и управления оборудованием электросвязи.
В общем случае БСМУ состоят из одной или нескольких сетей распределенных датчиков, актуаторов и центрального узла (ЦУ), выполняющего сбор
и предварительную обработку данных. Доступ к данным обеспечивается через локальные интерфейсы ЦУ. ЦУ также имеет интерфейс для интеграции с внешними системами управления. Дизайн системы содержит как программную, так и аппаратную составляющие. Под аппаратной компонентой подразумевается часть дизайна, ориентированная на разработку нового и/или модификацию существующего оборудования.
Постановка задачи проектирования и разработки бюджетных систем
Выше была дана характеристика БС с точки зрения потребителя. С точки зрения разработки на систему накладываются дополнительные требования:
♦ на момент создания предполагается единичное производство, с перспективой выхода на серийное производство. Как правило, изначально система создается для конкретного заказчика и предполагается, что появятся другие;
♦ жизненный цикл: короткий (до момента решения частной задачи; до года) или долгий (от нескольких лет);
♦ предельно короткие сроки разработки. Независимо от типа жизненного цикла, срок выполнения не может быть более нескольких месяцев;
♦ требования к системе определены не полностью;
♦ требования изменяются в течение жизненного цикла системы.
С учётом выше обозначенного задача построения бюджетной системы формулируется следующим образом:
Создать программно-аппаратный комплекс, удовлетворяющий заданным требованиям в течение промежутка времени менее 6 месяцев, не превышая заданный бюджет. Требования включают в себя помимо функциональных требований также ограничения на стоимость составляющих системы (например, одной точки контроля) и затрат на ее сопровождение.
Особенности выполнения этапов анализа требований и проектирование БСМУ
Анализ требований и проектирование являются типичными этапами любой системы. Несмотря на то, что в литературе и научных работах уделяется много внимания к формализации выполнения этих этапов, много вопросов остается открытыми.
Одними из таких вопросов являются совместное проектирование программных и аппаратных компонентов, эффективная, с экономической точки зрения, декомпозиция задач и др. По определению БСМУ имеют как программную, так и аппаратную компоненту. Решение этих вопросов является принципиальным для успешного создания ВСМУ. В работах Николоса Вороса [2] и Клауса Бехендера [3] детально рассматриваются вопросы совместного дизайна и текущее состояние дел по этому вопросу. В работе Мухамеда Абида [4] приводится пример, на базе которого рассматривается влияние различных дизайнерских решений для выполнения одной и той же задачи на стоимость решения и ключевые характеристики системы.
Основной вывод, который можно сделать по результатам [2—4] — это необходимость создания прототипа как минимум до момента формирования спецификации системы, и желательно, чтобы он существовал на момент анализа требований. Дополнительные аргументы в пользу создания прототипа приведены в работе Клауса Бехендера [5].
Следует отметить, что достоинства прототипов с точки зрения снижения рисков оценены не только разработчиками, но и заказчиками. В настоящее время наличие прототипа является обязательным условием заключения контракта на поставку систем мониторинга и управления. Прототип с точки зрения заказчика выглядит как реальная система, выполняющая основные функции, и рассматривается как нечто промежуточное между «почти готовым продуктом» и чем-то, что должно быть разработано.
Прототип не является реально существующим продуктом и представляет смесь существующих частей системы и частей, выполняющих эмуляцию и симуляцию не существующих.
Подходы к выполнению этапа реализации подсистем БСМУ
Наиболее часто применяемым подходом для построения различных подсистем системы управления является использование COTS (Commercial-Off-the-shelf) продуктов [6]. Термин COTS полностью определен в [3] и относится к существующим продуктам, которые можно купить у некоторого производителя (например, заказать через каталог). Основными характеристиками подобных продуктов являются:
♦ продукты уже существуют на рынке;
♦ широко доступны;
♦ могут быть куплены (получены в лизинг или лицензированы).
Использование COTS-продуктов позволяет использовать уже готовые части системы, по приемлемой стоимости, которые уже выполняют часть функциональности системы.
Другим подходом для реализации подсистем является использование продуктов, относящихся к категории NDI [2] (nondevelopmental item). Эти продукты обладают своими особенностями:
♦ существует полнофункциональная реализация продукта, но она не удовлетворяет всем критериям для широкой продажи на рынке (например, нет качественной упаковки, оцениваемый потребительский спрос слишком мал для широких продаж и т.п.);
♦ для конечного пользователя существуют определенные сложности получения информации о том, что продукт существует и какими характеристиками обладает;
♦ как правило, продукт может быть приобретен по прямому соглашению с производителем, минуя розничные или оптовые сети.
С точки зрения разработчика системы NDI — это продукт, который им не разрабатывается и рассматривается как «почти готовый». Последнее означает, что, несмотря на то, что NDI-продукт существует, он не обязательно на 100% соответствует спецификации заказчика и требует незначительной модификации, выполняемой по контракту.
Альтернативой COTS- и NDI-продуктам является разработка уникальных компонентов системы с расчетом на получение более дешевого решения.
COTS- и NDI-продукты объединяет то, что стоимость и требуемое время на их интеграцию могут быть оценены с высокой точностью. Разница между ними в том, что NDI-продукты более гибки в интеграции, но менее доступны широкому кругу потенциальных заказчиков.
Разработка уникальных компонентов также имеет свои достоинства и недостатки. Основным недостатком является невозможность с высокой степенью точности оценить затраты на разработку. И опыт показывает, что сравнительно большой процент разработок заканчивается неудачей.
К достоинствам разработки уникальных компонентов можно отнести:
♦ безусловное соответствие спецификации;
♦ потенциальная возможность изменения/рас -ширения функциональности, в соответствии с изменяющимися требованиями при минимальных затратах;
♦ возможность проектирования компонента, обладающего дополнительными возможностями
(«на вырост»), не связанными непосредственно с задачами текущего проекта; это позволяет в дальнейшем его использовать в виде самостоятельного продукта категорий COTS или NDI;
Очевидно, что в реальной системе продукты из всех трех перечисленных категорий должны разумно сочетаться на основе определенной методологии анализа и проектирования. По результатам анализа реальных проектов можно сказать, что в ходе принятия решения о том, что должно использоваться при построении БСМУ, придерживаются следующих эвристических правил:
1. Если существует COTS-продукт, то используется он.
2. Если не существует COTS-продукта и существует NDI-продукт, то используется он.
3. Лишь в том случае, если нет ни COTS- ни NDI-продуктов, то принимается решение о разработке.
Модель быстрой разработки и компонентное конструирование
Модель быстрой разработки приложений (Rapid Application Development, далее RAD) [8] обеспечивает экстремально короткий цикл разработки. RAD-процесс позволяет создавать программные системы за период от 2-x до 3-х месяцев. Основу RAD составляет использование компонентно-ориентированного конструирования. RAD применим только тогда, когда требования к системе определены полностью. Ключевой особенностью RAD является построение моделей предметной области и создаваемой системы с дальнейшей генерацией приложения по этим моделям.
Компонентное конструирование (КК) подразумевает использование как COTS-, так и NDI-продуктов. КК с точки зрения экономической эффективности рассматривается в [9]. Основным достоинством КК является снижение затрат на разработку и сопровождение систем. При этом процесс создания системы смещается из области разработки в область интеграции. Интеграция в свою очередь, в отличии о разработки, хорошо формализованный процесс, позволяющий с высокой точность оценивать как время требуемое на интеграцию так и затраты сопряженные с ней.
Эволюционирующее аппаратное обеспечение
БСМУ — это сложная распределённая программно-аппаратная система. Именно распределенность диктует необходимость аппаратной компоненты в системе. Для снижения затрат на эксплуатацию системы требуется использование узлов предварительной обработки информации (УПОИ). Кроме того, стоимость этих узлов должна быть минимальной. Помимо этого требуется возможность для УПОИ быть подключенными к разнородному оборудованию электросвязи. Таким образом, необходимо иметь достаточно большую номенклатуру дешевых УПОИ.
Но существует альтернативный вариант — использование эволюционирующего аппаратного обеспечения (ЭАО), подробно рассмотренного в тематическом выпуске журнала «Communications of the ACM» [11 — 12]. Использование ЭАО позволяет, помимо снижения номенклатуры УПОИ, решить и проблемы применимости RAD, быстрого создания прототипов и совместного проектирования программных и аппаратных компонент.
Выводы
Ввиду специфических особенностей БСМУ не представляется возможным выработка универсальных методик и подходов, пригодных для создания БСМУ для широкого круга предметных областей.
Предлагается следующий подход для построения БСМУ оборудованием электросвязи:
1. Эволюционирующее аппаратное обеспечение должно быть использовано для построения прототипов системы.
2. Должна быть разработана архитектура типовой БСМУ с учетом особенностей использования RAD (быстрое создание приложений) подхода для реализации программных компонент системы.
3. Должны быть построены модели с целью выполнения имитационного моделирования с целью анализа различных вариантов построения системы.
4. Должны быть выработаны методики автоматической/полуавтоматической декомпозиции системы на программные и аппаратные компоненты.
5. Должна быть использована эволюционирующая аппаратная платформа для реализации аппаратных компонент. ■
Литература
1. Boehm B.W., Abts C., Brown A.W., at al. Software Cost Estimation with COCOMO II. — Prentice Hall, 2000. 256 р.
2. Voros N. Hardware/Software Co-design of Complex Embedded Systems // Design Automation for Embedded Systems. 2003. № 8. P. 5 -49.
3. Buchenrieder K. Integration of Reconfigurable Hardware into System-Level Design // Design Automation for Embedded Systems. 2000. № 5. P. 222 -231.
4. Abid M. Exploration of Hardware/Software Design Space through a Co design of Robot Arm Controller // EURO-DAC'96 with EURO-VHDL'96. P. 599.
5. Buchenrieder K. Rapid Prototyping of Embedded Hardware/Software Systems // Design Automation for Embedded Systems. 2000. № 5. P. 215 -221.
6. COTS and Open Systems — An Overview: Software Technology Roadmap // http://www.sei.cmu.edu/str/descriptions/cots.html#110707 .
7. Federal Acquisition Regulations. — Washington, DC: General Services Administration, 1996. 576 р.
8. McConnel S. Rapid Development. — Microsoft Press; 1st edition, 1996. 347 р.
9. Component-Based Software Development / COTS Integration: Software Technology Roadmap // http://www.sei.cmu.edu/str/descriptions/cbsd.html.
10. Andrews D., Niehaus D. Programming Models for Hybrid CPU/FPGA Chips // Computer. 2004. № 1. P. 118 —120.
11. Xin Yao Evolvable Hardware: Introduction // Communications of ACM. 1999. V. 42. № 4. P. 46 —49.
12. Sipper M., Mange D., Sanchez E. Evolvable Hardware: Quo Vadis Evolvable Hardware? // Communications of ACM. 1999. V. 42. № 4. P. 50 —56.
13. Marchal P. Evolvable Hardware: Field-Programmable Gate Arrays // Communications of ACM. 1999. V. 42. № 4. P. 57 —59.
14. Higuchi T, Kajihara N.: Evolvable Hardware: Evolvable Hardware Chips for Industrial Application // Communications of ACM. 1999. V. 42. № 4. P. 60 —66.
e
B.B. Липаев
ОТЕЧЕСТВЕННАЯ
ПРОГРАММНАЯ
ИНЖЕНЕРИЯ:
ФРАГМЕНТЫ ИСТОРИИ И ПРОБЛЕМЫ
Издательство «Синтег» выпустило новую книгу Владимира Васильевича Липаева, профессора кафедры управления программной инженерии ГУ-ВШЭ и главного научного сотрудника Института системного программирования РАН «Отечественная программная инженерия: фрагменты истории и проблемы».
В монографии проанализированы этапы отечественной истории развития вычислительной техники с акцентом на методы и процессы программирования. Первая глава отражает развитие в стране автоматизации программирования в 50—60-е гг. Представлены процессы, начальные проекты отечественной вычислительной техники, развитие программирования и роль ведущих специалистов, заложивших основы в этой области. Выделены особенности развития специализированных вычислительных машин и программирования для оборонных систем реального времени. Формированию программной инженерии в 70-е гг. посвящена вторая глава. В третьей главе отражено развитие программной инженерии в 80-е гг. Изложена история развития экономики, методов и процессов программной инженерии в 70—80-е гг. Значительное внимание уделено реализации ПРОМЕТЕЙ-технологии программной инженерии для создания крупных комплексов программ реального времени оборонных систем. В четвертой главе подведены итоги развития программной инженерии и формирования ее методологии. Представлены проблемы расширения состава и совершенствования международных стандартов и инструментария программной инженерии, а также проблемы обучения методологией программной инженерии студентов и специалистов.
Книга предназначена для специалистов по вычислительной технике и программной инженерии, студентов и аспирантов, интересующихся историей развития и проблемами отечественной науки и техники в этой области.
