Формирование интегрированной информационной среды поддержки проектирования радиоэлектронной аппаратуры

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

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

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

Известным способом разрешения недостатков поливендорной среды является объединение различных информационных, программных и аппаратных средств поддержки процессов проектирования в единый комплекс информационно-программных решений и формирование на его основе единого информационного пространства [4, 5]. Информационное взаимодействие по такому принципу должно быть поддержано автоматизированными информационными системами сбора, обработки и анализа проектной информации, представленной в виде различных электронных конструкторских документов. Данный подход уже на ранних этапах проектирования обеспечивает формализацию методов и протоколов взаимодействия между аппаратными и программными средствами различных производителей, что существенно повышает эффективность обработки информации и способствует быстрому принятию проектных решений.

Постановка задачи

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

Формирование ЕИП или интегрированной информационной среды невозможно без разработки математической модели электронного конструкторского документа (ЭКД) и формализации взаимодействия между программно-аппаратными средствами проектирования на всех этапах проектного цикла (ПЦ). Формальное описание ЭКД должно включать в себя модели структуры и динамики процессов жизненного цикла (ЖЦ) ЭКД, описывающие, соответственно, структурную организацию ЭКД, и переходы по стадиям жизненного цикла документов (состояния ЭКД). Таким образом, при формировании ЕИП следует:

• •    формализовать описание ЭКД в виде единой математической модели, сочетающей в себе представление электронного конструкторского документа в рамках ЕИП с точки зрения его структуры и поведения;

• •    разработать требования к единому формату ЭКД, обеспечивающему эффективный обмен данными между средствами проектирования в ходе ПЦ;

• •    предложить методы и средства для интеграции программно-аппаратных комплексов проектирования в единую информационную среду с использованием единого формата ЭКД.

Стоит отметить, что уже известные решения в области организации ЕИП успешно применяются при создании безлюдных гибких производственных систем в различных областях машиностроения, в том числе с использованием виртуальных автоматизированных систем управления производством, но единых, хорошо апробированных подходов, методов и средств, полностью удовлетворяющих потребности проектных организаций при разработке и мелкосерийном производстве сложной радиоэлектронной аппаратуры, пока нет [6–9].

Формализация структуры электронного конструкторского документа в рамках единого информационного пространства

Прежде чем перейти непосредственно к рассмотрению единой модели представления данных об изделии и структуры PDM -системы, необходимо кратко обрисовать маршрут проектирования СБИС класса «Система на кристалле». Весь цикл проектирования можно представить в виде совокупности пяти основных этапов [10, 11]:

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

• 2.    Функциональное проектирование - разработка и верификация синтезируемой RTL -модели ( Register Transfer Level ) на уровне регистровых передач.

• 3.    Логическое проектирование – разработка логической схемы СнК.

• 4.    Топологическое проектирование – разработка и верификация топологии СБИС.

• 5.    Этап верификации и подготовки к производству.

На этапе системного проектирования разрабатывается поведенческая модель СнК и определяется состав СФ-блоков. Исполняемые спецификации представляются в определенном формате на языках С, C++, Verilog и VHDL .

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

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

На основе алгоритма работы СнК разрабатывается поведенческая модель системы на уровне СФ-блоков в виде блок-схемы, отражающей принцип взаимодействия СФ-блоков в составе СнК и включающей их основные параметры. Для верификации поведенческой модели создают – 296 – проект тестового окружения (Testbench). Он содержит в себе тестовые последовательности, генераторы входных сигналов и средства отображения выходной информации. На основе тестового окружения разрабатываются последовательности для верификации проекта на нижних уровнях проектирования, а также для функционального тестирования опытных образцов. После этого проводят верификацию поведенческой модели путем компьютерного моделирования с помощью специальных программных средств.

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

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

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

Концептуальная модельединого информационного пространства

Рассмотрим концептуальную модель ЕИП, приведенную на рис. 1. Модель ЕИП (поз. 1) включает следующие основные составляющие:

• •    система управления данными об изделии ( PDM -система, поз. 2) – информационная система, реализующая совокупность математических моделей ПЦ, обеспечивающая единый обменный формат ЭКД и предоставляющая платформу для информационного взаимодействия между поставщиками и потребителями информации;

• •    участники проектного цикла (поз. 3) - поставщики и потребители информации;

• •    аппаратные источники ЭКД (поз. 4) – стационарные и портативные рабочие станции, измерительное оборудование, отладочные средства различного типа;

• •    программные источники ЭКД (поз. 5) – развернутые на базе аппаратных источников системы автоматизированного проектирования (САПР), средства имитационного моделирования.

Рис. 1. Концептуальная модель ЕИП

Fig. 1. The Unified Information Space (UIS) conceptual model

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

Для формализации структуры ЭКД применим аппарат предметно-ориентированных онтологий и соответствующие разделы теории множеств [10–12]. Модель структуры ЭКД для такого случая определим следующим образом (1):

O = (С,I,E,L,Fext,Fmd,Fs,F^ , где C - набор категорий (классов объектов, понятий) ЕИП; I - набор информационных ресурсов (ЭКД), которые описываются различными категориями; E – единый обменный формат ЭКД, который позволяет формально описать все виды разнородных информационных ресурсов; L - набор внешних форматов представления ЭКД в ЕИП; Fext(L)) ^ E - функция преобразования ЭКД из внешних форматов в единый формат; Fmd(E) ^ I - функция преобразования ЭКД из единого формата в набор информационных ресурсов; Fs(I) ^ I - функция поиска требуемых информационных ресурсов (I), удовлетворяющих заданным поисковым критериям (It); Fexc(I) ^ I - функция информационного обмена между узлами ЕИП.

Электронный конструкторский документ ( I ) как информационный ресурс можно представить в виде кортежа (2):

I={ p, с, v, d, S, F, f, fm), где p = {p} - множество атрибутов документа, i = 1 - i, i - количество типов атрибутов в информационном ресурсе; c = {cj} - множество категорий документов, j = 1 - j, j - количество типов категорий, к которым может принадлежать информационный ресурс; v = {vk} - множество значений атрибутов, при этом V = {vk | vk - описание к-го значения атрибута, к = 1 - n, n - количество значений атрибутов в информационном ресурсе}; d = {dm} - множество прав доступа к документу, при этом D = {dm | dm - описание m-го права доступа некоторого пользователя -чтения, записи, удаления, передачи; m = 1 - m, m - количество определенных прав доступа}; S – набор настроек синхронизации, где каждая настройка определяет достаточные данные для осуществления информационного обмена, т. е. для выполнения функции Fexc(Ti) ^ Ij, при этом exc            j

S = { s i | s i - описание настройки синхронизации с i -м узлом ЕИП, i = 1 - к , к - количество узлов, с которыми синхронизируется информационный ресурс}; F – набор прикрепленных файлов, при этом г = { f i | f - описание i -го файла, i = 1 - l , l - количество прикрепленных к информационному ресурсу файлов}; f = {f h } - множество типов файлов, h = 1 - h , h - количество типов файлов, ассоциированных с информационным ресурсом; f m = { m_p} - множество атрибутов файлов, p = 1 - p , p - количество значений атрибутов файлов, ассоциированных с информационным ресурсом.

Все создаваемые, модифицируемые и передаваемые в процессе проектирования радиоэлектронной аппаратуры электронные конструкторские документы можно разделить на пять основных категорий ( v k ):

• •    v 1 - цифровая модель (модель в формате MATLAB / Simulink );

• •    v ₂ - исходный код (описание устройства на языке VHDL );

• •    v ₃ - отчет (отчет о верификации);

• •    v ₄ - текстовый документ (текст спецификации);

• •    v 5 - электронный документ свободной формы (документы, не подпадающие под вышеперечисленные типы).

Документы категорий v ₂, v ₃ и v ₄ относятся к текстовым электронным документами, v 1 и v ₅ – к нетекстовым. Каждой категории соответствует свой тип файлов ( f_h ): цифровая модель ( f ), исходный код ( f ), отчет ( f ), текстовый документ ( f 4 ), электронный документ свободной формы (f ₃.

В терминах предметно-ориентированной онтологии информационный ресурс состоит из реквизитной части (соответствует области метаданных ЭКД, определяется параметрами p , c , v , d , S ) и содержательной части (параметры F , ft , f_m ). Атрибуты различных типов файлов (f_m ) содержательной части в целом аналогичны (имя, размер и тип файла в терминах ПЦ и т. д.). Любой атрибут может заполняться пользователем в процессе работы с системой вручную путем выбора из списка доступных значений атрибута или автоматически при загрузке соответствующего файла в хранилище с преобразованием в единый формат.

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

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

Динамическая модель электронного конструкторского документа

Для полноты формализованного представления следует рассмотреть модель, описывающую особенности поведения ЭКД как некоторого динамического объекта. Для этого целесообразно представить модель переходов между стадиями жизненного цикла ЭКД в виде конечного автомата (КА) Мили (3):

• 5 = Q , D , V , W , N о , X , Y , Z ).

Описание конечного автомата включает в себя следующие элементы:

• •    Q = { q в }, где в = 1 ^ в’ — множество сигналов на изменение стадии ЖЦ ЭКД, поступающих в ЕИП на данном этапе ПЦ (входной алфавит);

• •    D = { d _х}, где X = 1 ^ X’ - множество ответных реакций на изменение стадии ЖЦ ЭКД на данном этапе ПЦ (выходной алфавит);

• •    V = { v _Y}, где у = 1 ^ у’ - множество состояний ЭКД (алфавит состояний);

• •    W = Q ^х D ^х V ^х V — множество действий, совершаемых над ЭКД, где четверка ( q р , d _х v _y+1 , v _Y) означает, что документ по запросу q р с ответом d _х перешел из состояния v _Y в состояние v γ+1 ;

• •    N 0 = {0, 1, 2 ...} - множество значений номеров этапов ЖЦ ЭКД;

• •    X - множество функций x : N 0 ^ Q , задающих все возможные последовательности запросов к ЕИП в ходе ЖЦ ЭКД;

• •    Y - множество функций y : N 0 ^ D , задающих все возможные последовательности ответов ЕИП по запросам (функция выходов);

• •    Z - множество функций z : N 0 ^ V, задающих все возможные последовательности состояний к ЕИП в ходе ЖЦ ЭКД (функция переходов).

Для каждого документа, формируемого в ходе ПЦ, можно выделить последовательность стадий его собственного ЖЦ, что отражается в свойствах документа как «Стадия ЖЦ документа» (алфавит состояний КА, табл. 1).

Рассмотрим логическую последовательность выполнения процессов стадий жизненного цикла ЭКД в ЕИП (переходов конечного автомата S ):

• 1.    До начала проектирования документ находится в стадии ЖЦ «Новый».

• 2.    При инициализации процесса проектирования документ переходит в стадию ЖЦ «В разработке».

• 3.    Для предоставления общего доступа к документу его следует опубликовать в PDM -системе, при этом стадия жизненного цикла документа меняется на «Опублико-ван».

• 4.    В случае изменения документ переходит в стадию ЖЦ «Внесение изменений в документ» и становится недоступным на время выполнения работ стадии.

• 5.    После внесения изменений документ переходит в стадию ЖЦ «Утверждение нового документа».

• 6.    При завершении процесса утверждения нового документа происходит его переход в стадию ЖЦ «Согласование документа».

• 7.    В случае успешного согласования документа объявляется окончание его разработки и стадия жизненного цикла изменяется на «Выпуск документа».

• 8.    Если документ не прошел согласование, то необходимо внести в него изменения. Для этого создается локальная копия изменяемого документа (стадия ЖЦ «Создание локальной копии»), затем вносятся изменения в локальную копию документа (стадия ЖЦ «Внесение изменений в новую версию»). После внесения всех необходимых изменений документ переходит в стадию ЖЦ «Утверждение новой версии документа» и передается на согласование.

• 9.    Если документ уже не актуален, то он выводится из проектного цикла и переходит в стадию ЖЦ «Аннулирование документа».

• 10.    Если документ не участвует в этапе проектного цикла, то переходит в стадию ЖЦ «Документ не активен».

Таблица 1. Стадии жизненного цикла ЭКД

Table. 1. Life cycle stages of the Electronic Design Document (EDD)

Обозначение	Стадия жизненного цикла
c 1	Новый
c 2	В разработке
c 3	Опубликован
c 4	Внесение изменений в документ
c 5	Утверждение нового документа
c 6	Согласование документа
c 7	Создание локальной копии документа
c 8	Внесение изменений в новую версию документа
c 9	Утверждение новой версии документа
c 10	Выпуск документа
c 11	Аннулирование документа
c 12	Документ не активен

Набор операций по изменению стадий ЖЦ документа определен как входной алфавит автомата Мили и представлен в табл. 2.

Представим стадии ЖЦ ЭКД в виде состояний и функций перехода конечного автомата Мили. Описание функций перехода по стадиям ЖЦ ЭКД приведено в табл. 3.

Связав вершины представления конечного автомата дугами в направлении движения от начальной вершины к конечной, согласно табл. 2 и 3, получим модель изменений стадий ЖЦ ЭКД в ЕИП в виде ориентированного графа (рис. 2).

Инициирующим действием начала работ по ЖЦ конкретного ЭКД является управляющее воздействие как изменение статуса управляемого документа. Признак завершения конкретного

Таблица 2. Операции перехода по стадиям ЖЦ документа

Table 2. Transition operations in the life cycle stages of a document

Стадия ЖЦ документа	Операция перехода в стадию ЖЦ
	Название	Обозначение
1. Новый	Создать	x 1
2. Опубликован	Опубликовать	x 2
3. Внесение изменений в документ / Внесение изменений в новую версию документа	Изменить	x 3
4. Утверждение нового документа / Утверждение новой версии документа	Утвердить	x 4
5. Согласование документа	Согласовать	x 5
6. Создание локальной копии документа	Копировать	x 6
7. Выпуск документа	Выпустить	x 7
8. Аннулирование документа	Аннулировать	x 8
9. Документ не активен	Вывести	x 9

Таблица 3. Функции перехода по стадиям ЖЦ документа

Table 3. Transition functions in the life cycle stages of a document

Стадия жизненного цикла документа Состояние Функция перехода в состояние 1. Новый c1 – 2. В разработке c2 x1 = f (c1) – создать 3. Опубликован c3 x2 = f (c2) – опубликовать 4. Внесение изменений в документ c4 x3 = f (c3) – изменить 5. Утверждение нового документа c5 x4 = f (c4) – утвердить 6. Согласование документа c6 x5 = f (c5) – согласовать 7. Создание локальной копии c7 x6 = f (c6) – копировать 8. Изменение новой версии c8 x3 = f (c7) – выпустить 9. Утверждение новой версии c9 x4 = f (c8) – утвердить 10. Выпуск документа c10 x7 = f (c9) – выпустить 11. Аннулирование документа c11 x8 = f (c2) – аннулировать 12. Документ не активен c12 x9 = f (c2) – вывести этапа ЖЦ ЭКД – смена атрибута статуса управляемого документа. Понятие статуса документа трактуется как совокупность атрибутов, однозначно определяющих фазу ЖЦ конкретного документа в рамках моделируемого этапа ПЦ. Условие завершения ЖЦ ЭКД – достижение им стадии c10 «Выпущен» или с11 «Аннулирован».

Для имитационного моделирования динамики изменения стадий ЖЦ ЭКД используем среду MATLAB с подключенным пакетом Stateflow . Разработанная имитационная модель включает в себя собственно модель конченого автомата в виде ориентированного графа (рис. 3) и генераторы случайных чисел, определяющие статус документа:

• •    активен, не нуждается во внесении изменений (0);

Рис. 2. Модель динамики изменений стадий жизненного цикла ЭКД в ЕИП в виде ориентированного графа

Fig. 2. The model of the change dynamics of the EDD life cycle stages in the UIS in the form of an oriented graph

• •    активен, нуждается во внесении изменений (1);

• •    не активен (2);

• •    аннулирован (3).

Имитационная модель КА представлена тремя отдельными циклами обработки документа (рис. 3):

• 1)    обработка без внесения изменений (поз. 1);

• 2)    обработка с внесением изменений (поз. 2);

• 3)    вывод из обращения (поз. 3).

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

На рис. 4 показана форма отображения динамики выполнения процессов стадий жизненного цикла ЭКД в ходе моделирования в пакете Stateflow . Так, в приведенном случае активный ЭКД находится в стадии ЖЦ c ₂ «В разработке», при этом не известно, будут в него внесены изменения или нет. Текущая стадия документа в ходе моделирования выделена жирной линией. На рис. 5 активный ЭКД находится в стадии ЖЦ c ₉ «Утверждение», при этом в документ уже внесены изменения и в данной стадии выполняется утверждение новой версии документа.

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

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

В качестве прикладной области применения предложенных методов и средств организации электронного документооборота и единого информационного пространства рассмотрим интегра- – 303 –

Рис. 3. Имитационная модель динамики изменения стадий ЖЦ ЭКД

Fig. 3. The simulation model of the dynamics of the EDD life cycle stages

Рис. 4. Отображение стадии ЖЦ ЭКД «В разработке»

Рис. 5. Отображение стадии ЖЦ ЭКД «Утверждение»

Fig. 4. Display of the EDD life cycle stage “Development”

Fig. 5. Display of the EDD life cycle stage “Approval”

цию программных и аппаратных средств, используемых при проектировании цифровых приемников навигационных спутниковых сигналов (ГНСС-приемников) с измерением углов пространственной ориентации подвижных объектов (углов Эйлера). Такого рода устройства предназначены для работы с навигационными сигналами (НС) от двух навигационных космических аппаратов (НКА), реализуются на базе заказных или полузаказных интегральных схем, базовых матричных кристаллов (БМК) или программируемых логических интегральных схем (ПЛИС).

С точки зрения организации процесса проектирования разрабатываемый угломерный ГНСС-приемник можно представить в виде двух составляющих:

• •    программный имитатор сигналов от НКА (рис. 6, поз. 1);

• •    структурные единицы ГНСС-приемника (рис. 6, поз. 2).

Разрабатываемый ГНСС-приемник включает в себя составляющие [16, 17]:

• •    Г ! - блок генерации информационной и частотной составляющей НС НКА 1;

• • Г^- блок генерации информационной и частотной составляющей НС НКА 2;

• •    КА ! - блок имитатора генерации и усиления НС на НКА 1;

• •    КА₂ - блок имитатора генерации и усиления НС на НКА 2;

• •    СФ₁ - блок ввода фазового сдвига НС от НКА 1;

• •    СФ₂ - блок ввода фазового сдвига НС от НКА 2;

• •    С₁ - селектор НКА;

• •    П _L1₁ - приемник НС L 1;

• •    П_ L 2 1 ^- приемник НС L 2;

• •    РН₁ - блок разрешения фазовой неоднозначности НС с использованием двухчастотного режима;

• •    Ф₁ - блок вычисления фазового сдвига НС;

• •    УО₁ - блок разрешения системы уравнений определения угловой ориентации объекта (углов Эйлера) по величине фазового сдвига НС.

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

Блок-схема этапа системного проектирования угломерного ГНСС-приемника представлена на рис. 7. Разработка СнК на этапе системного проектирования начинается с анализа требований, а также разработки спецификации системы (рис. 7, поз. 1.1). При этом определяются основные эксплуатационно-технические свойства СнК, такие как требуемое быстродействие и допустимая потребляемая мощность. Алгоритм работы СнК на уровне математического описания разрабатывается на основе спецификации системы (рис. 7, поз. 1.2). На данном этапе произ-

Рис. 6. Структурная схема угломерного ГНСС-приемника

Fig. 6. The block diagram of the angular Global Navigation Satellite System (GNSS) receiver водится математическое моделирование разработанных алгоритмов функционирования СнК, оцениваются требуемое быстродействие, разрядность и форматы представления внутренних данных.

На основе алгоритма работы разрабатывается поведенческая модель, отражающая общие принципы функционирования СнК (рис. 7, поз. 1.3). Для верификации поведенческой модели разрабатывают поведенческую модель тестового окружения (рис. 7, поз. 1.4). Она включает в себя тестовые последовательности, генераторы входных сигналов и средства отображения выходной информации. На основе разработанной модели впоследствии проектируются и реализуются тестовые последовательности для верификации проекта на нижних уровнях проектирования, а также для тестирования опытных образцов. После этого проводят верификацию поведенческой модели системы (рис. 7, поз. 1.5).

На основе поведенческой модели системы разрабатывается структурная модель системы на уровне функциональных блоков (рис. 7, поз. 1.6), отражающая принципы взаимодействия отдельных блоков в составе СнК и включающая их основные параметры.

Структурная модель системы позволяет выполнить генерацию описания блоков разрабатываемой СнК на уровне регистровых передач с использованием языков описания аппаратуры ( HDL -описания, рис. 7, поз. 1.7), аналогично генерируется HDL -описание тестового окру-

Разработка алгоритма

Разработка поведенческой моле;

системы

Ратработка 1юне,кнческой модели тестово!о окружения

* Верификация поведенческой модели

Генерация HDL-описания блоков

СИС1СМЫ

Генерация HDL-опнслнмя тестошмо окружения

Про1раммно-аппарзтиоя верификация структурной модели

Рис. 7. Блок-схема этапа системного проектирования ГНСС-приемника

Fig. 7. The block diagram of the GNSS receiver system design stage жения (рис. 7, поз. 1.8). Полученное HDL-описание структурной модели системы проходит процедуру программно-аппаратной верификации с использованием аппаратных отладочных средств на базе ПЛИС (рис. 7, поз. 1.9) совместно с программным тестовым окружением, разработанным на этапах 1.4 и 1.8.

Электронные конструкторские документы, создаваемые в ходе этапа системного проектирования, могут быть представлены в различных форматах файлов в зависимости от используемого на конкретном этапе программного обеспечения (табл. 4), в частности:

• •    . doc , . docx – текстовый процессор MS Word ;

• •    . xls , . xlsx – табличный процессор MS Excel ;

• •    . ns , . msw – система компьютерной алгебры Maple ;

• •    . eap – среда проектирования программного обеспечения Enterprise Architect ;

• •    . m , . slx , . html , . xml , . vhd – среда технических вычислений и моделирования MATLAB / Simulink ;

• •    . vhd , . xise , . ucf , . bit – системы автоматизированного проектирования Xilinx ISE Design Suite и Vivado ;

• •    . vi – система моделирования и сбора данных LabVIEW ;

• •    . mpf – среда моделирования и отладки HDL -кода Mentor Graphics ModelSim .

Таблица 4. Программные средства, которые используются на этапах системного проектирования ГНСС-приемника и порождаемые ими форматы ЭКД

Table 4. Software that is used at the stages of the GNSS receiver system design and EDD formats generated by them

Номер этапа	Используемое программное обеспечение	Форматы документов	Типы документов
1.1	MS Word	. doc , . docx	v 3 , v 4
1.2	MATLAB , Maple , Enterprise Architect	. m , . ns , . msw , . eap	v 2 , v 5
1.3	MATLAB , Simulink : Communications System Toolbox ; DSP System Toolbox	. m , . slx	v 1 , v 2
1.4
1.5	MATLAB , Simulink : Simulink Control Design ; Simulink Design Optimization ; Simulink Design Verifier	. html	v 3
1.6	MATLAB , Simulink : HDL Coder ; Communications System Toolbox HDL Support	. m , . slx	v 1 , v 2
1.7	MATLAB , Simulink : HDL Workflow Advisor ; HDL Code Generation	. m , . slx , . vhd , . html	v 1 , v 2 , v 3 , v 4
1.8
1.9	LabVIEW , ISE Design Suite , Vivado , ModelSim , MATLAB , Simulink : HDL Verifier ; Instrument Control Toolbox ; MS Excel	.vhd, .xise, .ucf, .bit, .vi, .mpf, .html, .xls, .xlsx	v 2 , v 3 , v 4 , v 4

Также у каждого ЭКД имеется статус происхождения: «извне», «создается», «создается/ передается». Каждый из создаваемых ЭКД относится к одной из категорий документов v_k .

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

Ядром автоматизированного программно-управляемого стенда является персональная ЭВМ с развернутыми на ней программными средствами проектирования и разработки (рис. 8, поз. 6), включающими в себя прикладное программное обеспечение (рис. 8, поз. 7) и программный модуль преобразователя в единый формат ЭКД (рис. 8, поз. 8), через который осуществляется взаимодействие с PDM -системой (рис. 8, поз. 11). Аппаратные средства разработки включают в себя измерительное оборудование (генераторы сигналов, осциллографы, анализаторы спектра, рис. 8, поз. 1) и отладочные средства (отладочные платы и комплекты разработчика, рис. 8, поз. 9).

Взаимодействие между программными средствами и измерительным оборудованием осуществляется посредством программной архитектуры виртуальных устройств ( VISA , рис. 8, поз. 5), использующей стандартизированный интерфейс ввода-вывода тестирования и проведения измерений для управления приборами, поддерживающими интерфейсы IEEE -488 (GPIB, рис. 8, поз. 2), USB 2.0 (рис. 8, поз. 3) и LAN (рис. 8, поз. 4) измерительных устройств. Взаимодействие между отладочными средствами и программным обеспечением осуществляется посредством шины ввода-вывода PCI (рис. 8, поз. 10).

Со стороны программных средств за обеспечение взаимодействия отвечают:

• •    с измерительным оборудованием - встроенные модули среды LabVIEW и модуль расширения Instrument Control Toolbox среды MATLAB / Simulink ;

Рис. 8. Схема информационного взаимодействия аппаратных и программных средств разработки

Fig. 8. The scheme of information interaction between hardware and software development tools

• •    с отладочными средствами – программное обеспечение производителя отладочных средств DIMECheck и FUSE Probe .

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

• •    высокопроизводительная персональная ЭВМ;

• •    отладочное средство Nallatech Xtreme DSP Development Kit - IV , включающее в себя ПЛИС Xilinx Virtex - IV XC 4 VSX 35-10 FF 668 и Virtex - II XC 2 V 80-4 CS 144;

• •    генератор сигналов произвольной формы GW Instek SFG -2108;

• •    цифровой осциллограф LeCroy WaveRunner 64 Xi ,

• •    анализатор спектра сигнала Agilent FieldFox Analyzer N 9914 A (рис. 9).

Программная реализация моделей структуры и динамики ЖЦ ЭКД выполнена на базе системы управления инженерными данными «Лоцман: PLM ». В качестве унифицированного формата ЭКД разрабатываемого изделия использованы открытые стандарты обмена данными на базе расширенного языка разметки XML . При невозможности экспорта информации в едином формате берут конвертор, преобразующий текстовую информацию в таблицу формата . xls . Структура разрабатываемого угломерного ГНСС-приемника дана в ЕИП в виде схематического описания IP - XACT (стандарт IEEE 1685), представляющего собой расширение языка XML для документирования метаданных блоков, применяется в проектировании, разработке и верификации электронных систем [19].

Преобразователь в единый формат ЭКД выполнен на языке C # с использованием скриптового языка высокого уровня Tcl . Взаимодействие преобразователя со средой LabVIEW осуществляется с помощью расширения Model Interface Toolkit , со средой MATLAB – с использованием модуля tclmatlab свободно распространяемой среды разработки Tloona , ориентированной на язык Tcl . Взаимодействие преобразователя с прочими программными продуктами осуществляется с помощью встроенных интерпретаторов языка Tcl .

Разработанный автоматизированный стенд обеспечивает выполнение процессов проектирования, разработки и проведения испытаний ГНСС-приемника на протяжении всего проект-

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

Fig. 9. The hardware implementation structure of the automated stand for design, development and conduct of research tests ного цикла. При этом реализовано автоматизированное протоколирование результатов испытаний и формирование требуемого комплекта конструкторской документации в электронном виде. Комплект ЭКД, созданный с применением предложенных методов и алгоритмов, обладает требуемой полнотой и непротиворечивостью.

В качестве примера на рис. 10–12 приведены диаграмма спектра, автоматизированные протоколы исследовательских испытаний угломерного ГНСС-приемника, полученные с использованием разработанного стенда.

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

ИНФОРМАЦИЯ ( 3 кадр )

1еографические координаты		Геоцентрические координаты		Угловые координаты
Широта	56*0.3995Ъ	X	-177298.3 м	Азимут	210.127
Долгота	Э2М5Э44Е	Y	3569907 Эм	Крен	0.057
Высота	1144.33*	Z	5264Э75 7 *	Угол места	■0337
Геон Фактор	130	X проекции Г-К	6209350 6 м	UFIag	=
Скорость		Y проекции Г-К	16490233 0 м	Время и частота
Вертикальная	•0.01 м/сек			ИРК UTC	6 .617618 мс
Север Ог	0.02 м/сек	Путевой угол	50.38*	ГЛОНАСС-GPS	208.383276 нс
Запад Восток	О 02 м/сек	Путевая скорость	0 03 м/сек	Рас стройка ОГ	1 83X010
Количество ИКА в расчете 9 ГЛОНАСС и 9 GPS				Отстройка ВхМВ	0 нс
Режим навигации	Готовность координат	0%		29 Апрель 2013 11:54:28

Рис. 10. Настройки автоматизированного стенда для проведения испытаний ГНСС-приемника

• Fig. 10.    Automated stand settings for GNSS receiver testing

  

  нооиально

  чаркер на

  tef: -50. OOdRm

  SAtt:О. OOdB

  L604239130 GHi

  ¹¹ 2 1.60423 СНз

  -124.36 dBm

  больше

  I of 2

  #№W:30O. 0 Hz

  функция

  ноомальне

  маркер грнка

  График "

  Span:2 5. 0000001Hz

  Sweep:1 8. ЬЗ s

  навкео

  2 3 4 5 6

  Рис. 11. Диаграмма спектра навигационного сигнала ГНСС-приемника

  
  

  Center:1.602500000GHz

  
  

• Fig. 11.    The Spectrum Chart of the GNSS Receiver Navigation Signal

  

  Рис. 12. Протоколы измерений видимости для группировки ГЛОНАСС

  Fig. 12. Protocols of visibility measurement for the GLONASS satellite group

  
  
  
  
  

обеспечиваются в стандартных форматах – XML или xls . Хранилище (репозиторий) информации реализовано на основе комплекса обработки инженерной информации «Лоцман: PLM ».

Заключение

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

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

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

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

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

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

Стоит отметить, что в представленном варианте используется PLM -система, ориентированная на металлоемкие отрасли машиностроения с преобладанием крупносерийного производства. Для более эффективного ее использования при информатизации проектной деятельности необходима модификация исходной системы под требования приборостроительной отрасли. Также возможна реализация отдельных функций PLM / PDM -системы на базе систем контроля версий, таких как Rational ClearCase, Perforce и PVCS , получивших широкое распространение при организации разработки программного обеспечения.

Работа выполнена при финансовой поддержке Министерства образования и науки РФ (договор № 02.G25.31.0202 от 27 апреля 2016 г.).