Волнообразный вид функции обусловлен: целесообразностью наработки ассемблерных наполнений операторов и функций языков высокого уровня; появлением новых нишь применения модулей.

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

.

Выражение описывает вид функции прогнозирования объема разработки С++ подобной среды программирования Q.

Где - стартовое время жизни модуля;

- функция Стъюдента;

k, m, n, d – нормирующие коэффициенты.

На рис. 16.3. приведен вид функции прогнозирования объема работ по разработке С – подобной языковой среды с учетом целесообразности начала и объема работ.

Функция прогнозирования для разработки с – подобной среды программирования

Рис. 16.3. Функция прогнозирования объема работ по разработке на С

Целесообразность создания на базе С++ объектов высокоуровнего языка класса языков описания сценариев определяется временем жизни модульного средства, объемом его распространения и, в первую очередь, стремлением потребителей к значительному по объему программированию силами технологов и других специалистов производств. Работы по созданию такой среды реально начинаются после наработки достаточно полного множества переносимых модулей на С++.

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

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

Тестирование в обеспечении надежности КС

Надежность информационных систем как свойство системы сохранять показатели назначения во времени в заданных пределах существенно зависит от качества и периодичности контроля. Для многих случаев вероятность правильного функционирования технического средства:

,

где - интервал времени после проведения (в момент времени ) цикла идеального контроля; - интенсивность неисправностей системы. Под «идеальным» понимается контроль, при котором условная вероятность обнаружения дефекта равна единице. В связи с тем, что вероятность надежной работы для систем в данном случае не зависит от предыстории эксплуатации системы и ее клонов, особенно важен контроль перед включением аппаратуры в рабочий режим, а для модулей с перестраиваемой архитектурой – при смене конфигурации решающей среды. Так как обнаруженный дефектный узел может быть исключен из рабочей конфигурации МСПА с сохранением работоспособности последней, можно реально говорить о повышении, наряду с надежностью, и живучести системы.

При современных требованиях к надежности работы МСПА выражение (1) может быть с погрешностью не более сотых долей процента аппроксимировано линейной зависимостью

.

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

,

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

.

Линейная аппроксимация и в данном случае дает достаточно хорошее приближение, например, для (k – коэффициент пропорциональности) погрешность аппроксимации при не превышает 1 %.

При отсутствии периодического тестирования

.

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

Введение тестирования позволяет повысить надежность работы системы, которая с учетом (3) и (5) может быть оценена по формуле

.

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

,

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

.

Коэффициент 0.91 подобран для m = 2.5, соотношения и . Погрешность аппроксимации не превысила в таком случае сотых долей процента.

Живучесть системы как возможность и реализуемость замены вышедших из строя узлов на не занятые в решении текущей задачи, может быть оценена через вероятность замены сомножителей в (8) с сохранением при этом работоспособности системы:

,

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

Верификация и диагностика архитектуры и схемных решений

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

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

Начиная со схемы верификации по Роту (фирма IBM) включая в себя схемы Ивенгелисти (фирма IBM), Маруяма (фирма Фудзицу) (рис.16.4…16.6), она приобрела черты сложной многомерной логической задачи, решаемой с учетом ограничений во времени, допустимой вероятности пропуска ошибки в решениях, используемых САПР в разработках схем и т. п.

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

Сегодня профессия тестировщика стала массовой.

Рис. 16.4. Укрупненная схема верификации по Роту

Рис. 16.5. Укрупненная схема верификации по Ивенгелисти

Рис. 16.6. Укрупненная схема верификации по Маруяма

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

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

Наиболее интересен для конкретной реализации в диагностике МСПА

D-алгоритм и его развитие (алгоритмы PODEM, 10-ти значный и др.). Тесты в данном случае генерируются алгоритмически и основываются на понятиях активизации путей, т.е. нахождения комбинаций входных переменных и состояний, при которых различия в выходных сигналах идентифицируют наличие неисправности. Локализация неисправности ведется через анализ D-кубов неисправностей, строящихся последовательностью правил выбора. Разумны и рациональны рекомендации, в первую очередь, для идентификации выбирать линии и элементы ближайшие к входным и выходным контактам.

Поддержка тестирования в программном обеспечении

Перечислим проработанные и принятые за базу основные принципы построения программного обеспечения для тестирования и самодиагностики КС ПОТКС:

• построение ПОТКС проводить, ориентируясь на удержание функциональных возможностей отладчиков профессиональных языков программирования высокого уровня;

• сохранить компонентный подход к построению ПОТКС;

• при тестировании разрешать построение новой конфигурации модулей;

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

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

• нарабатывать библиотеки имитации устройств подключаемых к КС, используя их как тестирующие вектора;

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

Рис. 16.7. Схема формирования файлов для комплексного тестирования рабочих программ и технических средств

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