Пример: система обслуживания телефонных станций TSPS фирмы «Белл»

Система TSPS фирмы «Белл» демонстрирует некоторые примеры методов исправления ошибок и обеспечения устойчивости. Система предназначена для обслуживания телефонной сети, поэтому на нее накладываются строгие требования в отношении постоянной готовности: суммарное время простоя системы из-за отказов не должно превышать двух часов за 40 лет. В TSPS полный выход системы из строя — серьезное событие, в то время как такие случайные сбои, как разрыв телефонной связи, вполне допустимы. Отметим, что во многих системах требования прямо противоположны. Например, в системе обработки банковских чеков выход системы из строя менее серьезен, чем ошибка в данных.

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

Телефонная сеть представлена таблицами в основной памяти, которые хранятся как множество связанных линейных списков. Например, каждый блок имеет свой тэг, последний блок определяется по двум признакам, и в поле состояния каждого блока в этом списке должно быть установлено значение «активно». Монитор (называемый в TSPS audit program) периодически просматривает списки. Если обнаруживается противоречие, например в поле СЛЕДУЮЩИЙ некоторого блока указан неправильный адрес (что обнаруживается по несоответствию тэга блока, находящегося по этому адресу), то список обрывается после последнего правильного блока и в каждом правильном блоке значение бита L (от английского слова lost — потеряно) устанавливается равным 1. Другая компонента монитора периодически просматривает последовательно блоки всех линий. Если бит L блока равен 0 (что значит, что он «потерян»), блок включается в список незанятых линий соответствующего типа. Эти действия могут привести к разрыву телефонной связи, но сохраняют работоспособность всей системы.

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

Механизм исправления ошибок в TSPS ежедневно исправляет довольно много ошибок. Установка TSPS после трех лет работы выполняет в среднем от 10 до 100 реальных исправлений в день и примерно раз в два месяца — автоматический повторный запуск.

6. Изоляция ошибок

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

• 1. Прикладная программа не должна иметь возможности непосредственно ссылаться на другую прикладную программу или данные в другой программе и изменять их.
• 2. Прикладная программа не должна иметь возможности непосредственно ссылаться на программы или данные операционной системы и изменять их. Связь между двумя программами (или программой и операционной системой) может быть разрешена только при условии использования четко определенных сопряжении и только в случае, когда обе программы дают согласие на эту связь.
• 3. Прикладные программы и их данные должны быть защищены от операционной системы до такой степени, чтобы ошибки в операционной системе не могли привести к случайному изменению прикладных программ или их данных.
• 4. Операционная система должна защищать все прикладные программы и данные от случайного их изменения операторами системы или обслуживающим персоналом.
• 5. Прикладные программы не должны иметь возможности ни остановить систему, ни вынудить ее. изменить другую прикладную программу или ее данные.
• 6. Когда прикладная программа обращается к операционной системе, должна проверяться допустимость всех параметров. Более того, прикладная программа не должна иметь возможности изменить эти параметры между моментами проверки и реального их использования операционной системой.
• 7. Никакие системные данные, непосредственно доступные прикладным программам, не должны влиять на функционирование операционной системы. Например, OS/360 хранит некоторые блоки, управляющие распределением памяти, в областях основной памяти, доступных прикладным программам. Ошибка в прикладной программе, вследствие которой содержимое этой памяти может быть случайно изменено, приводит в конце концов к сбою системы.
• 8. Прикладные программы не должны иметь возможности в обход операционной системы прямо использовать управляемые ею аппаратные ресурсы. Прикладные программы не должны прямо вызывать компоненты операционной системы, предназначенные для использования только ее подсистемами.
• 9. Компоненты операционной системы должны быть изолированы друг от друга так, чтобы ошибка в одной из них не привела к изменению других компонент или их данных.
• 10. Если операционная система обнаруживает ошибку в себе самой, она должна попытаться ограничить влияние этой ошибки одной прикладной программой и в крайнем случае прекратить выполнение только этой программы.
• 11. Операционная система должна давать прикладным программам возможность по требованию исправлять обнаруженные в них ошибки, а не безоговорочно прекращать их выполнение.

Реализация многих из этих принципов влияет на архитектуру лежащего в основе системы аппаратного обеспечения.

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