Анализ на безопасность платы ТС2 ЦП ДЦ 'Минск'

  • Вид работы:
    Курсовая работа (т)
  • Предмет:
    Информатика, ВТ, телекоммуникации
  • Язык:
    Русский
    ,
    Формат файла:
    MS Word
    16,77 Кб
  • Опубликовано:
    2013-07-12
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

Анализ на безопасность платы ТС2 ЦП ДЦ 'Минск'

Оглавление


Оглавление          1

Введение    2

. Структура системы моделирования      4

.1 Основные компоненты для исследования цифровых схем        4

.2 Порядок работы с системой моделирования          10

. Разработка новых компонентов   16

.1 Структура компонентов моделирования цифровых схем        16

.2 Разработка интерфейсной части компонента         17

.3 Разработка алгоритмов функционирования компонентов       17

. Исследование на безопасность платы ТС ЦП ДЦ Минск  18

.1 Назначение и принципы функционирования платы ТС2          19

.2 Разработка модели   20

. Разработка функции загрузки реальных параметров       21

Приложение А    22

Приложение В    27

Приложение С    40

Введение

цифровая схема моделирование интерфейсный

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

Испытания на машинных моделях по сравнению с другими видами испытаний позволяют:

·   обеспечивать ускоренные испытания в машинном времени;

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

·   организовать процедуры верификации ППО; откорректировать списки опасных отказов; собрать статистические данные по влиянию сбоев на безопасность;

·   организовать вероятностные эксперименты с машинными моделями систем большой размерности.

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

Имитационные испытания на машинных моделях, делятся на три вида:

·   испытания технологических алгоритмов;

·   моделирование работы аппаратных средств при сбоях и отказах;

·   испытания имитационной модели программно-технических средств.

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

Необходимо сделать возможным загрузку реальных параметров элементов ТТЛ и КМОП, для того чтобы имитационные испытания были наиболее приближены к реальным процессам, происходящим в микроэлектронных элементах.

Также необходимо сделать анализ на безопасность платы ТС2 ЦП ДЦ «Минск» в данном приложении, что станет возможным по выполнении вышеперечисленных задач.

1. Структура системы моделирования

 

.1 Основные компоненты для исследования цифровых схем


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

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

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

Абстрактный базовый класс TGraphicControl1 (рисунок 1.2) обладает всеми перечисленными свойствами. В этом классе имеют реализацию только некоторые свойства (property), позволяющие устанавливать значения параметров элементов. Остальные свойства и методы присутствуют в описании только как полностью виртуальные функции (pure virtual functions), или «заглушки».

Для того, чтобы все элементы иерархии унаследовали способность отображать свое условное обозначение на форме, а также возможность взаимодействия с Инспектором Объектов (Object Inspector) C++ Builder, базовый абстрактный класс TGraphicControl1 нследуется от класса TGraphicControl. Этот класс является одним из ключевых базовых классов иерархии VCL (Visual Component Library). Графические компоненты, являющиеся наследниками класса TGraphicControl представляют собой видимые элементы управления, которые не могут принять фокус ввода, т.к. не являются оконными. Они не могут служить контейнерами для других элементов управления, т.е. не могут владеть другими компонентами. Графические компоненты обеспечивают отображение объектов без использования системных ресурсов, они требуют меньших «накладных расходов», нежели стандартные (находящиеся на вкладке Standard в C++ Builder) или адаптированные (наследники компонента TWinControl) компоненты. Таким образом, все элементы, являющиеся наследниками класса TGraphicControl1 получают возможность реагировать на сообщения Windows (такие как OnPaint, OnMouseMove) простым перекрытием соответствующих функций базового класса.

Отдельно от общей иерархии стоит компонент TExperimentManager (рисунок 1.2). Он является наследником одного из ключевых базовых классов иерархии VCL TWinControl. Использование в качестве родителя оконного компонента приведет к некоторому увеличению затрат ресурсов ЭВМ, так как компонентами данного типа используются системные ресурсы. Но такие меры оправданы, так как оконные (адаптированные) компоненты способны принимать фокус ввода и могут служить контейнерами, т.е. являться родителями других элементов управления. А это необходимо для взаимодействия с пользователем.

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

·   чтение файла сценария посредством взаимодействия с объектом класса TTestFile (рисунок 1.2);

·   введение неисправностей в элементы схемы;

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

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

·   протоколирование результатов работы модели схемы посредством взаимодействия с объектом вспомогательного класса TLogFile (рисунок 1.2).

Блок управления экспериментом содержит такие компоненты управления, как TEditBox, TLabel и TButton (рисунок 1.1). Эти компоненты управления позволяют изменять интервал дискретизации по времени, а также количество циклов тестирования.

Рисунок 1.1 - Интерфейс компонента «Блок управления экспериментом»

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

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

(1.1)

где N - число тактов;

tдискрет. - длительность такта (величина интервала дискретизации).

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

Также не является наследником основного базового класса иерархии элементов компонент TConnection. Этот элемент моделирует работу проводника, соединителя в электрической схеме. Он не должен обладать свойствами микроэлектронного элемента. Работа компонента заключается в моментальной передаче значения напряжения, поступившего на его вход. Рассмотрим описание такого компонента:

Вспомогательные сервисные классы (рисунок 1.2) служат для взаимодействия ПО с файловой системой (компоненты TLogFile и TSection), синтаксического разбора файлов конфигурации (компонент TatfParser), а также для упрощения работы со сложными структурами времени (TTestTimer). Эти классы не входят в общую иерархию элементов и не имеют родителей.

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

Класс управления работой программного счетчика времени с момента начала тестирования TTestTimer позволяет производить со структурами времени следующие операции:

·   суммирование двух переменных типа TTestTimer или TTestTimer и long;

·   вычитание двух переменных типа TTestTimer или TTestTimer и long;

·   увеличение времени на 1 пикосекунду;

·   сравнение моментов времени;

·   суммирование с целым числом, которое представляет собой время в пикосекундах.

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

Для работы с файлом протокола используются классы TLogFile и TSection. Формат файла повторяет формат стандартного ini-файла Windows. Необходимость создания собственного класса для работы с файлами в таком формате обусловлена ограничением длины стандартного файла величиной в 64 килобайта, что недопустимо, так как при длительном тестировании файлы протоколов могут быть значительно большего размера. Кроме того, тестирование показало, что специальный класс TLogFile обеспечивает гораздо более быстрый доступ к файлу протокола, чем это позволяют стандартные функции для работы с ini-файлами. Такой эффект в первую очередь обусловлен применением гибкой буферизации записи на диск и промежуточным размещением секций в различных файлах на диске.

Синтаксический анализ файла сценария осуществляется объектами класса TatfParser. Взаимодействие с объектами других классов осуществляется посредством одной функции Process():

void __fastcall Process(TGraphicControl1*,char*);

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

Создание объектов классов специального назначения и все последующие обращения к этим объектам производятся центральным компонентом библиотеки - «Блок управления экспериментом» (класс TExperimentManager).

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

Рисунок 1.2 - Иерархия классов системы моделирования микроэлектронных устройств.

 

1.2 Порядок работы с системой моделирования


Использование программного обеспечения для создания и проведения испытаний имитационных машинных моделей состоит из следующих этапов:

·   установка библиотеки компонентов;

·   создание модели схемы;

·   написание файла сценария и параметров тестирования;

·   анализ результатов работы модели.

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

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

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

Кратко рассмотрим этапы использования программного обеспечения:

Для правильной установки библиотеки необходимо произвести следующие операции (строго в той последовательности, в которой они изложены ниже):

1 удалить предыдущую версию библиотеки компонентов (если таковая была установлена) из C++ Builder IDE (Integrated Development Environment);

2 удалить скомпилированный ранее модуль Elements.bpl с жесткого диска;

3 удостовериться, что в настройках проекта (Project\Options\Linker) выключена опция линкера «Use dynamic RTL»;

4 открыть модуль Elements.bpk (меню File\Open);

5 использовать пункты меню «Project\Make...» или «Project\Build...» для компиляции модуля Elements.bpk;

6 поместить откомпилированный файл Elements.bpl в каталог, который доступен через переменную окружения %PATH% операционной системы;

7 после компиляции, необходимо установить модули времени проектирования (design-time packages) в окружении C++ Builder IDE. Это делается в диалоге «Packages», вызываемом при выборе пункта меню «Component\Install packages...», затем надо нажать кнопку «Add...», указать расположение файла Elements.bpl и нажать «OK» для интеграции модуля в IDE.

После установки библиотеки, компоненты, которые она содержит, можно будет использовать таким же образом, как и стандартные компоненты VCL. При необходимости расширения возможностей компонентов или добавления в библиотеку новых моделей микроэлектронных элементов, достаточно изменить исходный текст модуля, перекомпилировать проект (Elements.bpk) и выполнить пункт 6 описанного выше процесса инсталляции библиотеки.

Библиотека компонентов интегрируется в среду Borland C++ Builder. Поэтому для успешной работы в системе необходимо установить C++ Builder версии 4.0 или выше. Для создания новой схемы, необходимо в первую очередь создать новый проект (File\New Project) в C++ Builder, после чего размещать компоненты библиотеки на главной форме этого проекта.

Похожие работы на - Анализ на безопасность платы ТС2 ЦП ДЦ 'Минск'

 

Не нашли материал для своей работы?
Поможем написать уникальную работу
Без плагиата!