Software & Systems

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

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

В рамках синхронного подхода разрабатывается семейство сетевых протоколов TTP (Time Triggered Protocol), включающее протоколы типа TTP/C и TTP/A [2,3]. Протоколы TTP/C, ориентированные на передачу многобайтовых сообщений, требуют применения специализированных контроллеров. Протоколы TTP/A обеспечивают передачу однобайтовых сообщений и могут быть реализованы путем использования стандартной аппаратуры. Известна реализация протокола TTP/A, опирающаяся на использование интервальных таймеров и стандартных коммуникационных контроллеров [4]. Предлагаемые ниже методы реализации протокола TTP/A путем использования тех же аппаратных средств обеспечивают сокращение накладных расходов в 2-4 раза в сравнении с [4]. Кроме того, предлагаются варианты построения упрощенных версий протокола TTP/A.

Концепция протокола TTP/A. В основе протокола TTP/A лежит понятие сетевой базы сообщений (network message base [5]), которая может рассматриваться как глобальная структура данных, доступная в любом узле сети. База сообщений содержит две составляющих:

·     статическая составляющая – массив констант-спецификаторов сообщений (MEssage Description List – MEDL),

·     динамическая составляющая – массив переменных, фиксирующих содержание текущих сообщений; авторы протокола называют этот массив коммуникационным сетевым интерфейсом (Communication Network Interface – CNI).

Каждый узел сети имеет в ОЗУ свою копию массива текущих сообщений и в ПЗУ копию MEDL. В случае TTP/A структура элементов MEDL и CNI предельно упрощена [5]: i-й элемент MEDL содержит идентификатор узла, выполняющего передачу i-го элемента массива текущих сообщений; i-й элемент MEDL хранит копию сообщения (рис. 1).

Реализация TTP/A предполагает такое взаимодействие между узлами сети, при котором в каждый момент времени обеспечивается идентичность копий массива текущих сообщений, размещенных во всех узлах сети. Доставка сообщений может быть реализована, в частности, за счет использования стандартного последовательного коммуникационного интерфейса (Serial Communication Interface – SCI).

В общем случае протокол TTP/A допускает существование нескольких режимов функционирования распределенной системы. В таком случае для каждого из режимов строится своя сетевая база сообщений со своим специфическим MEDL.

Протокол TTP/A предписывает строгую синхронность всех действий, связанных с передачей сообщений: активизация коммуникационных задач, посылка и прием сообщений выполняются в предопределенные моменты времени. В основе хронологической структуры, определяющей порядок протокольных событий, лежит понятие раунда (рис. 2) [4]. Сетевое оборудование и коммуникационные программы в узлах сети работают периодически, раунд за раундом.

Каждый раунд разделяется на слоты. В рамках каждого слота передается ровно один байт данных. ТТР протоколы основаны на дисциплине доступа к шине с разделением времени (Time Division Multiple Access – TDMA). Это означает, что для каждого слота заранее определяется узел, выполняющий передачу данных; остальные узлы в рамках этого слота работают на прием. Каждый слот разделяется на три окна (см. рис. 2): (SDTi – ADTi) передача данных, (ADTi – DPTi) прием данных, (DPTi – SDTi + 1) обработка данных.

При нормальной работе системы на интервале (ADTi – DPTi) должно прийти прерывание RDIi от приема байта данных. Возникновение прерывания от приема данных вне окна приема воспринимается как некорректное – в этом случае система должна переходить к обработке соответствующей ветви ошибочных ситуаций. При нормальном приеме данных прерывания RDI используются для коррекции показаний локальных часов принимающего узла.

Такая коррекция необходима в связи с наличием относительного дрейфа локальных часов в различных узлах сети. Дрейф может быть обусловлен различными факторами, в том числе различием температурных условий. Принятый в ТТР/А принцип синхронизации часов опирается на предположение, что в рамках требуемой точности синхронизации прерывание RDI происходит одновременно во всех узлах сети. Поэтому коррекция локальных часов во всех узлах сети выполняется в момент возникновения прерываний RDI.

Первый слот каждого раунда отличается от всех последующих форматом и назначением. Байт данных, передаваемый в рамках первого слота, задает режим работы сети в течение начинающегося раунда, что дает основание называть его слотом режима (в оригинале – firework slot). Остальные слоты раунда используются для передачи элементарных сообщений: байт данных, передаваемый в рамках слота элементарных сообщений, размещается в очередном элементе динамической составляющей глобальной базы сообщений – очередном элементе массива текущих сообщений. Будем называть эти слоты слотами данных (в оригинале – normal slot).

Имеется однозначное соответствие между слотами данных и элементами базы сообщений, а именно, i-му слоту данных соответствует:

·     i-й элемент статической составляющей базы сообщений (то есть i-й элемент массива MEDL указывает номер узла, передающего элементарное сообщение в рамках данного слота);

·     i-й элемент динамической составляющей базы сообщений (фиксирует значение байта данных, передаваемого в рамках данного слота).

Формат слота режима отличается от формата слота данных в двух отношениях:

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

·     в случае слота режима байт данных передается с нечетным паритетом, в слотах данных байты данных передаются с четным паритетом.

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

Прецедент реализации протокола TTP/A. Вариант реализации протокола TTP/A для микроконтроллеров, совместимых с микросхемами типа HC12 фирмы Motorola, приведен в [4]. В этой реализации осуществлены предложения, обеспечивающие уменьшение накладных расходов на выполнение коммуникационных функций, а также предложения, обеспечивающие предоставление прикладным программам дополнительных данных об особенностях выполнения коммуникационных операций.

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

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

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

При нормальной работе системы обработчик прерываний от интервального таймера срабатывает три раза на каждом слоте: в начале окна передачи, в начале окна приема и в начале окна обработки данных; обработчик прерываний RDI срабатывает по одному разу в рамках каждого слота. Таким образом, реализация протокола осуществляется путем обработки четырех прерываний на каждом слоте каждого раунда. Такая схема реализации протокола TTP/A была воспроизведена авторами для микроконтроллера MC68HC12D60 фирмы Motorola для экспериментальной оценки накладных расходов на выполнение коммуникационных операций. Для достижения целей экспериментов оказалось достаточным воспроизведение упрощенной версии протокола TTP/A. Ниже приводится перечень упрощений протокола, допущенных при выполнении экспериментов.

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

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

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

Система с фиксированным режимом. В исходной версии протокола TTP/A первый слот каждого раунда выполняет двоякую роль: несет информацию для настройки всех узлов сети на выбор требуемого режима передачи сообщений (фактически – выбор требуемого варианта MEDL) и символизирует начало нового раунда передачи сообщений.

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

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

Разреженная синхронизация. Согласно общей концепции протокола ТТР/А дрейф часов в узлах сети должен корректироваться в каждом слоте по событию прием байта. Это означает, что на каждом слоте процессор тратит время на корректировку локальных часов. Такой подход обеспечивает период синхронизации Rsync равным длине одного слота. Согласно [6] связь допустимого значения Rsync с точностью D локальных часов отражается следующим соотношением: D = e + g + 2×r×Rsync, где r – максимальная скорость дрейфа локальных часов в кластере; g – гранулярность локальных часов (отношение единицы отсчета локальных часов узла к единице сетевого времени); e – максимальная величина задержки реакции процессора узла на прерывание RDI. При этом D, в свою очередь, влияет на величину окна приема. То есть чем меньше величина D, тем меньшей может быть длина окна приема (ADT; DPT), что способствует повышению вероятности своевременной регистрации сбоев в работе коммуникационной системы.

Заметим, что если узел работает под управлением операционной системы, значение e может многократно превышать 2×r×Rsync, то есть решающий вклад в правую часть приведенного соотношения вносит e, а не 2×r×Rsync, в особенности, если величина дрейфа часов r мала. В таком случае может отпасть необходимость синхронизации локальных часов на каждом слоте. Например, может оказаться достаточным синхронизировать локальные часы только в начале каждого раунда на первом его слоте. Тогда время обработки прерывания RDI на других слотах уменьшается на величину, равную времени выполнения блока коррекции локальных часов. Заметим также, что в этом случае глобальное системное время фактически представляется локальным временем ведущего узла.

Прием без тайм-аутов. Анализ протокола TTP/A показывает, что он может быть реализован без обработки прерываний в моменты ADT и DPT, ограничивающие окно приема: границы ADTi и DPTi окна приема могут быть вычислены либо при обработке SDTi, либо в рамках обработки прерыва- ния RDIi. Центр окна приема может быть смещен относительно ожидаемого момента активизации обработчика прерываний RDI (рис. 3).

Две основные компоненты программной реализации TTP/A методом приема без тайм-аутов – обработчик Timer_ISR прерываний SDT от интервального таймера и обработчик Receive_ISR прерываний RDI. Обработчик Timer_ISR выполняется в начале каждого слота; обработчик Receive_ISR выполняется в момент приема очередного сообщения (при нормальной работе системы – внутри окна приема). Номинальная продолжительность TRANS_INTERVAL передачи сообщения определяется продолжительностью генерации сообщения передающим узлом и временем распространения сигнала по сети. Длина окна приема (представляется константой TOLERANCE) должна быть достаточной, чтобы охватывать нормальный диапазон вариаций момента вызова обработчика Receive_ISR. Асимметрия окна приема (представляется константой ASYMMETRY) вызвана, в первую очередь, возможными задержками вызова Receive_ISR и задержками вызова обработчика прерываний SDT в передающем узле. Такие задержки возникают в тех случаях, когда в момент возникновения причины прерывания процессор работает с блокированными прерываниями.

Основу структуры алгоритма обработчика прерываний от таймера Timer_ISR составляют операторы, выполняющие посылку очередного сообщения (если данный узел активен в рамках текущего слота) и настройку на обработку следующего слота.

Основу структуры алгоритма обработчика Receive_ISR прерываний RDI составляют операторы, которые осуществляют размещение принятого сообщения в локальной копии базы сообщений (локальной копии CNI), а также операторы, выполняющие регистрацию момента приема сообщения и корректировку показаний локальных часов. Кроме того, они выполняют проверку корректности приема, а в случае обнаружения какой-либо некорректности (нарушение паритета или границ окна приема) выполняются действия, предусмотренные для зафиксированной сбойной ситуации (передача соответствующего извещения прикладной программе, реинициализация протокола обмена и т.п.

Подавление избыточных прерываний. Дополнительная возможность повышения эффективности реализации протокола TTP/A связана, во-первых, с тем, что узел, пассивный (принимающей сообщение) в текущем слоте, не нуждается в прерывании SDT в этом слоте и, во-вторых, с тем, что узел, активный (передающий сообщение) в текущем слоте, не нуждается в прерывании RDI в этом слоте.

Действительно, прерывание SDT необходимо лишь передающему узлу, для того чтобы вовремя выполнить передачу сообщения. Основная функция обработчика прерываний Timer_ISR выполняется условно, если узел активен в текущем слоте. Ранее в перечне функций обработчика прерываний Timer_ISR указана еще одна функция – настройка на обработку следующего слота; но в случае пассивного узла выполнение этой функции может быть перенесено в обработчик прерывания RDI. Таким образом, для принимающего узла прерывание SDT является избыточным. Отказ от генерации такого избыточного прерывания обеспечивает дополнительное снижение накладных расходов на реализацию протокола TTP/A.

С другой стороны, прерывание RDI необходимо лишь принимающему узлу, для того чтобы согласованно с другими узлами обновить элемент своей копии базы сообщений и скорректировать показание своих локальных часов. При этом корректировка часов фактически соответствует привязке к локальным часам передающего узла. Но передающий узел может обновить свою базу сообщений заблаговременно, в момент его передачи (в рамках обработчика Timer_ISR прерывания SDT). Кроме того, передающий узел не имеет корректировки своих локальных часов, поскольку именно к их показаниям привязываются показания локальных часов всех остальных узлов. Таким образом, для передающего узла прерывание RDI является избыточным. Отказ от генерации такого избыточного прерывания также обеспечивает дополнительное снижение накладных расходов на реализацию протокола TTP/A.

Результаты измерений эффективности методов реализации протокола TTP/A. Авторами проведены эксперименты по оценке эффективности рассмотренных методов реализации протокола TTP/A. Эксперименты были выполнены с упрощенной версией протокола (фиксированный ведущий узел, фиксированный режим). Такая упрощенная версия протокола TTP/A была реализована для микроконтроллера MC68HC12D60 фирмы Motorola (тактовая частота 8Мгц) тремя методами: приведенным в [4] (обработка четырех прерываний на слот); методом приема без обрамления окна приема тайм-аутами (обработка двух прерываний на слот); методом подавления избыточных прерываний (обработка одного прерывания на слот). Результаты экспериментов приведены на рисунке 4.

Расширение практики применения встроенных компьютерных систем реального времени сопровождается повышением требований к их надежности и отказоустойчивости. Одним из эффективных подходов, ориентированных на удовлетворение таких требований, является построение систем с синхронным выполнением компонент программной системы – синхронных систем. Построение распределенных систем синхронного типа требует использования специальных сетевых протоколов. Такими протоколами являются протоколы семейства TTP, в частности протокол TTP/A. Предложенные авторами методы позволяют повысить эффективность реализации протокола TTP/A в 2-4 раза. Варианты упрощения протокола TTP/A также позволяют минимизировать объемы памяти и процессорного времени, расходуемые на реализацию протокола, повысить прозрачность организации протокола и простоту его реализации.

Список литературы

1.     Никифоров В.В., Павлов В.А. Операционные системы реального времени для встроенных программных комплексов. //Программные продукты и системы.- 1999.- №4.- С.24-30.

2.    Kopetz H. TTP – A Protocol for Fault-Tolerant Real-Time Systems. // Computer, v.27, no.1, Jan 1994.

3.    Kopetz H., etc. A Prototype Implementation of a TTP/C Controller. Institute for Technical Informatics < Technical University, Vienna, Austria.

4.    Ebner C. Implementation of a TTP/A Prototype. Research Report no. 2/95. Institute for Technical Informatics < Technical University, Vienna, Austria. February, 1995, 34 p.

5.    Kopetz H. A Comparition of CAN and TTP. A paper for 15th IFAC Workshop on Distributed Computer Control Systems, Como, Italy, 1998.

Kopetz H. Real-Time Systems. Design prinnciples for Distributed Embedded Applications. Kluweer Academic Publisher, Boston