CC BY
20Journal of Siberian Federal University. Engineering & Technologies, 2019, 12(3), 293-313
y^K 621.396.62+658.56
Formation of the Integrated Information Environment of a Radio-Electronic Equipment Design
Oleg V. Drozd* and Denis V. Kapulin
Siberian Federal University 79 Svobodny, Krasnoyarsk, 660041, Russia
Received 12.04.2017, received in revised form 24.04.2018, accepted 27.02.2019
Widely known method of combining of different information instruments of design support is formation of a common information space. However the modern nomenclature of software for the organization of a common information space not always considers specifics of a radio-electronic equipment production. In article the task on development of a mathematical model for the electronic designer document and formalization of interaction between design tools at all stages of a project cycle of a radio-electronic equipment is researched. The mathematical model of the electronic designer document with using of the subject-oriented ontology apparatus and theory of sets is offered. Dynamics of the electronic designer document life cycle is described by using of the automata theory, graphically the model of dynamics is presented in the form of the oriented graph, simulation modeling of dynamics was carried out in the numerical computing environment MATLAB with using of an extension packet Stateflow. Application area of use of the developed mathematical model is design and tests of digital receivers of navigation satellite signals. The hardware-software automated bench and software of interaction with management system the engineering data "Lotsman: PLM" within a common information space are developed for implementation of tests of the designed digital receiver.
Keywords: PDM, design support, common information space, subject-oriented ontology, theory of sets, automata theory, testing of a radio-electronic equipment.
Citation: Drozd O.V., Kapulin D.V. Formation of the integrated information environment of a radio-electronic equipment design, J. Sib. Fed. Univ. Eng. technol., 2019, 12(3), 293-313. DOI: 10.17516/1999-494X-0137.
© Siberian Federal University. All rights reserved
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License (CC BY-NC 4.0). Corresponding author E-mail address: olvldrozd@gmail.com
Формирование интегрированной информационной среды поддержки проектирования радиоэлектронной аппаратуры
О.В. Дрозд, Д.В. Капулин
Сибирский федеральный университет Россия, 660041, Красноярск, пр. Свободный, 79
Широко известным способом объединения различных информационных средств поддержки проектирования является формирование единого информационного пространства. Однако современная номенклатура программных средств организации единого информационного пространства не всегда учитывает специфику производства радиоэлектронной аппаратуры. В статье исследуется задача по разработке математической модели электронного конструкторского документа и формализации взаимодействия между средствами проектирования на всех этапах проектного цикла радиоэлектронной аппаратуры. Предлагается математическая модель конструкторского документа с использованием аппарата предметно-ориентированных онтологий и теории множеств. Динамика жизненного цикла конструкторского документа описывается с помощью теории автоматов, графически модель динамики представлена в виде ориентированного графа, имитационное моделирование динамики проводилось в среде MATLAB с использованием пакета Stateflow. Прикладной областью применения разработанной математической модели является проектирование и испытания цифровых приемников навигационных спутниковых сигналов. Для осуществления испытаний цифрового приемника разработаны программно-аппаратный автоматизированный стенд и программные средства взаимодействия стенда с системой управления инженерными данными «Лоцман: PLM» в рамках единого информационного пространства.
Ключевые слова: поддержка проектирования, единое информационное пространство, предметно-ориентированная онтология, теория множеств, теория автоматов, испытание радиоэлектронной аппаратуры.
Введение
Разработка современной радиоэлектронной аппаратуры связана с непрерывным увеличением степени сложности проектируемых устройств, ужесточением требований к технологическому процессу полупроводникового производства, эволюцией методов и подходов к проектированию. При проектировании сложных цифровых систем широко применяются методологии «Система на кристалле» (System-on-a-Chip, SoC) и «Сеть на кристалле» (Network-on-a-Chip, NoC), ориентированные на использование заранее разработанных схемотехнических блоков (программных процессоров, блоков памяти, цифровых усилителей, фильтров и т. д.) [1-3]. На каждом этапе такого процесса используется собственная система автоматизированного проектирования, что повышает эффективность отдельных этапов или стадий процесса проектирования. Но при этом неизбежно образуется поливендорная среда, содержащая разнородные решения нескольких производителей (вендоров), что порождает ряд проблем, связанных с отсутствием единых информационных решений:
• отсутствие цельного системного представления о процессе проектирования;
• невозможность детального анализа всей совокупности проектной информации;
• сложность быстрого принятия проектных решений из-за отсутствия унифицированных подходов к проектированию и обработке проектной информации.
Кроме того, стоит учитывать особенности современного производства радиоэлектронной аппаратуры: большой ассортимент выпускаемой продукции, мелкосерийный характер производства, необходимость быстрой переналадки и перенастройки как всего производства, так и процессов проектирования, обусловленная выпуском новой продукции и/или заменой компонентной базы. В таких условиях поливендорная среда проектирования, характеризующаяся наличием значительного числа как систем автоматизированного проектирования, так и иных прикладных программ различных производителей, нуждается в пересмотре с точки зрения эффективности организации применения разнородных информационно-программных решений.
Известным способом разрешения недостатков поливендорной среды является объединение различных информационных, программных и аппаратных средств поддержки процессов проектирования в единый комплекс информационно-программных решений и формирование на его основе единого информационного пространства [4, 5]. Информационное взаимодействие по такому принципу должно быть поддержано автоматизированными информационными системами сбора, обработки и анализа проектной информации, представленной в виде различных электронных конструкторских документов. Данный подход уже на ранних этапах проектирования обеспечивает формализацию методов и протоколов взаимодействия между аппаратными и программными средствами различных производителей, что существенно повышает эффективность обработки информации и способствует быстрому принятию проектных решений.
Постановка задачи
Учитывая современные подходы к проектированию, разработке и организации производства радиоэлектронной аппаратуры, использовать ограниченную, нерасширяемую номенклатуру прикладных программных продуктов для решения разнообразных проектных задач невозможно. При этом наличие большого количества разнородных, зачастую несовместимых между собой программных систем порождает значительное число плохо управляемых потоков информации, нуждающихся в унификации и единых подходах к их анализу и обработке. Единое информационное пространство (ЕИП), формируемое для систематизации и унификации обработки информации, связанной с решением прикладных задач проектирования и производства радиоэлектронной аппаратуры, позволит исключить недостатки поливендорной среды проектирования.
Формирование ЕИП или интегрированной информационной среды невозможно без разработки математической модели электронного конструкторского документа (ЭКД) и формализации взаимодействия между программно-аппаратными средствами проектирования на всех этапах проектного цикла (ПЦ). Формальное описание ЭКД должно включать в себя модели структуры и динамики процессов жизненного цикла (ЖЦ) ЭКД, описывающие, соответственно, структурную организацию ЭКД, и переходы по стадиям жизненного цикла документов (состояния ЭКД). Таким образом, при формировании ЕИП следует:
• формализовать описание ЭКД в виде единой математической модели, сочетающей в себе представление электронного конструкторского документа в рамках ЕИП с точки зрения его структуры и поведения;
• разработать требования к единому формату ЭКД, обеспечивающему эффективный обмен данными между средствами проектирования в ходе ПЦ;
• предложить методы и средства для интеграции программно-аппаратных комплексов проектирования в единую информационную среду с использованием единого формата ЭКД.
Стоит отметить, что уже известные решения в области организации ЕИП успешно применяются при создании безлюдных гибких производственных систем в различных областях машиностроения, в том числе с использованием виртуальных автоматизированных систем управления производством, но единых, хорошо апробированных подходов, методов и средств, полностью удовлетворяющих потребности проектных организаций при разработке и мелкосерийном производстве сложной радиоэлектронной аппаратуры, пока нет [6-9].
Формализация структуры электронного конструкторского документа в рамках единого информационного пространства
Прежде чем перейти непосредственно к рассмотрению единой модели представления данных об изделии и структуры PDM-системы, необходимо кратко обрисовать маршрут проектирования СБИС класса «Система на кристалле». Весь цикл проектирования можно представить в виде совокупности пяти основных этапов [10, 11]:
1. Системное проектирование - определение основных эксплуатационно-технических свойств будущей системы. На основании этих свойств создается системная спецификация, которая может выступать частью технического задания на разработку системы.
2. Функциональное проектирование - разработка и верификация синтезируемой RTL-модели (Register Transfer Level) на уровне регистровых передач.
3. Логическое проектирование - разработка логической схемы СнК.
4. Топологическое проектирование - разработка и верификация топологии СБИС.
5. Этап верификации и подготовки к производству.
На этапе системного проектирования разрабатывается поведенческая модель Снк и определяется состав СФ-блоков. Исполняемые спецификации представляются в определенном формате на языках С, С++, Verilog и VHDL.
Разработка СнК начинается с анализа задач и требований, а также написания системной спецификации. При этом определяются основные эксплуатационно-технические свойства Снк, такие как требуемое быстродействие и допустимая потребляемая мощность.
Алгоритм работы СнК на уровне математического описания создается на основе разработанной системы спецификации. Производится математическое моделирование разработанных алгоритмов функционирования СнК, оценка требуемого быстродействия, разрядности и оценка формата представления внутренних данных. Также при необходимости может производиться синтез наборов данных (сигналов), предназначенных для тестирования схемотехнических решений СнК.
На основе алгоритма работы СнК разрабатывается поведенческая модель системы на уровне СФ-блоков в виде блок-схемы, отражающей принцип взаимодействия СФ-блоков в составе СнК и включающей их основные параметры. Для верификации поведенческой модели создают
проект тестового окружения (Testbench). Он содержит в себе тестовые последовательности, генераторы входных сигналов и средства отображения выходной информации. На основе тестового окружения разрабатываются последовательности для верификации проекта на нижних уровнях проектирования, а также для функционального тестирования опытных образцов. После этого проводят верификацию поведенческой модели путем компьютерного моделирования с помощью специальных программных средств.
Далее принимается решение о том, какие СФ-блоки поведенческой модели будут реализованы на аппаратном уровне, а какие - на программном, на основе встроенных в СнК процессорных ядер; разрабатывается интерфейс между аппаратным и программным обеспечениями и определяется общая аппаратная архитектура СнК. Разрабатывается спецификация и определяются приобретаемые, имеющиеся в наличии и вновь разрабатываемые СФ-блоки. В итоге создается набор спецификаций на разработку как программного обеспечения, так и каждого аппаратно реализуемого СФ-блока.
При совместной программно-аппаратной верификации проверяется функционирование аппаратного обеспечения, разрабатываемого в соответствии с имеющимися спецификациями, под управлением встроенного программного обеспечения в реальном масштабе времени. В качестве аппаратного обеспечения используются исполняемые спецификации аппаратно реализуемых блоков, в качестве программного - прототип прикладного программного обеспечения (ПО), развертываемого на базе Снк (например, прикладное ПО для цифровой обработки сигналов на базе операционных систем реального времени Unison и других Unix-подобных систем для архитектур MicroBlaze и Cortex).
При выборе архитектуры одним из ключевых параметров является низкое энергопотребление микросхемы. Исходя из этого, производится подбор СФ-блоков и разделение на аппаратный и программный уровни. Поэтому необходимо получить и систематизировать полную техническую информацию о покупных и имеющихся в наличии СФ-блоках, так как их характеристики могут существенно повлиять на архитектуру микросхемы.
Концептуальная модель единого информационного пространства
Рассмотрим концептуальную модель ЕИП, приведенную на рис. 1. Модель ЕИП (поз. 1) включает следующие основные составляющие:
• система управления данными об изделии (PDM-система, поз. 2) - информационная система, реализующая совокупность математических моделей ПЦ, обеспечивающая единый обменный формат ЭКД и предоставляющая платформу для информационного взаимодействия между поставщиками и потребителями информации;
• участники проектного цикла (поз. 3) - поставщики и потребители информации;
• аппаратные источники ЭКД (поз. 4) - стационарные и портативные рабочие станции, измерительное оборудование, отладочные средства различного типа;
• программные источники ЭКД (поз. 5) - развернутые на базе аппаратных источников системы автоматизированного проектирования (САПР), средства имитационного моделирования.
Рис. 1. Концептуальная модель ЕИП
Fig. 1. The Unified Information Space(UIS) conceptual model
Участники проектного цикла (поставщиниинфоимации) передаютЭКД полаженные на текущем этапе ПЦ, участникам-потребителям, которые могут быть расположены на текущем, последующем или предыдущем этапе ПЦ. Причем поставщик информации может также выступать и в роли потребителя информации от других участников ПЦ. Приведение разнородных ЭКДот программныхиаппаратных систем сторонних разработчиков к единому форматуосуществляется программным конвертором-преобразователем. ХранениеЭКД и информационное взаимодействие между участниками проектного цикла обеспечиваются РТФТ-силормай-
Для формалиоалой струоруры ЭКД применом аппагам предметно-ориентироведдоп он-голоспИ исооттетсамающие ррсдлоее теориоииежеств [10-И2]. Моделлртруклуды —КПдля таккоослри—к определимследующимо-иалом (0):
O — РFmK Л^Т ) ,
где C - набор категорий (классов объектов, понятий) ЕИП; I - набор информационных ресурсов (ЭКД), которые описываются различными категориями; E - единый обменный формат ЭКД, который позволяет формально описать все виды разнородных информационных ресурсов; L-набор внешние форматрк предотавления ЭКД в ЕИП; Fexl(L1) ^ E - функция преобразования ЭКД из внешних форматов в единый формат; Fmd(E) ^ I - функция преобразования ЭКД из единого формата в набор информационных ресурсов; F/I,) ^ I - функция поиска требуемых информационных ресурсов (I), удовлетворяющих заданным поисковым критериям (I,); Fexc(Ii) ^ Ij - функция информационногообменамеждуузлами ЕИП.
- 298 -
Электронный конструкторский документ (I) как информационный ресурс можно представить в виде кортежа (2):
I = ( р, с, V, а, 5, ^, , П,
где р = {р,} - множество атрибутов документа, , = 1 ^ ,, , - количество типов атрибутов в информационном ресурсе; с = {с,} - множество категорий документов, , = 1 ^,,, - количество типов категорий, к которым может принадлежать информационный ресурс; V = {ук} - множество значений атрибутов, при этом V = {ук | ук - описание к-го значения атрибута, к = 1 ^ п, п - количество значений атрибутов в информационном ресурсе}; d = - множество прав доступа к документу, при этом Б = | dm - описание т-го права доступа некоторого пользователя -чтения, записи, удаления, передачи; т = 1 ^ т, т - количество определенных прав доступа}; £ - набор настроек синхронизации, где каждая настройка определяет достаточные данные для осуществления информационного обмена, т. е. для выполнения функции Еехс(1) ^ I,, при этом £ = {5,- | - описание настройки синхронизации с 1-м узлом ЕИП, , = 1 ^ к, к - количество узлов, с которыми синхронизируется информационный ресурс}; Е - набор прикрепленных файлов, при этом Е = {/ | fi - описание ,-го файла, , = 1 ^ I, I - количество прикрепленных к информационному ресурсу файлов}; / = {/к} - множество типов файлов, к = к, к - количество типов файлов, ассоциированных с информационным ресурсом;/т = {тр} - множество атрибутов файлов, р = 1 ^ р, р - количество значений атрибутов файлов, ассоциированных с информационным ресурсом.
Все создаваемые, модифицируемые и передаваемые в процессе проектирования радиоэлектронной аппаратуры электронные конструкторские документы можно разделить на пять основных категорий (ук):
• VI - цифровая модель (модель в формате MATLAB/Simulink)^;
• у2 - исходный код (описание устройства на языке VHDL);
• у3 - отчет (отчет о верификации);
• у4 - текстовый документ (текст спецификации);
• у5 - электронный документ свободной формы (документы, не подпадающие под вы-шеперечисленныетипы).
Документы категорий у2, у3 и у4 относятся к текстовым электронным документами, VI и у5 - к нетекстовым. Каждой категории соответствует свой тип файлов (/к): цифровая модель (/1), исходный код (/2), отчет (/3), текстовый документ (/4), электронный документ свободной формы (/5).
В терминах предметно-ориентированной онтологии информационный ресурс состоит из реквизитной части (соответствует области метаданных ЭКД, определяется параметрами р, с, V, d, £) и содержательной части (параметры Е, /,, /). Атрибуты различных типов файлов (/) содержательной части в целом аналогичны (имя, размер и тип файла в терминах ПЦ и т. д.). Любой атрибут может заполняться пользователем в процессе работы с системой вручную путем выбора из списка доступных значений атрибута или автоматически при загрузке соответствующего файла в хранилище с преобразованием в единый формат.
Область метаданных представлена индивидуальной карточкой ЭКД. Набор атрибутов индивидуальной карточки документа зависит от того, куда передается или откуда получен ЭКД.
Таким же образом, как и при работе с файлами, любой атрибут может заполняться пользователем вручную или автоматически. Введение автоматического формирования метаданных для ЭКД позволяет снизить влияние человеческого фактора на документооборот в ходе проектного цикла [13-15].
Динамическаямодель элект роннотпкенпт рукеереко гоппокумент а
Дая ноапюиыфенеоиизованного предатаваенин слееепет рассмопрпть модель, описываю-щуюосоОееноттипоиеденияеКДнаг иекоерптпедииакическоао объекто.Для этого целесоо-бназнп таиЕТпавитьмодпль переходов между стадиями жизненного цикла ЭКД в виде конечного автомата (КА) Мили (3):
я=(2, д V, ж, м0, х, у, г).
Описание конечного автомата включает в себя следующие элементы:
•б = где в = 1 ^ в' - множество сигналов на изменение стадии ЖЦ ЭКД, поступающих вЕИП наданномэтапеПЦ(входной алфавит);
• Б = {где V =1 ^ V - множество ответных реакций на изменение стадии ЖЦ ЭКД на данном этапе ПЦ (выходной алфавит);
• V = {уу},гдеу=1^- у' - множество состояний ЭКД (алфавит состояний);
• ^ = б х Б х V, х V2- множество действий, совершаемых над ЭКД, где четверка (др, Ак уу+ь уу) означает, что документ по запросу с ответом dV перешел из состояния уу в состояние Уу+ь
• N = {0, 1, 2 ...} - множество значений номеров этапов ЖЦ ЭКД;
• X - множество функций х: N ^ б, задающих все возможные последовательности запросов к ЕИПвходеЖЦЭКД;
• У - множество функций у: Х0 ^ Б, задающих все возможные последовательности ответов ЕИПпо запросам (функция выходов);
• 2 - множество функций г: N ^ V, задающих все возможные последовательности состояний к ЕИП в ходе ЖЦ ЭКД (функция переходов).
Для каждого документа, формируемого в ходе ПЦ, можно выделить последовательность стадий его собственного ЖЦ, что отражается в свойствах документа как «Стадия ЖЦ документа» (алфавит состояний КА, табл. 1).
Рассмотрим логическую последовательность выполнения процессов стадий жизненного цикла ЭКД в ЕИП (переходов конечного автомата 5"):
1. До начала проектирования документ находится в стадии ЖЦ «Новый».
2. При инициализации процесса проектирования документ переходит в стадию ЖЦ «В разработке».
3. Для предоставления общего доступа к документу его следует опубликовать в PDM-системе, при этом стадия жизненного цикла документа меняется на «Опубликован».
4. В случае изменения документ переходит в стадию ЖЦ «Внесение изменений в документ» и становится недоступным на время выполнения работ стадии.
Таблица 1. Стадии жизненного цикла ЭКД
Table. 1. Life cycle stages of the Electronic Design Document (EDD)
Обозначение Стадия жизненного цикла
Cl Новый
C2 В разработке
Сз Опубликован
C4 Внесение изменений в документ
С5 Утверждение нового документа
Сб Согласование документа
С7 Создание локальной копии документа
С8 Внесение изменений в новую версию документа
С9 Утверждение новой версии документа
С10 Выпуск документа
Cil Аннулирование документа
Cl2 Документ не активен
5. После внесения изменений документ переходит в стадию ЖЦ «Утверждение нового документа».
6. При завершении процесса утверждения нового документа происходит его переход в стадию ЖЦ «Согласование документа».
7. В случае успешного согласования документа объявляется окончание его разработки и стадия жизненного цикла изменяется на «Выпуск документа».
8. Если документ не прошел согласование, то необходимо внести в него изменения. Для этого создается локальная копия изменяемого документа (стадия ЖЦ «Создание локальной копии»), затем вносятся изменения в локальную копию документа (стадия ЖЦ «Внесение изменений в новую версию»). После внесения всех необходимых изменений документ переходит в стадию ЖЦ «Утверждение новой версии документа» и передается на согласование.
9. Если документ уже не актуален, то он выводится из проектного цикла и переходит в стадию ЖЦ «Аннулирование документа».
10. Если документ не участвует в этапе проектного цикла, то переходит в стадию ЖЦ «Документ не активен».
Набор операций по изменению стадий ЖЦ документа определен как входной алфавит автомата Мили и представлен в табл. 2.
Представим стадии ЖЦ ЭКД в виде состояний и функций перехода конечного автомата Мили. Описание функций перехода по стадиям ЖЦ ЭКД приведено в табл. 3.
Связав вершины представления конечного автомата дугами в направлении движения от начальной вершины к конечной, согласно табл. 2 и 3, получим модель изменений стадий ЖЦ ЭКД в ЕИП в виде ориентированного графа (рис. 2).
Инициирующим действием начала работ по ЖЦ конкретного ЭКД является управляющее воздействие как изменение статуса управляемого документа. Признак завершения конкретного
Таблица 2. Операции перехода по стадиям ЖЦ документа Table 2. Transition operations in the life cycle stages of a document
Стадия ЖЦ документа Операция перехода в стадию ЖЦ
Название Обозначение
1. Новый Создать Xi
2. Опубликован Опубликовать X2
3. Внесение изменений в документ / Внесение изменений в новую версию документа Изменить Хз
4. Утверждение нового документа / Утверждение новой версии документа Утвердить Х4
5. Согласование документа Согласовать Х5
6. Создание локальной копии документа Копировать Хб
7. Выпуск документа Выпустить Х7
8. Аннулирование документа Аннулировать Х8
9. Документ не активен Вывести Х9
Таблица 3. Функции перехода по стадиям ЖЦ документа Table 3. Transition functions in the life cycle stages of a document
Стадия жизненного цикла Состояние Функция перехода
документа в состояние
1. Новый Cl -
2.В разработке С2 х1 = / (с1) - создать
3. Опубликован Сз х2 = / (с2) - опубликовать
4. Внесение изменений в документ С4 х3 = / (с3) - изменить
5. Утверждение нового документа С5 х4 = / (с4) - утвердить
6. Согласование документа Сб х5 = / (с5) - согласовать
7. Создание локальной копии С7 х6 = / (с6) - копировать
8. Изменение новой версии С8 х3 = / (с7) - выпустить
9. Утверждение новой версии С9 Х4 = / Ы - утвердить
10. Выпуск документа С10 х7 = / (с9) - выпустить
11. Аннулирование документа Cil х8 = / (с2) - аннулировать
12. Документ не активен С12 х9 = / (с2) - вывести
этапа ЖЦ ЭКД - смена атрибута статуса управляемого документа. Понятие статуса документа трактуется как совокупность атрибутов, однозначно определяющих фазу ЖЦ конкретного документа в рамках моделируемого этапа ПЦ. Условие завершения ЖЦ ЭКД - достижение им стадии с10 «Выпущен» или са «Аннулирован».
Для имитационного моделирования динамики изменения стадий ЖЦ ЭКД используем среду МЛТ1АВ с подключенным пакетом 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)t
• не активон(2)р
• аннулирован(З).
Имитационная модель КА представлена тремя отдельными циклами обработки документа (рис. 3):
1) обработка без внесения изменений (поз. 1);
2) обработка с внесением изменений (поз. 2);
3) вывод из обращения (поз. 3).
Номера состояний документа на рис. 3 указаны в кружках и соответствуют номерам состояний, приведенным в табл. 3.
На рис. 4 показана форма отображения динамики выполнения процессов стадий жизненного цикла ЭКД в ходе моделирования в пакете Stateflow. Так, в приведенном случае активный ЭКД находится в стадии ЖЦ c2 «В разработке», при этом не известно, будут в него внесены изменения или нет. Текущая стадия документа в ходе моделирования выделена жирной линией. На рис. 5 активный ЭКД находится в стадии ЖЦ c9 «Утверждение», при этом в документ уже внесены изменения и в данной стадии выполняется утверждение новой версии документа.
Разработанная имитационная модель позволяет эффективно проводить событийное моделирование организационных и технических процессов, которые сопровождаются изменением статуса электронной документации и, соответственно, нуждаются во взаимном согласовании. В рассмотренном случае моделирование показало потенциальную выполнимость ЖЦ ЭКД, отсутствие бесконечных циклов, «тупиков» и других коллизий, препятствующих протеканию процессов жизненного цикла конструкторского документа.
Формирование интегрированного информационного пространства поддержки проектирования, разработки и проведения испытаний радиоэлектронной аппаратуры
В качестве прикладной области применения предложенных методов и средств организации электронного документооборота и единого информационного пространства рассмотрим интегра-
Рис. 3. Имитационная модель динамикиизмененип стадий ЖЦ ЭКД Fig. 3. The simulationmodelofthedynamicsofthe EDD life cycle stages
moo« -- и
Рис. 4. Отображение стадии ЖЦ ЭКД «В Рис. 5. Отображение стадии ЖЦ ЭКД
разработке»
«Утверждение»
Fig. 4. Display of the EDD life cycle stage "Develop- Fig. 5. Display of the EDD life cycle stage "Approval" ment"
цию программных и аппаратных средств, используемых при проектировании цифровых приемников навигационных спутниковых сигналов (ГНСС-приемников) с измерением углов пространственной ориентации подвижных объектов (углов Эйлера). Такого рода устройства предназначены для работы с навигационными сигналами (НС) от двух навигационных космических аппаратов (НКА), реализуются на базе заказных или полузаказных интегральных схем, базовых матричных кристаллов (БМК) или программируемых логических интегральных схем (ПЛИС).
С точки зрения организации процесса проектирования разрабатываемый угломерный ГНСС-приемник можно представить в виде двух составляющих:
• программный имитатор сигналов от НКА (рис. 6, поз. 1);
• структурные единицы ГНСС-приемника (рис. 6, поз. 2).
Разрабатываемый ГНСС-приемник включает в себя составляющие [16, 17]:
• Г1 - блок генерации информационной и частотной составляющей НС НКА 1;
• Г2-блокгенерацииинформационнойи частотной составляющейНСНКА 2;
• КА1 - блок имитатора генерации и усиления НС на НКА 1;
• КА2 - блок имитатора генерации и усиления НС на НКА 2;
• СФ1 - блок ввода фазового сдвига НС от НКА 1;
а СФ2 ц блок вводафанквонн ндаига НСот НКА2;
н(ф-склектор НКА;
• П_НК-ириемнма Юф Ы;
• П_Мф - прнемник НС £2;
• РН- Прокра_решенияфазов_й неоднозначносрнНСсиспользов_ннем друхчасрот_ого режима;
• Ф1 - блок вычисления фазового сдвига НС;
• УО1 - блок разрешения системы уравнений определения угловой ориентации объекта (углов Эйкерв)нлве ливннвфазнвого лдвигаНС.
В целом нцл цесс проевхированин цифровой геслнмы по митодологив СнФ вклюяаетв себя следоющан этапьгсистлмноепроевни(ВбЫФке,фунКнилннльнсФ прАяитирохание, княическое про2овировбннр;твпАлогическФепровоАрров)шие,ЭА2Р вериКвкФцнии есднотовиик ирнизбаи-ству [18]. Рассмотрим пример интеграции средств проектирования для этапа системного проектирования, сделав допущение, что методы интеграции для остальных этапов ПЦ аналогичны.
Блок-схема этапа системного проектирования угломерного ГНСС-приемника представле-н;^^абис.ц.1^;^з^^(-2^1сд(о^Ьср^^нк^пв ллнтемфроа проексирования начинается с анализа требование, сгааж-раздрботкю спецификнцмиеисинмы (рнс-Н;РОЗ-1-)ЛПВФЭтомонреналяювся
требуемое быстродействие и
допустимая потребляемая мощность. Алгоритм работы СнК на уровне математического описания разрабатывается на основе спецификации системы (рис. 7, поз. 1.2). На данном этапе произ-
Рис. 6. Структурная схема угломерного ГНСС-приемника
Fig. 6. The block diagramoftheangular Global Navigation SatelliteSystem(GNSS)receiver
— 305 —
водится математическое моделирование разработанных алгоритмов функционирования СнК, оцениваются требуемое быстродействие, разрядность и форматы представления внутренних данных.
На основе алгоритма работы разрабатывается поведенческая модель, отражающая общие принципы функционирования СнК (рис. 7, поз. 1.3). Для верификации поведенческой модели разрабатывают поведенческую модель тестового окружения (рис. 7, поз. 1.4). Она включает в себя тестовые последовательности, генераторы входных сигналов и средства отображения выходной информации. На основе разработанной модели впоследствии проектируются и реализуются тестовыепоследователыюсти дляверификациипроекта на нижних уровняхпроек-тирования, а также для тестирования опытных образцов. После этого проводят верификацию иоврденчпскяиял>ыелисхртемы -рлт.7, поз.ед) .
Наостоыепопедкифесройкядели сифтсмы уызуабатываетсястру лтяенаямодель системы на уровне функциональных блоков (рис. 7, поз. 1.6), отражающая принципы взаимодействия ояделякых бликов всоставеСлК т ифлючжщыялттссо вныепарахтсры.
Структурная модель системы позволяет выполнить генерацию описания блоков разрабатываемой СнК на уровне регистровых передач с использованием языков описания аппарату-ут1 (ЫЮя-ОФиеанрс,ниСмя,пяы 1.7),акахкгичнргерериямлтся Л/Щ-описнняеряскрвосоохпу-
^ Конец ^
Рис. 7. Блок-схема этапа системного проектирования ГНСС-приемника Fig. 7. The block diagram of the GNSS receiver system design stage
- 306 -
жения (рис. 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 GraphicsModelSim.
Таблица 4. Программные средства, которые используются на этапах системного проектирования ГНСС-приемника и порождаемые ими форматы ЭКД
Table 4. Software that is used at the stages of the GNSS receiver system design and EDD formats generated by them
Номер этапа Hcnorn3yeMoe nporpaMMHoe o6ecneneHne Форматы документов Типы документов
1.1 MS Word .doc, .docx v3, v4
1.2 MATLAB, Maple, Enterprise Architect .m, .ns, .msw, .eap v2, v5
1.3 MATLAB, Simulink: Communications System Toolbox; DSP System Toolbox .m, .slx vb v2
1.4
1.5 MATLAB, Simulink: Simulink Control Design; Simulink Design Optimization; Simulink Design Verifier .html v3
1.6 MATLAB, Simulink: HDL Coder; Communications System Toolbox HDL Support .m, .slx vb v2
1.7 MATLAB, Simulink: HDL Workflow Advisor; HDL Code Generation .m, .slx, vhd, .html vb v2, v3, v4
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 v2, v3, v4, v4
Также у каждого ЭКД имеется статус происхождения: «извне», «создается», «создается/ передается». Каждый из создаваемых ЭКД относится к одной из категорий документов vk.
Проектирование на системном этапе осуществляется с помощью программно управляемого автоматизированного стенда разработки и проведения испытаний, включающего в себя соответствующие аппаратные и программные средства. Информационное взаимодействие программно-аппаратной структуры в составе такого стенда приведено на рис. 8.
Ядром автоматизированного программно-управляемого стенда является персональная ЭВМ с развернутыми на ней программными средствами проектирования и разработки (рис. 8, поз. 6), включающими в себя прикладное программное обеспечение (рис. 8, поз. 7) и программный модуль преобразователя в единый формат ЭКД (рис. 8, поз. 8), через который осуществляется взаимодействие с PDM-системой (рис. 8, поз. 11). Аппаратные средства разработки включают в себя измерительное оборудование (генераторы сигналов, осциллографы, анализаторы спектра, рис. 8, поз.1) и отладочныесредства (отладочныеплатыи комплектыразработчика, рис.8,поз,9).
Взаимодействие между программными средствами и измерительным оборудованием осуществляется посредством программной архитектуры виртуальных устройств (VISA, рис. 8, нав 5),использующей стандартизированный интерфейс ввода-вывода тестирования и прове-денио измсвениЧдля управтынчя пркборамы,поддсыживчющиминыеерЫейпыЯбКИ-488 (GP/K, рис. 8, поз. 2), USB 2.0 (рис. 8, поз. 3) и LAN (рис. 8, поз. 4) измерительных устройств. Взаимодействие между отладочными средствами и программным обеспечением осуществляется по-сиечсавом шинывведа-вы1вадаЧТЫ(вос. 8,чоз. 10Ы.
Со стороны программных средств за обеспечение взаимодействия отвечают: • с измерительным оборудованием - встроенные модули среды LabVIEW и модуль рас-ширенышЛЮгидаent Control Toolbox среды MATLAB/Simulink;
Рис. 8. Схема информационного взаимодействия аппаратных и программных средств разработки Fig. 8. The scheme of information interaction between hardware and software development tools
- 308 -
• с отладочными средствами - программное обеспечение производителя отладочных средств DIMECheck и FUSE Probe.
Сточкизренияаппаратнойреализацииавтоматизированныйстенд включает в себясле-дующие компоненты:
• высокопроизводительная персональная ЭВМ;
• отлндочноесреRCTvoNoUatechXOHemeDSPDevelepmentKit-ИН, вклюнтощое в себтПЛИС Xilinx МыЖех-ИКХС403ХЗИ-1ТПМ08 и ЯиЫх-ЯеНВМЛ0-40S140;
• генератор сигналов произвольной формы GW Instek SFG-2108;
• ци0довоп осещитогроф ПСгодЗВлаеПаипев
• анапиоааиревектра сигяала ^g/'feiH FieinFoxAnafyzBrNBOAAggnao.O).
Программная реализация моделей структуры и динамики ЖЦ ЭКД выполнена на базе
системы управления инженерными данными «Лоцман: PLM». В качестве унифицированного формата ЭКД развабатываемогоиздеяивзсп0ЛА30РаАР1 открытые стандарты обмена данными на базе расширенного языка разметки XML. При невозможности экспорта информации в едином формате берут конвертор, преобразующий текстовую информацию в таблицу формата .xte. Ст^ктура разрт&тыывеиого угломерного ГНСС-приемника дана в ЕИП в виде схематического онивтния /Р-ХаИВ^таадартЗЕЕЕЮЗЗ ),неддсвавонющенвстбой раептизенге языке XML для документирования метаданных блоков, применяется в проектировании, разработке и верификации электронных систем [19].
ЯДгобоадоонаелзвепзбыкформат ЭКДбыкялненна языке C# с использованием скрипто-вого языка высокого уровня Tcl. Взаимодействие преобразователя со средой LabVIEWосуществляется с помощью расширения Model Interface Toolkit, со средой MATLAB - с использованием мо^ля ы1талааЬ свокодсо распросаранееоойсртды ааз]раоотеи к/восп,криентированной на языйЫа/.Bзаимoдтйcтднeпи•oбpaззбaт•ляcпитчи мипратааммсыииоподуктами осуществляется с помощью встроенных интерпретаторов языка Tcl.
Разработанный автоматизированный стенд обеспечивает выполнение процессов проекти-рввавзо, оведтния иАпытомиСГНСС-одАемника ыаеротпжАнии всеоопроект-
Рис. 9. Структура аппаратной реализации автоматизированного стенда проектирования, разработки и проведения исследовательских испытаний
Fig. 9. The hardware implementation structure of the automated stand for design, development and conduct of research tests
ного цикла. При этом реализовано автоматизированное протоколирование результатов испытаний и формирование требуемого комплекта конструкторской документации в электронном виде. КомплектЭКД,созданныйсприменениемпредложенных методовиалгоритмов,облада-ет требуемой полнотойи непротиворечивостью.
В качестве примера на рис. 10-12 приведены диаграмма спектра, автоматизированные протоколы исследовательских испытаний угломерного ГНСС-приемника, полученные с ис-ньеьзьванредразрьбоейнного стенда.
бским оброзом,автомвьизиройеипый еаеимнио ироептнрьвания, разработки и исследования ГНСС-приемников позволяет организовать выполнение процессов проектного цикла радиоэлектронной аппаратуры заданного назначения в условиях автоматизации обработки информации, напрырепий результатоеразлчпйыо итыртщш про цессовнреемгиретания мыдотоко-лировачняверрэеоатывисеыеыоввтельеких испытаний. Накопление информации и ее передача
ИНФОРМАЦИЯ 13 надр)
I Географические координаты Геоцентрические КОйрДЫНЛТЫ Угловые координаты
Широта 56*0 3995'N X 177238. Î м Азыыут 210.127
Долгота Э2*50.5Э44'Е Y 35SÏ907 3 n Крен 0.057
Высота 144 33м Z 52И975 7 м Угол места ■в 337
Геом. Фактор ,30 X проекции Г-К 6203350 6 м UFIag
Y проекции Г-К. 1Б00233.0 M
Скорость Время и частота
Вертикальная 0,01 м/сек MPK-UÏC 6.617618 мс
Север-Юг 8 02 м/с en Путевой угол 50.30* ГШНАЕС-GPS 288.3C327G не
Запад-Восток а 02 м/сек Л j ' евап скорость 0 03 м/сек Расстройка ОГ 1 Ï3SE 010
Количество НКА в расчёте: 9 TilGHACC и Э 6PS Отстройка ВхМЗ О не
J Режим навигации Гогйяносгь кййрдмш О* 23 Апрель 2013 11:54:20
Рис. 10. Настройки автоматизированного стенда для проведения испытаний ГНСС-приемника Fig.l ((.Automated standsettings for GNSS receivertgsting
Рис. 11. Диаграмма спектра навигационного сигнала ГНСС-приемника Fig. 11. TheSp ectrumChartofthe GNSS Ree aver Navigation Signal
- 310 -
Л Процентное соотношение вид^Я xj
число спутников % наблюдения
12 11 0
13 12 0
14 13 0
15 14 0
16 1S 0
17 16 0.0261165
18 17 0.504919
19 18 4.71838
20 19 15.5045
21 20 32.2451
22 21 32.6891
23 22 14.1725
24 23 0.139288
25 >=3 100 d
- |П| X
число спутников % наблюдении -
: 0 6.92957
2 1 51.2144
3 2 18.8996
4 3 19.6657
5 3.29068
6 5 0
Рис. 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 г.).
Список литературы
[1] Wei H., Hong G., Hongna G., Kai Z., Jun L., Xiaoming L. A Novel Design of Software System on Chip for Embedded System, Journal of Signal Processing Systems, 2017, 86 (2), 135-147.
[2] Feero B.S. Networks-on-chip in a three-dimensional environment: a performance evaluation,
IEEE Transactions on Computers, 2009, 58 (1), 32-45.
[3] Хюбнер М., Бекер Ю. и др. Многопроцессорные системы на одном кристалле. Разработка аппаратных средств и интеграция инструментов. М.: Техносфера, 2012. 304 с. [Hübner M., Becker J. Multiprocessor System-on-Chip. Development of hardware and integration of tools. Moscow, Tekhnosfera, 2012, 304 p. (in Russian)]
[4] Борискин В.С., Гулякович Г.Н., Северцев В.Н. Организация мелкосерийного производства микросхем. Инженерный вестник Дона, 2012, 20 (2), 310-314. [Boriskin V.S., Gulyakovich G.N., Severtsev V.N. Organization of small batch production of chips, Engineering journal of Don, 2012, 20 (2), 310-314. (in Russian)]
[5] Загидуллин Р.Р. Управление машиностроительным производством с помощью систем MES, APS, ERP: Монография. Старый Оскол: ТНТ, 2011. 372 с. [Zagidullin R.R. Management of engineering production with the help of MES, APS, ERP: Monograph. Stary Oskol: TNT, 2011, 372 p. (in Russian)]
[6] Hu H., Wang L., Luh P. Intelligent manufacturing: New advances and challenges, Journal of Intelligent Manufacturing, 2015, 26 (5), 841-843.
[7] Duy Dao S., Abhary K., Marian R. An innovative model for resource scheduling in VCIM systems, Operational Research, 2016, 1-22.
[8] Iizuka M., Hamada N., Saito H., Yamaguchi R., Yoshinaga M. A tool set for the design of asynchronous circuits with bundled-data implementation, IEEE 29th International Conference on Computer Design (ICCD), 2011, 78-83.
[9] Musa A., Gunasekaran A., Yusuf Y. Supply chain product visibility: Methods, systems and impacts, Expert Systems with Applications, 2014, 41, 176-194.
[10] Mao Xi, Li Qi, Zhang Ziming Subject-oriented spatial information search engine based on ontology, Proceedings of Informational Technology and Environmental System Science (ITESS), 2008, 3, 843-848.
[11] Lavrishcheva E. Ontological Approach to the Formal Specification of the Standard Life Cycle,
Proceedings of the Science and Information Conference (SAI), 2015, 965-972.
[12] Соловьев В.Д., Добров Б.В., Иванов В.В., Лукашевич Н.В. Онтологии и тезаурусы: модели, инструменты, приложения. М.: Бином. Лаборатория знаний, 2009. 173 с. [Solovev V.D., Dobrov B.V., Ivanov V.V., Lukashevich N.V. Ontologies and thesauruses: models, tools, application. Moscow: Binom. Laboratoriya znaniy, 2009, 173 p. (in Russian)]
[13] Липаев В.В. Человеческие факторы в программной инженерии: рекомендации и требования к профессиональной квалификации специалистов. М.: СИНТЕГ, 2009. 328 с. [Lipaev V.V. Human factors in software engineering: recommendations and requirements for the professional qualification of specialists. Moscow: SINTEG, 2009, 328 p. (in Russian)]
[14] Evans M., Maglaras L.A., He Y., Janicke H. Human behaviour as an aspect of cybersecurity assurance, Security and Communication Networks, 2016, 9 (17), 4667-4679.
[15] Gopalakrishna A.K, Ozcelebi T., Lukkien J.J., Liotta A. Relevance in cyber-physical systems with humans in the loop, Concurrency and Computation-Practice and Experience, 2017, 29 (3), 1-18.
[16] Перов А.И., Харисов В.Н. и др. ГЛОНАСС. Принципы построения и функционирования. М.: Радиотехника, 2010. 800 с. [Perov A.I., Harisov V.N. et al. GLONASS. Principles of construction and operation. Moscow: Radiotehnika, 2010, 800 p. (in Russian)]
[17] Перов А.И. Основы построения спутниковых радионавигационных систем. М.: Радиотехника, 2012. 240 с. [Perov A.I. Basics of building satellite radio navigation systems. Moscow: Radiotehnika, 2012, 240 p. (in Russian)]
[18] Наваби З. Проектирование встраиваемых систем на ПЛИС. М.: ДМК Пресс, 2016. 464 с. [Navabi Z. Embedded Core Design with FPGAs. Moscow, DMK Press, 2016, 464 p. (in Russian)]
[19] Matilainen L., Lehtonen L., Maatta J.M., Salminen E., Hamalainen T.D. System-on-Chip deployment with MCAPI abstraction and IP-XACT metadata, Samos XII, International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation, Samos: IEEE, 2012, 209-216.
