Комплекс вычислительных средств
Крупные встроенные системы реального времени обычно управляются не одним, а несколькими компьютерами, связанными сетью передачи данных. Если все компьютеры и их операционные системы одинаковы, сеть называется гомогенной, в ином случае – гетерогенной. Управлять гетерогенной сетью намного сложнее, хотя в наш век стандартных протоколов связи эти трудности успешно преодолеваются. Понятие "комплекс вычислительных средств" и связанные с этим понятием проблемы мы продемонстрируем на нескольких примерах.
Более 6 лет мы разрабатывали большую междугородную телефонную станцию. Эта АМТС предназначалась для правительственной связи, поэтому главным требованием была надежность. Именно из-за соображений надежности для управления АМТС был разработан довольно сложный комплекс вычислительных средств (КВС).
Во главе КВС стоит троированный "Самсон", его надежность во много раз превосходит надежность любого другого элемента КВС. Именно "Самсон" принимает окончательное решение во всех спорных ситуациях. Через центральный канал межмашинного обмена (ЦКМО) "Самсон" связан с периферийными управляющими устройствами (ПУУ), которых может быть до 100 штук, и ЦКМО, и ПУУ дублированы. Каждая половинка ПУУ связана с одним подканалом ЦКМО, но может быть переключена и на другой подканал. Каждое ПУУ представляет собой небольшую ЭВМ, управляющую телефонным оборудованием (абонентскими комплектами, коммутационным полем, концентраторами и т.д.)
Две половинки ПУУ работают синхронно, выполняя одну и ту же программу. Существует специальная схема, проверяющая совпадение результатов половинок, выдаваемых в ЦКМО. Если "Самсон" получит сигнал о несовпадении результатов (то, в первую очередь, проверяется корректность ЦКМО) – просто посылается контрольный запрос на соседние ПУУ: если ответ поступит, то сбилось ПУУ, если нет, то что-то случилось с ЦКМО. Если вышел из строя один из подканалов ЦКМО, он выводится из конфигурации, второй подканал переводится в другой режим работы, например, каждое сообщение повторяется или кодируется специальным кодом с избыточностью, который позволяет обнаруживать и даже исправлять ошибки передачи.
Если же с ЦКМО все в порядке то, прежде всего надо выяснить, какая из половинок ПУУ сломалась. "Самсон" запускает короткий диагностический тест в обеих половинках, затем выводит неисправную часть из конфигурации и сообщает оператору о необходимости ремонта. Ввод в конфигурацию половинки ПУУ после ремонта является весьма нетривиальной задачей. Остановить работающую половинку даже на короткое время для выравнивания данных с вводимой половинкой нельзя из-за требований надежности и готовности АМТС в целом. Нам удалось придумать хитрый алгоритм постепенного выравнивания данных, но поскольку несколько поколений студентов заваливало экзамен на этом вопросе, я отказался от мысли изложить содержание алгоритма в лекциях, хотя готов рассказать его интересующимся в индивидуальной беседе.
АМТС управляется операторами, сидящими за рабочими местами операторов (РМО), которых может быть до 30 штук. Каждое РМО — это две обычных персональных ЭВМ (основная и резервная). Никаких аппаратных средств резервирования ПЭВМ не имела, поэтому пришлось изобретать программную реализацию. И основная, и резервная ПЭВМ связана с "Самсоном" отдельным, сравнительно медленным последовательным каналом. В "Самсоне" для каждого РМО предусмотрен специальный драйвер, который "знает", какая ПЭВМ в данный момент основная, а какая – резервная. Любая информация для РМО из "Самсона" посылается в обе ПЭВМ, все действия оператора разбиты на короткие транзакции по базе данных конкретного РМО. Если основная ПЭВМ отказала, что видно по тестам, таймерным событиям или просто визуально, оператору достаточно пересесть на резервную ПЭВМ. При этом гарантируется, что все транзакции, завершенные на основной ПЭВМ, закончены и на резервной, поэтому оператору не придется заново вводить более одной команды.
В 1996 году мы успешно прошли государственные испытания этой АМТС, накопили бесценный опыт разработки и комплексной отладки сложных программно-аппаратных средств, отработали технологию программирования RTST на базе SDL, в общем, все было хорошо.
Мы были уверены в скором и успешном продолжении работ, но в этот момент государственное финансирование окончательно прекратилось, и наш отдел разработки средств телекоммуникаций остался без работы.
Поэтому как нельзя кстати оказалось предложение ЛНПО "Красная Заря" переделать или написать заново программное обеспечение для уже существующей сельской АТС "Бета". Станция была разработана в ЛНПО "Красная Заря", сертифицирована и уже серийно выпускалась. Но оказалось, что ПО, сделанное "на коленках", без всякой технологии, очень дорого в сопровождении – трудно исправить ошибку, сложно добавить новую функцию. В результате каждая АТС после полугода эксплуатации обладала индивидуальным ПО, а если после этого исправлялась какая-то незамеченная ранее ошибка или добавлялась новая функция, то приходилось переделывать все версии ПО.
В другой ситуации мы, возможно, и отказались бы от такого предложения, но поскольку другой работы не было, делать было нечего. Только много позже мы поняли, как нам повезло. Мы изучили чужой опыт, познакомились с требованиями рынка, получили подробно изложенные алгоритмы большинства протоколов, используемых на российских каналах связи.
Для начала нас познакомили с общей архитектурой АТС "Бета".
МАЛ — модуль абонентских линий, к которому подключаются до 180 телефонов.
СЛ — соединительная линия к другой АТС.
МГО – модуль группового оборудования.
Каждый из этих модулей управлялся контроллером i8086 и имел
небольшую оперативную память. Все модули связывались между собой общей шиной с пропускной способностью 9,6 кбит/сек.
Нам объяснили, что общая шина является самым узким местом станции, многие протоколы не укладываются в ограничения по времени, поэтому сейчас они думают перейти на скорость 19,2 кбит/сек.
Наш специалист Н.Ф. Фоминых тут же подсчитал, что тогда каждый контроллер будет тратить больше половины своего времени только на обработку прерываний (известно, что при тактовой частоте 4,67 Мгц этот процессор имеет чуть больше 1 млн.
операций в секунду).
В результате часа разговоров с разработчиками АТС мы нашли
несколько способов уменьшить нагрузку на общую шину:
- Для защиты от ошибок при передаче по шине использовался сложный протокол, который обычно применяется при передаче на большие расстояния (сотни километров). А тут внутри одной стойки к каждому пакету добавляется несколько байтов!
- На каждый полученный пакет каждый модуль должен был послать двухбайтовую квитанцию, подтверждающую правильность приема. Но оказалось, что порядок посылки пакетов жестко определен – всегда МГО сначала посылает какому-то модулю запрос, затем этот модуль должен послать ответ в МГО, причем каждый пакет имеет контрольную сумму своих битов. Н.Ф. Фоминых предложил в каждом пакете иметь всего 1 бит, подтверждающий правильность передачи предыдущего пакета.
Уже первые два предложения снизили нагрузку на шину более чем в 2 раза. Но мы пошли еще дальше. Разработчики АТС "Бета" предполагали, что МАЛ (модуль абонентских линий) будет очень простым, например, он будет принимать номер вызываемого абонента по одной цифре и пересылать ее в МГО.
- Мы предложили принимать в МАЛ весь номер, а только потом сразу в одном пакете передавать его в МГО. Чтобы понять, сколько цифр надо принять – одну (8 для входа в межгород), две (01,02,03), три (для внутриофисных вызовов), пять (сельская связь) и т.д., в каждый МАЛ пришлось поместить по небольшой таблице, настоящая таблица маршрутизации все равно осталась в МГО. Таким образом, нагрузка на сеть упала еще в 5-7 раз.
Самое забавное и поучительное событие произошло через несколько месяцев после того как мы начали разрабатывать новое ПО для АТС "Бета". Наша операционная система теряла отдельные сообщения, хотя по всем расчетам производительности процессора должно было хватать. После долгих мучительных поисков ошибки в ПО Н.Ф. Фоминых решил проверить правильность работы аппаратуры и обнаружил ошибку в разводке платы процессора. Вместо тактовой частоты 4,67 МГц на вход clock процессора подавалась частота 1 МГц, предназначавшаяся совсем для других целей.Таким образом, все 30 АТС, выпущенные до нас, управлялись в 5 раз более медленными ЭВМ, чем могли бы. Потому и все проблемы были связаны с шиной, т.к. любая работа с ней связана c обработкой прерываний, где производительность процессора критична. Боюсь, если бы разработчики АТС "Бета" обнаружили эту ошибку сами, к нам бы вообще не обратились и тогда бы история нашего коллектива сложилась совсем иначе.
