Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Надежность систем автоматизации

..pdf
Скачиваний:
19
Добавлен:
15.11.2022
Размер:
6.87 Mб
Скачать

10.2.Общие принципы контроля

идиагностирования цифровой аппаратуры ответственного применения

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

Используется так называемая самопроверка ЭВМ:

1. Проверка процессора – все команды методом «раскрутки» (за основу берется наиболее надежное ядро, которое постепенно увеличивается по мере проверки), а также отдельные узлы посредством определенных тестов.

2. Проверка ОЗУ – тесты «бегущий ноль», «бегущая единица», адрес ячейки и др.

3. Проверка ПЗУ – путем определения контрольной суммы, хранящейся в нем информации. Контрольная сумма также хранится в ПЗУ.

4. Проверка блоков ввода-вывода. Для этого в них вводится дополнительное оборудование.

5. Проверка межканального обмена в мажоритарной структуре – путем контроля передачи констант и циклограмм обмена каналов.

6. Проверка мажоритарных схем.

Кроме наличия трех каналов в каждом канале для наиболее важных вычислений используются дополнительно троированные ячейки памяти.

201

11.JTAG

11.1.Понятие о JTAG

JTAG (joint test action group) – специализированный ап-

паратный интерфейс, разработанный для тестирования цифровых процессоров (рис. 11.1) [2].

Рис. 11.1. JTAG (сокращение англ. joint test action group) – специализированный аппаратный интерфейс

JTAG стал повсеместно использоваться для отладки и программирования. На данный момент JTAG-интерфейс применяется при периферийном сканировании. Этот термин относится к тестированию печатных плат, с установленными на них процессорами, ПЛИС, флеш-микросхемами и т.д., на наличие в электроцепях коротких замыканий, непропаек, западаний на 0 или 1. Управление JTAG-интерфейсом описывается в BSDL-файле, который предоставляет разработчик. Порт тестирования (англ. test access port) представляет собой

202

четыре или пять выделенных выводов микросхемы: ТСK, TMS, TDI, TDO, ~TRS.

11.2. JTAG-порт микросхемы и ячейки периферийного сканирования

Функциональное назначение этих линий:

TDI (вход тестовых данных) – вход последовательных данных периферийного сканирования. Команды и данные вдвигаются в микросхему с этого вывода по переднему фронту сигнала TCK;

TDO (выход тестовых данных) – выход последовательных данных. Команды и данные выдвигаются из микросхемы с этого вывода по заднему фронту сигнала TCK;

TCK (вход тестового тактирования) тактирует работу встроенного автомата управления периферийным сканированием. Максимальная частота сканирования периферийных ячеек зависит от используемой аппаратной части и на данный момент ограничена 25–40 МГц;

TMS (вход управления тестированием) обеспечивает выбор режима тестирования.

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

Работа средств обеспечения интерфейса JTAG подчиняется сигналам автомата управления, встроенного в микро-

схему. Состояния автомата определяются сигналами TDI

иTMS порта тестирования. Определенное сочетание сигналов TMS и TCK обеспечивает ввод команды для автомата

иее исполнение.

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

203

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

204

12. ПОНЯТИЕ О НАДЕЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ

При расчете и обеспечении надежности СА необходимо учитывать не только надежность аппаратуры, но и программных средств (ПС). Имеются соответствующие модели надежности ПС, например модель Джелинского – Моранды [3]. Интенсивность отказов программных средств λПО может быть получена экспериментальным путем. Причем в отличие от аппаратуры ПС не «стареет», напротив, его интенсивность отказов со временем может снижаться в связи с внесением изменений после нахождения ошибок, совершенствованием алгоритмов и пр.

Тем не менее часто λПО рассчитывают по формуле

[17, 18]

λПО = αλАО,

где α – коэффициент интенсивности отказа ПС, принимающий значение в диапазоне 0,1–10,0; λАО – интенсивность отказов соответствующей аппаратуры.

Учитывают также и сбои ПС. Интенсивность сбоев АС (аппаратных) и ПС (программных) – λАС, λПС. Эти интенсивности определяются исходя из условия λАС (λПС) = βλАО (λПО),

где β = 102…103.

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

Большее значение придается контролю работы ПС.

205

12.1. Контроль работы ПС на этапе эксплуатации

На пользовательском уровне:

двойной (многократный) счет;

реверсивный контроль (по результатам восстанавливают исходные данные и сравнивают);

грубый повторный счет;

контроль времени выполнения программы;

метод контрольных функций (результат должен удовлетворять некоторым соотношениям);

контроль гладкости (резкие отклонения могут свидетельствовать об ошибке).

На системном уровне:

контроль хода программы;

контроль обращения к областям памяти (обращение

кнеиспользуемой или несуществующей области);

контроль недействительных кодов операций.

На функциональном уровне:

периодическое программное тестирование;

контрольные таймеры (при нормальной работе периодически запускается таймер, если он не запущен в определенном промежутке времени – ненорма);

контрольные процессоры, контролирующие основной процесс.

На логическом уровне:

контролирующие и корректирующие коды;

контроль дублированием, мажоритированием;

контроль по модулю.

12.2. Обеспечение надежности ПС на этапе проектирования

Внутренними источниками угроз надежности можно считать следующие дефекты программ:

206

системные ошибки при постановке целей и задач создания ПС;

алгоритмические ошибки;

ошибки программирования в текстах программ и описаниях данных.

Внешними дестабилизирующими факторами являются:

ошибки персонала в процессе эксплуатации ПС;

искажения в каналах телекоммуникации информации, поступающей от внешних источников;

сбои и отказы в аппаратуре вычислительных средств;

непредусмотренные изменения состава и конфигурации информационной системы.

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

логий:

проектирования;

разработки;

сопровождения;

документирования ПС.

Методы обеспечения надежности ПС можно разбить на четыре группы:

1.Предупреждение ошибок.

2.Обнаружение ошибок.

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

4.Обеспечение устойчивости к ошибкам – способность программного обеспечения продолжать функционирование даже при наличии ошибок.

В 2010 г. при выводе на орбиту были потеряны два спутника системы ГЛОНАС. Официальной причиной неудачного запуска была объявлена ошибка в документации – неверная формула расчета количества топлива, соответст-

207

венно, и программное обеспечение было разработано неправильно.

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

12.3. Надежность ПС – одна из составляющих качества ПС

Качество – совокупность характеристик объекта, относящихся к его способности удовлетворить установленные и предполагаемые потребности (определение этого понятия в соответствии со стандартом ISO 8402:1994).

ISO 9000 – серия международных стандартов ISO, регламентирующих контроль качества на предприятиях. Система стандартов разработана Международной организацией по стандартизации (ISO – international organization for standardization), которая основывалась на разработках Британского института стандартов BS 5750.

Вдействительности серия стандартов ISO 9000 объединяет три стандарта:

– ISO 9000:2005 «Системы контроля качества. Основные положения и словарь»;

– ISO 9001:2000 «Системы контроля качества. Требования»;

– ISO 9004:2000 «Системы контроля качества. Рекомендации по улучшению деятельности».

ВРФ действует ГОСТ 28195–89. В соответствии с ним устанавливается шесть показателей – факторов качества: надежность, корректность, удобство применения, эффективность, универсальность и сопровождаемость.

Эти факторы детализируются в совокупности более подробными критериями качества. Дальнейшая детализация

208

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

Имеется также ГОСТ 28806–90 «Качество программных средств. Термины и определения», где формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качест-

ва, приведенных в ГОСТ 28195–89.

Надежная программа должна обеспечивать:

низкую вероятность отказа в процессе функционирования в реальном времени;

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

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

Надежность функционирования программ является по-

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

Устойчивость зависит от уровня неустраненных дефектов и ошибок.

Восстанавливаемость характеризуется полнотой и дли-

тельностью восстановления функционирования программ в процессе перезапуска.

Меры повышения надежности проектируемого ПО

К административным мерам повышения надежности проектируемого ПО можно отнести следующие мероприятия:

– проведение обучения персонала, переподготовки;

– тщательное документирование всех изменений в структуре ПС;

209

назначение ответственных лиц за каждую доработ-

ку ПС;

текущий контроль качества и заключительный контроль качества;

обеспечение мониторинга качества (например, фиксирование ошибок, поступивших от пользователя);

введение внутренних стандартов (обычно содержат соглашения о именовании переменных в программном коде, наименовании файлов данных, процедур и функций);

организация отдела тестирования как самостоятельного подразделения;

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

ектируемого ПО относятся следующие мероприятия:

выбор стандарта качества и четкое следование ему на всех этапах;

единая среда разработки;

формализация проекта, использование формального языка спецификаций (например, UML);

тщательное тестирование ПО;

использование проверенной операционной системы

иязыка программирования.

12.4. Тестирование ПС

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

Дейкстра, 1970 г.

Общепринятая практика состоит в том, что после завершения разработки продукта и до передачи его заказчику независимой группой тестировщиков проводится тестирование ПО.

Эта практика часто выражается в виде отдельной фазы тестирования (в общем цикле разработки ПО), которая часто

210