Читать онлайн «Очерки истории отечественной программной инженерии в 1940-е – 80-е годы». Страница 47

5.3. Методы оценивания и обеспечения корректности и надежности программных продуктов – 1975-е годы

В конце 1970-х годов было установлено отсутствие тождественности между понятиями правильной и надежной программы реального времени [17]. Понятие правильной, или корректной, программы может рассматриваться статически, вне временного функционирования. Корректная программа должна была обеспечивать выходные данные, соответствующие эталонным требованиям, в области изменения исходных данных заданных техническим заданием или спецификацией. Степень правильности программы можно характеризовать вероятностью попадания в область исходных данных, которая предусматривалась требованиями спецификации, но не была проверена при тестировании и испытаниях. В этой области исходных данных не гарантируются эталонные результаты из-за возможных ошибок в программе, не обнаруженных при отладке. При этом корректность программы не определена вне области данных, заданной спецификацией, и не зависит от динамики функционирования программ в реальном времени. Таким образом, некорректность исполнения программы определяется совмещением событий: попаданием исходных данных в область, заданную требованиями спецификации, но не проверенную при тестировании и испытаниях и наличием ошибки в программе при обработке таких данных.

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

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

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

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

Так как в программах нет необходимости «ремонта» компонентов с участием человека, то нужно добиваться высокой автоматизации программного восстановления функционирования. Автоматизируя процесс и сокращая время восстановления, можно преобразовать отказы в сбои и тем самым улучшить показатели надежности функционирования системы в реальном времени. Для решения этой задачи в комплексе программ должны быть средства, позволяющие [17]:

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

• диагностировать обнаруженные искажения;

• вырабатывать решения и выбирать методы и средства оперативного восстановления;

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

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

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

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

При этом не обязательно сразу устанавливать причины искажений, главная задача сводится к максимально быстрому восстановлению нормального функционирования и ограничению последствий проявления дефектов. Временная и программная избыточность комплекса программ состоит в использовании некоторой части производительности и памяти ЭВМ для оперативного контроля исполнения программ и восстановления (рестарта) вычислительного процесса. Величина избыточности зависит от требований к надежности и безопасности функционирования систем обработки информации и обычно должна находиться в пределах от 5 – 10 % ресурсов однопроцессорной ЭВМ или до трех, четырехкратного дублирования отдельной машины в мажоритарных вычислительных комплексах.

В 1970-е – 80-е годы дефекты и ошибки в сложных комплексах программ стратегических ракет неоднократно приводили к их гибели с огромным ущербом. Резко обострилась проблема оценивания и повышения безопасности применения мобильных и бортовых программных продуктов. Единичные и непредсказуемые ситуации и их катастрофические последствия, требовали практически полного исключения, и отличали от дефектов в аппаратуре, надежность и безопасность которой можно рассчитывать аналитически. Необходимо было создавать систему защитных барьеров и самоконтроля исполнения программ для обеспечения гарантированной работоспособности и безопасности применения сложных систем управления на базе программных продуктов.

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