Научная статья на тему 'Обновление программного обеспечения распределенных микропроцессорных систем'

Обновление программного обеспечения распределенных микропроцессорных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
430
66
i Надоели баннеры? Вы всегда можете отключить рекламу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Постников Николай

Современные условия вынуждают коллективы разработчиков микропроцессорных систем резко сокращать длительность этапа проектирования и в кратчайшие сроки выходить на этап пуско-наладки и эксплуатации. При этом разработчику приходится жертвовать функциональностью и качеством создаваемого программного обеспечения, чтобы уложиться в заданные сроки. Одним из способов исправить ситуацию является предоставление возможности обновления программного обеспечения микропроцессорных модулей системы после того, как она была сдана в эксплуатацию и установлена на объекте.

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Обновление программного обеспечения распределенных микропроцессорных систем»

Компоненты и технологии, № 3'2004 Компоненты

Обновление программного обеспечения

распределенных микропроцессорных систем

Современные условия вынуждают коллективы разработчиков микропроцессорных систем резко сокращать длительность этапа проектирования и в кратчайшие сроки выходить на этап пуско-наладки и эксплуатации. При этом разработчику приходится жертвовать функциональностью и качеством создаваемого программного обеспечения, чтобы уложиться в заданные сроки. Одним из способов исправить ситуацию является предоставление возможности обновления программного обеспечения микропроцессорных модулей системы после того, как она была сдана в эксплуатацию и установлена на объекте.

Николай Постников

pnp@d1.ifmo.ru

Механизмы внутрисхемного программирования

В общем случае проблема обновления программного обеспечения микропроцессорного модуля сводится к замене содержимого (обычно это объектный код программы микроконтроллера) энергонезависимой памяти самого микроконтроллера или внешних микросхем. В настоящее время технологии FLASH, EEPROM, FRAM позволяют без демонтажа и физической замены микросхемы программировать носитель информации средствами самого микроконтроллера, не привлекая дополнительного оборудования или инструментария. Ведущие производители микропроцессорной элементной базы предлагают различные способы перепрограммирования своих устройств, уже установленных на плату [1]. Такой способ программирования называется In-Circuit Programming (ICP) или In-System Programming (ISP) и обычно используется для первоначальной инициализации микроконтроллера. Если разработчик использует микроконтроллер-ную базу, поддерживающую тот или иной способ ISP, и в процессе эксплуатации системы имеется доступ к инструментальному ISP-каналу каждого микроконтроллера, то в этом случае проблема обновления программного обеспечения может быть решена «стандартными» средствами (средствами, предоставленными производителями микропроцессоров), хотя это и сопряжено с определенными неудобствами:

• для обеспечения работы ISP-канала может потребоваться дополнительное оборудование и инструментальные средства;

• перевод микроконтроллера в режим ISP зачастую ставит сложные схемотехнические задачи перед разработчиком, что повышает стоимость устройства;

• различные узлы системы могут иметь свой уникальный ISP-интерфейс и инструментарий.

Даже будучи относительно неудобным, описанный способ позволит решить проблему обновления программного обеспечения компактных одномодульных систем. Для более сложных распределенных микропроцессорных систем такой способ становится очень ресурсоемким и сложным, как для разработчика, так и для конечного пользователя.

Распределенные микропроцессорные системы

Из множества микропроцессорных систем можно выделить достаточно широкий класс распределенных информационно-управляющих систем. Основной задачей информационно-управляющей системы является получение информации о состоянии внешнего объекта посредством специальных датчиков и сенсоров, принятие решения на основе полученной и накопленной информации и воздействие на объект с целью перевода его в заданное состояние. В некоторых случаях объект управления может простираться в пространстве на значительные расстояния или же ввиду жестких условий эксплуатации, ограничений габаритов, климатических требований, нехватки вычислительных ресурсов невозможно сосредоточить всю систему управления на одном-единственном вычислителе. В этом случае разработчик вынужден иметь дело со сложным иерархическим комплексом вычислительных

Компоненты и технологии, № 3'2004

Компоненты

узлов, объединенных некоторой информационной сетью и решающих общую задачу.

Для распределенных микропроцессорных систем базовые механизмы внутрисхемного программирования практически неприменимы по следующим причинам:

• разработчик не имеет физического доступа к отдельным модулям системы или такой доступ сопряжен со значительными финансовыми и иными затратами;

• КР-канал вычислителей был использован при начальном программировании микроконтроллеров и в целях повышения безопасности был отключен при сдаче системы в эксплуатацию;

• в состав системы может входить огромное количество модулей, индивидуальное программирование которых не представляется возможным (перепрограммированию подлежат как функционирующие в конкретный момент времени контроллеры, так и контроллеры, находящиеся на сервисном обслуживании или в ЗИП);

• выбор удобного времени перепрограммирования того или иного модуля (временно его функции будут недоступны системе) в общем случае целиком зависит от самой системы.

Перечисленные проблемы заставляют разработчика рассмотреть задачу обновления программного обеспечения микроконтроллеров не с точки зрения отдельных модулей, а с точки зрения системы. Задачу можно сформулировать как обновление (замену) программного обеспечения отдельных модулей системы, не нарушая общей работоспособности системы в целом. При решении этой задачи разработчику необходимо учитывать определенные требования:

• Удобство использования. Для проведения обновления системного программного обеспечения конечный пользователь должен прилагать минимум усилий и совершать минимум действий.

• Единый инструментальный интерфейс. Несмотря на возможную широкую номенклатуру устройств в системе, интерфейс обновления системного программного обеспечения должен быть единым для всех вычислителей.

• Малая ресурсоемкость. Это требование очень важно, т. к. возможность обновления программного обеспечения в общем случае не является необходимой частью целевой системы, а является способом ускорения проведения цикла разработки и выдачи изделия на рынок (конечному пользователю). В таких условиях отвлекать на решение этой задачи значительные вычислительные ресурсы нерационально.

• Безопасность. Обеспечив микроконтроллер в составе системы возможностью самостоятельно изменять программное обеспечение, разработчик сталкивается с проблемой возможных сбоев, которые приведут к несанкционированному выполнению тех или иных процедур обновления программного обеспечения, что в свою очередь приведет к нарушению целостности программного кода микроконтроллера.

MCN3

МА444

МА004

ГТ ІПІ

MD846

MD846

Рис. 1. Структура системы

• Надежность. Даже в случае корректной работы процедур внутреннего перепрограммирования энергонезависимых ресурсов в принципе не должно складываться ситуации, когда в результате того или иного сбоя (потеря питания, ошибка связи, рестарт микроконтроллера) микропроцессорный модуль останется без программного обеспечения и тем самым будет выведен из строя.

Для отдельных микроконтроллеров производители (Philips Semiconductors, Microchip, Atmel, Motorola, ST и др.) предлагают решение обозначенной задачи средствами In Application Programming (IAP). К таким средствам относятся различные аппаратные решения, предусмотренные производителями микроконтроллеров для перепрограммирования ресурсов энергонезависимой памяти прямо из целевой задачи без перевода микроконтроллера в специальный режим работы.

Таким образом, задачу обновления программного обеспечения распределенных микропроцессорных систем разработчик решает на двух уровнях: на системном уровне и на уровне микропроцессорного узла системы.

На первом уровне необходимо обеспечить взаимодействие частей системы в рамках единого инструментального протокола, идентификацию типов узлов и версий системного программного обеспечения, доставку новых версий программного обеспечения до вычислительных узлов. При этом общая работоспособность системы не должна быть нарушена. На этом уровне важными являются требования к удобству использования и единому инструментальному интерфейсу.

На уровне вычислительного узла необходимо обеспечить защиту программного кода, проверку целостности доставленного программного обеспечения, перепрограммирование энергонезависимых ресурсов микроконтроллера. На этом уровне важными являются требования к малой ресурсоемкости, безопасности и надежности.

Пример реализации технологии обновления программного обеспечения

Одна из технологий обновления программного обеспечения распределенных микропроцессорных систем была реализована специалистами ООО «ЛМТ» (http://lmt.ifmo.ru) в комплексе технических средств КТЖ-2 (КТС КТЖ-2). В состав комплекса входят модули центрального вычислителя MCNx, периферийные модули MAxxx, MDxxx и CSCx, коммуникационная система на базе интерфейсов Ethernet, CAN и RS-232/485, инстру-

ментальные средства системного и прикладного программирования (поддерживающие стандарт 1ЕС 1131-3). Центральный вычислитель МСЮ на базе 32-разрядного микроконтроллера Би^и МБ91Б362, оснащенный графическим дисплеем и сенсорной панелью, может выполнять функции ПЛК, интеллектуального пульта оператора, сетевого шлюза. При работе МСЮ взаимодействует с множеством периферийных модулей (МА444, МЭ846, МА004 и др.), обеспечивающих дискретный и аналоговый ввод-вывод, замер физических параметров окружающей среды и т. д. Конструктивно центральные модули выполнены в виде компактных панельных компьютеров, периферийные модули оформлены в корпусах для монтажа на ЭШ-рейку. Типы и количество периферийных модулей могут с легкостью варьироваться и расширяться. Типовая структура системы на базе КТС КТЖ-2 представлена на рис. 1.

Большинство типов периферийных модулей системы построено на базе 16-разрядных микроконтроллеров Би^и МБ90Б598. Семейство микроконтроллеров МБ90595 предлагает механизмы защиты энергонезависимой памяти, но для повышения уровня безопасности функционирования периферийных модулей процедуры, которые работают с внутренней БЫ^памятью микроконтроллера, были исключены из состава целевой системы. Код процедур становится доступным только после санкционированного и корректного получения программного обеспечения периферийным модулем.

Весь процесс обновления программного обеспечения был разбит на независимые этапы. При этом процесс обновления программного обеспечения может начинаться с любого из этапов, а сбой на любом из этапов фатально не нарушит весь процесс обновления, а лишь потребует повторного прохождения сбойного этапа. Реализовано 4 этапа:

1. Создание образа системного программного обеспечения (обновления). Эти данные помимо самого объектного кода содержат команды для его размещения во БЫ^па-мяти периферийного модуля, различные контрольные суммы, идентификаторы типов модулей и версии программного обеспечения. Обновление формируется таким образом, что содержащихся в нем данных полностью хватает для восстановления объектного кода программного обеспечения периферийного модуля.

2. Доставка обновления в систему по специальному инструментальному каналу. Передаваемое обновление может воспринимать как центральный вычислитель, так и периферийные модули.

Компоненты и технологии, № 3'2004

Начальный загрузчик

SSI

Хранилище

О

Инструментальный

интерфейс

RS-232

Рис. 2. Архитектура периферийного модуля

1

CAN

Системное ПО

С с Служба обновления истемного ПО

«Прикладной» / ввод/вывод 4

Целевой сетевой интерфейс

3. Передача обновления в периферийные модули системы, которые сохраняют его для последующей обработки.

4. В каждом модуле происходит обработка обновления, полное или частичное уничтожение старого программного обеспечения модуля и программирование нового программного обеспечения.

Поскольку обновление должно быть полностью доставлено и сохранено перед началом его обработки в периферийном модуле, пришлось учесть требования малой ресур-соемкости. Технически задача была решена сокращением объема обновления с использованием относительно несложных алгоритмов сжатия данных без потерь. На персональном компьютере разработчика создается файл-обновление, который потом нужно без изменений доставить в периферийный модуль. Файл-обновление самодостаточен, что позволяет периферийному модулю в дальнейшем самостоятельно восстановить объектный код программного обеспечения.

Все программное обеспечение периферийного модуля разбито на две части: начальный загрузчик и системное программное обеспечение (собственно эту часть программного обеспечения имеет возможность обновлять разработчик или пользователь). Архитектура периферийного модуля представлена на рис. 2. Передача и сохранение обновления реализуется через специально созданный программный интерфейс работы с хранилищем обновлений (SSI). Этот интерфейс содержит всего 5 функций (SsiUnlock, SsiAllocate, SsiStoreItem, SsiGetItemCount, SsiLock), но при этом полностью обеспечивает решение поставленной задачи. Интерфейс SSI экспортируется через собственный инструментальный канал узла (реализуется в начальном загрузчике) и через целевой протокол

Таблица. Технические характеристики периферийного модуля

Объем кода обновляемого программного обеспечения 56 кбайт

Объем кода начального загрузчика 4 кбайт

Объем резидентной части загрузчика в RAM 200 байт

Объем хранилища 64 кбайт

Типичный объем обновления 10-20 кбайт

Задержка при рестарте модуля • с декодированием обновления • без декодирования обновления 15-20 с нет

сети CAN (реализуется в системном программном обеспечении).

Технические характеристики периферийных модулей, относящиеся к работе механизмов обновления программного обеспечения, приведены в таблице.

В целевом протоколе сети существует возможность определения номенклатуры периферийных модулей системы в реальном масштабе времени, определение их типов и версий программного обеспечения. Передача обновлений периферийным модулям происходит в широковещательном режиме, что очень важно, так как в системе обычно присутствует много однотипных модулей. Передача обновлений по сети осуществляется в наименее приоритетном режиме, что практически не влияет на временные параметры выполнения системой целевой задачи. Служба, реализованная в центральном вычислителе, позволяет в реальном масштабе времени в полуавтоматическом режиме отслеживать версии программного обеспечения периферийных модулей и производить при необходимости процедуру загрузки обновлений.

Заключение

Использование технологий обновления программного обеспечения в распределенных микропроцессорных системах позволяет разработчикам значительно сократить сроки получения пилотного образца системы, снизить затраты на этапах внедрения и опытной эксплуатации, получать масштабируемые решения с гибкой целевой функциональностью [2]. Разработанная технология обновления программного обеспечения может быть легко реализована в различных коммуникационных средах. МММ

Литература

1. Гаврилюк Д. Внутрисхемное программирование // Компоненты и Технологии. 2003. № 8.

2. Платунов А. Е., Постников Н. П. Единое проектное пространство плюс аспектная технология — перспективная парадигма проектирования встраиваемых систем // Научно-технический вестник СПбГУ ИТМО. Вып. 11. Актуальные проблемы анализа и синтеза сложных технических систем. СПб.: СПбГУ ИТМО. 2003.

Компоненты

е

i Надоели баннеры? Вы всегда можете отключить рекламу.