Технология программирования встроенных систем реального времени

Понятие встроенной системы

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

Многие авторы относят создание встроенных систем к числу самых трудных задач; в каком-то смысле, здесь сконцентрированы практически все проблемы системного программирования.

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

Реактивность. По определению, встроенная система реального времени должна всегда укладываться в некоторые временные рамки. Отсюда вытекают требования к тщательному анализу времени протекания различных процессов, выделению критически важных задач (здесь, как всегда, действует правило 20-80 – 20% задач занимают 80% времени исполнения), глубинной оптимизации программ.

Компактность. Оптимизировать нужно не только время исполнения, но и объем используемой памяти. Например, в современных автомобилях карбюратором управляет микроЭВМ, в которой никакой внешней памяти нет. Если программа и данные превысят наличную память микроЭВМ на 1 байт, то нужно будет переделывать всю систему. В обычных программных системах скорость счета обычно "разменивают" на больший объем памяти, здесь же такие приемы не проходят.

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

Взаимодействие с человеком. Некоторые встроенные системы не имеют никаких способов взаимодействия с человеком (например,система техобслуживания). Такие системы принято называть "глубоко встроенными системами" (deeply embedded systems). Другие же, наоборот, иногда требуют вмешательства человека-оператора. Это еще более усложняет ситуацию, поскольку для человека важно иметь удобный интерфейс и оперативное отображение текущего состояния всех технических элементов.

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

Инструментальная и целевая ЭВМ

Для обычных ЭВМ технология разработки ПО в последние годы была более или менее стандартизирована. Такие ее элементы как алгоритмические языки высокого уровня (АЯВУ) и компиляторы для них, текстовые и графические редакторы, различные средства поддержки коллективной разработки и т.п. используются повсеместно. Вряд ли кто-нибудь сегодня решится программировать в кодах ЭВМ без каких-либо инструментальных средств.

Теперь представим себе, что нам нужно запрограммировать контроллер карбюратора автомобиля, микропроцессор в мобильном телефоне или какое-то другое специализированное устройство. Наверняка там не будет традиционной ОС, многопользовательского режима, трансляторов и многого другого, к чему мы привыкли. Более того, из-за ограничений памяти, отсутствия обычных устройств ввода-вывода и коммерческих соображений (разовая, не массовая разработка!) все это и невозможно реализовать.

Будем действовать следующим образом.

Всю разработку осуществляем на АЯВУ на хорошо оснащенной ЭВМ, которую будем называть "инструментальной". Для получения кода на нужной "целевой" ЭВМ создаем транслятор с нашего АЯВУ, который работает на инструментальной ЭВМ, но в качестве результата выдает код целевой ЭВМ. Такой транслятор называется "кросс-транслятором".

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

Самую сложную, на моей памяти, схему отладки мы реализовали для военных заказчиков, которым нужно было разработать сложное ПО на Алголе 68 для управляющего вычислительного комплекса (УВК) "Самсон". В качестве инструментальной ЭВМ мы использовали ПЭВМ.

Сначала все программы транслировались в коды ПЭВМ и проверялись на имитационных моделях. Так была проверена правильность основных алгоритмов. Естественно, мы не могли проверить реактивность и другие временные параметры.

Затем все программы были оттранслированы кросс-транслятором в коды "Самсона" и были еще раз проверены на ПЭВМ, но с использованием интерпретатора системы команд УВК "Cамсон". Так мы получили размеры реальных объектных кодов, проверили правильность адресации и смогли подсчитать время исполнения всех фрагментов программы, не зависящих от внешних сигналов.

Наконец, на стенде, в котором несколько ПЭВМ и один "Самсон" были связаны в локальную сеть, мы получили возможность запускать программы непосредственно на "Самсоне", но с полным контролем со стороны ПЭВМ (остановка по команде, по адресу чтения и т.п.) "Самсон" в то время был всего один (это обычная ситуация, когда ПО и оборудование разрабатываются одновременно), а разработчиков – много; при этом каждый из них мог запускать программы со своего рабочего места.

Такая "трехступенчатая" схема отладки помогла разработать чрезвычайно важное ПО.