CC BY
24Информационно-управляющие системы
Все симуляторы, существующие в настоящее время, являются модифицированной версией SPICE 3C1 и по существу сохраняют основные архитектурные особенности этого симулятора.
SPICE 3C1 - это заново написанный симулятор SPICE 2G6. Если последний был написан на фортране в университете Калифорнии в Беркли еще в 1970-х годах, то сам SPICE 3C1 - это версия, написанная на Си. Она была разработана Thomas Quarles в 1989 г. [1]. Данный симулятор включает новый расширенный интерфейс пользователя под названием «Nutmeg», обеспечивая интерактивный выбор анализа и графическое отображение результатов. Визуализация поддерживается в среде X Window System. Однако SPICE 3C1 использует тот же синтаксис входного формата (netlist) для удобства работы.
Описание архитектуры симулятора разделено на две секции. Первая секция описывает принципиальные компоненты упрощенного симулятора, вторая секция - все модификации, сделанные и улучшенные в симуляторе для получения уже более полноценного ядра.
В общем случае симулятор может состоять из двух частей:
- процессора командной строки и интерактивных графических средств, обеспечивающих интерактив-
ный выбор анализа и графическое отображение результатов;
- средств симуляции.
Процессор командной строки - это основанный на командной строке интерфейс, который позволяет контролировать симуляцию и служит для интерактивного графического отображения результатов.
В соответствии с веянием современных высоких технологий при проектировании программного комплекса важно включить возможность проектирования API-интерфейса системы, который позволяет пользователям создавать собственные модули расширения как для серверной, так и для клиентской частей системы (в случае сетевого ее варианта) для реализации дополнительных функций [2]. Модули могут быть написаны на любом .NET-языке программирования и наследовать открытую функциональность любого модуля, входящего в состав системы. API-интерфейс позволяет также интегрировать IPS с другими информационными системами.
Библиографические ссылки
1. Thomas L. Adding devices to SPICE3 // Memorandum № UCB/ERL M89/42 University of California. Berkeley, 1989. April.
2. Жуков Д. Intermech Professional Solutions - новое поколение систем ИНТЕРМЕХ. Модульная структура // САПР и графика. 2008. № 11.
A. A. Kazutov, V. S. Kanterov Siberian State Aerospace University named after academician M. F. Reshetnev, Russia, Krasnoyarsk
THE METHOD OF SCHEMATIC DESIGN PROGRAMS DEVELOPING
The method of schematic design programs developing on the base of SPICE 3C1- simulator is considered. And on its basis a possible variant of high-level schematic design programs developing is made.
© Ka3yTOB A. A., KarnepoB B. C., 2010
УДК 681.5
В. И. Киселев
Сибирский федеральный университет, Россия, Красноярск
АВТОМАТИЗИРОВАННОЕ ФОРМИРОВАНИЕ ТЕКСТОВОЙ КОНСТРУКТОРСКОЙ ДОКУМЕНТАЦИИ ПО ЕДИНОЙ СИСТЕМЕ КОНСТРУКТОРСКОЙ ДОКУМЕНТАЦИИ
Рассматривается проблема автоматизированного формирования текстовой конструкторской документации в зарубежных САПР.
Поставлена задача: разработать программный продукт для автоматизированного формирования текстовой конструкторской документации.
Основная проблема в выпуске конструкторской документации в пакетах иностранного производства -соблюдение правил ЕСКД (Единая система конструкторской документации).
Большинство САПР зарубежного производства могут формировать BOM спецификации. BOM (Bill of Materials) - универсальная спецификация состава из-
делия представляет собой, как минимум, список компонентов, их количество, вычисляемые итоги. Естественно, что структура BOM отличается от предъявляемых требований к конструкторской текстовой документации по ЕСКД. Следовательно, в настоящее время перед разработчиками, использующими САПР зарубежного производства (например, SolidWorks), стоит задача - дополнительно к BOM разрабатывать спецификацию по ЕСКД (ГОСТ 2.10-96 «Единая система конструкторской документации. Текстовые документы»).
Решетневские чтения
Для решения этой задачи существует несколько программных продуктов, осуществляющих автоматизированное формирование спецификаций из BOM: SWR PDM-спецификация, полигон-спецификация, навигатор СП. К недостаткам вышеперечисленных программных продуктов и макросов относятся программы, предназначенные для конкретных программных продуктов, которые не работают с разными САПР, неправильно формируют документацию, не полностью автоматизируют процесс, платные продукты.
Целью проведенной работы является анализ возможности автоматизации процесса формирования
конструкторской документации по ЕСКД и разработка программного продукта.
На данный момент разработан алгоритм и написан программный код автоматизированного процесса формирования конструкторской документации.
Сейчас идет настройка интерфейса для удобного использования макроса, а также тестирование на предмет ошибок и правильного формирования выходных данных.
Результаты исследования должны показать, как реализуется процесс автоматизации при формировании текстовой конструкторской документации по ЕСКД.
V. I. Kiselev
Siberian Federal University, Russia, Krasnoyarsk AUTOMATED FORMATION OF THE TEXTUAL DESIGN DOCUMENTATION ON ESKD
The problem of the automatic formation of a test design documentation in foreign CAD is considered.
© Киселев В. И., 2010
УДК 004.421.2
К. И. Кузьмичев
Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, Россия, Красноярск
АЛГОРИТМЫ РАБОТЫ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА ПРОВЕРКИ БОРТОВОЙ АППАРАТУРЫ
Рассматривается работа автоматизированных систем проверки бортовой аппаратуры. Делаются выводы об эффективности применения различных алгоритмов для проверки блоков бортовой аппаратуры в подобных системах.
Важнейшей частью конструкции современного космического аппарата является бортовая аппаратура, обеспечивающая корректную работу всех систем спутника в соответствии с возложенными на него задачами. Поэтому качественная разработка как аппаратной, так и программной части блоков аппаратуры ведет к успешному функционированию систем космического аппарата. Поэтому стоит уделять особое внимание созданию автоматизированных систем, связанных с отработкой бортовой аппаратуры.
Создание четких алгоритмов работы автоматизированных систем проверки блоков бортовой аппаратуры для проведения испытаний и отладочных работ содержит в себе следующие ключевые моменты: обеспечение, по возможности, наиболее полной автоматизации цикла проверки аппаратуры во избежание больших временных затрат для достижения конечной цели; контроль за точностью получаемых в процессе работы системы значений и независимость данных значений от множества факторов, воздействующих на систему, в том числе и «человеческих»; минимизация ручной, механической работы при подготовке и проведении испытаний блоков аппаратуры; ведение
учетных сведений о работе системы и полной отчетной информации по завершению отладочных работ.
Корректная работа автоматизированной системы проверки блоков бортовой аппаратуры является объ -ектом сразу нескольких отчетных структур и требует проведения должного анализа. Выполнение указанных этапов при разработке алгоритмов работы автоматизированного рабочего места связано с определенными трудностями, например, постоянно увеличивающимся объемом параллельных испытаний и документооборота. Решение данных задач автоматически повышает эффективность работы системы в целом, сокращает время испытаний, уменьшает экономические затраты, упрощает организацию отчетности. Разработка алгоритмов работы подобных систем позволит сократить время, необходимое для подготовки рабочего места к проведению испытаний иного блока или прибора и, как следствие, сократить промежуточные издержки.
Работа по проектированию подобных алгоритмов ведется с учетом того, что подобная система должна стать унифицированным средством отработки и проведения испытаний блоков бортовой аппаратуры.
