CC BY
42
зуется для обновления модели шума с помощью низкочастотного фильтра рекурсивного сглаживания.
Схема системы
Работу описанной системы можно разбить на два основных этапа: построение модели окружения (инициализация) и выделение областей интереса (слежение).
На рисунке 2 представлена схема разработанной системы видеонаблюдения.
Предложенная в данной статье система моделирования окружения управляемой камеры использует алгоритмы, имеющие низкую вычислительную сложность и обеспечивающие приемлемое для поставленной задачи качество анализа и обработки видеоданных. Разработанная система может применяться как для задач охраны периметра при использовании управляемых камер в помещениях и на зданиях, так и для построения различных интеллектуальных систем, например, способных выявлять криминальные ситуации.
В силу наличия параметров настройки и разных функциональных блоков предложенная система может быть использована, например, в задачах слежения за производством или для эко-
логических наблюдений. Качество анализа для предложенной системы можно повысить, если использовать специфические знания для конкретной области применения.
Список литературы
1. Chris Stauffer, W. Eric L. Grimson, Learning Patterns of Activity Using Real-Time Tracking. IEEE Transactions on Pattern Analysis and Machine Intelligence, 2000, pp. 747-757.
2. Harris C., Stephens M. A Combined Corner and Edge Detector. Proc. 4th Alvey Conference, 1988, pp. 147-151.
3. Cho J., Kim S. Object detection using multi-resolution mosaic in image sequences. Signal Processing/ Image communication, 2005, 20(3), pp. 233-253.
4. Солдатов С.А., Стрельников К.Н., Ватолин Д.С. Быстрое и надежное определение глобального движения в видеопоследовательностях. // Тр. конф.: Graphicon-2006. - Новосибирск, 2006.
5. Куликов Д., Ватолин Д. Обнаружение и заполнение статических инородных областей в видео на примере удаления логотипов и сбоев при ошибках передачи. // Матер. девятого науч.-практич. сем.: Новые информационные технологии в автоматизированных системах. - М.: 2006.
6. Куликов Д., Ватолин Д. Метод пространственного заполнения испорченных областей видео при ошибках в работе кодека. // Матер. десятого науч.-практич. сем.: Новые информационные технологии в автоматизированных системах. - М.: 2007.
7. Liu C., Freeman W.T., Szeliski R., Kang S.B. Noise Estimation from a Single Image. CVPR'06, 2006, pp. 901-908.
АКТУАЛИЗАЦИЯ И АРХИВИРОВАНИЕ ОБЪЕКТОВ ПРОЕКТИРОВАНИЯ В САПР ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ КОВКИ
С.В. Арзамасцев, к.т.н.; О.Ю. Муйземнек, к.т.н. (Институт машиноведения УрО РАН, г. Екатеринбург)
Исторически САПР технологических процессов (САПР ТП) предназначались для разработки технологической документации с целью получения изделий надлежащего качества. В круг задач САПР ТП не входили вопросы управления производством (планирование по заказам и комплектам, учет изменений по извещениям и т.п.). Функции управления решались средствами АСУ, а в настоящее время являются неотъемлемой частью СЛЬв-технологии.
Внедрение РБМ/РЬМ-систем, составляющих основу СЛЬ8-технологий, для многих предприятий является сложной задачей, связанной с организационной перестройкой всей инженерной структуры и с большими материальными затратами. Эти процессы осложняются из-за отсутствия на предприятиях достаточного количества подготовленных специалистов по СЛЬв-технологиям. Локальные САПР ТП значительно дешевле и проще в освоении и использовании по сравнению с РБМ/РЬМ-системами. Наделение их некоторыми возможностями РБМ/РЬМ-систем позволило бы решить часть проблем, связанных с управлением процессом технологической подготовки производства.
Одной из главнейших задач СЛЬ8-технологии является управление документооборотом, учитывающим актуальность разрабатываемой конструкторской и технологической документации. Суть проблемы заключается в том, что для одной и той же конечной детали возможны различные варианты ее изготовления. Кроме того, деталь может иметь конструктивные различия без изменения атрибутов (ее наименования, обозначения и т.д.). Вопрос решается с помощью извещений об изменении, в которых конкретно указывается, какие происходят изменения в чертеже и на какие комплекты они распространяются. В этом случае зачастую приходится разрабатывать различные варианты технологических процессов.
Данная проблема реально существует в заготовительном производстве машиностроительных предприятий, в частности, при разработке технологической документации для кузнечно-штамповочных цехов. Различные варианты технологических процессов могут понадобиться из-за отсутствия заготовок нужного профиля, временного выхода из эксплуатации оборудования с его заменой и при необходимо-
сти учета изменений в чертежах деталей. Таким образом, требование учета многовариантности при разработке технологических процессов ставит перед создателями САПР задачи наполнения проектирующих систем элементами управления документооборотом, в том числе перевода разработанных вариантов технологической документации в архивное или актуальное состояние.
1. Рассмотрим постановку задачи актуализации и архивирования объектов проектирования и ее решение на примере разработки технологических процессов для ковки поковок типа ступенчатых валов (см.: Коновалов А.В., Арзамасцев С.В., Муйземнек О.Ю. и др. Новые принципы разработки САПР ТП ковки. // Куз-нечно-штамповочное производство. - 2007. - № 1).
Чертеж одной и той же по наименованию и обозначению детали как входной документ для САПР ТП ковки может иметь разное функциональное наполнение, например, различные варианты могут отличаться размерами или марками материалов (сталей, сплавов). На каждый вариант детали в общем случае могут быть спроектированы различные поковки. На заключительном этапе разработки техпроцесса на каждую поковку могут быть спроектированы различные варианты технологических процессов. Следовательно, на одно и то же обозначение детали требуется хранить в базе данных множество вариантов этой детали, множество поковок и карт технологических процессов. При таком многообразии вариантов часть из них должна находиться в актуальном состоянии, а часть передана в архив. В действительности данная ситуация характерна для мелкосерийного производства, в котором изделия выпускаются мелкими партиями в различной комплектации с сохранением обозначений входящих в сборки деталей.
Таким образом, задача заключалась в формулировании и разработке способов организации данных о деталях, поковках и техпроцессах, позволяющих вести учет и корректное изменение их текущего состояния.
Для решения этой задачи и всего программного обеспечения в целом использован объектно-ориентированный подход. Выделены три основных класса объектов проектирования: детали, поковки и техпроцессы. Информационная связь рассматриваемых объектов представляет собой трехъярусные деревья (рис. 1). Общее число вариантов объектов одного
О б о з н а ч е н и я Классы объектов
5? т т
СО - С X Детали (варианты)
<4 - Ь со с £ - Поковки (варианты)
с 1- ь Техпроцессы (варианты)
Рис. 1. Трехъярусные деревья связей вариантов проектирования
обозначения выражается суммой листьев данного дерева.
Каждый вариант объекта согласно разработанной концепции может находиться в одном из четырех состояний: актуальном, архивном, аннулированном, удаленном (рис. 2). К актуальному состоянию относится документация на изделия, находящиеся в текущий момент в стадии изготовления. К архивному можно отнести документы на временно снятые с производства или перспективные разработки, ждущие своей очереди. К аннулированному относится документация на изделия, окончательно снятые с производства или переданные в другие организации, но продолжающие храниться в базе данных. К удаленному относятся объекты, которые физически стираются из базы данных.
Объект (деталь, поковка, техпроцесс)
1-й вариант объекта
Актуальный
И
Архивный
I
Аннулированный
Удаленный
Рис. 2. Ориентированное дерево состояний объектов.
Примечание: стрелками показаны возможные переходы состояний объектов
Проблема состоит в том, чтобы для всего множества объектов, включающего детали, поковки и техпроцессы, создать правила для корректного перевода их из одного состояния в другое. Для выработки правил перевода введена иерархия объектов проектирования от родительских к дочерним. Она базируется на последовательности порождения одним объектом другого и наследовании дочерними объектами свойств родителей. Объект деталь порождает объект поковка, а объект поковка является родительским по отношению к объекту техпроцесс. Каждый дочерний объект не может существовать без своего порождающего объекта. Но каждый порождающий объект может существовать без порождаемых им дочерних объектов. В аналогичной иерархической последовательности выстроены состояния объектов от высшего актуального состояния к низшему удаленному состоянию (см. рис. 2).
Для формализации алгоритмов перевода состояний классы объектов и состояний представлены в виде трехмерной модели (рис. 3). Разработанная модель реализует структуру данных и управление ходом вычислительного процесса с помощью данных. Условно модель показана в виде параллелепипеда, состоящего из горизонтальных и вертикальных слоев наподобие известной игрушки кубик Рубика. Фронтальные вертикальные слои представляют набор объектов проектирования всех трех классов (детали,
Актуальные
О —ги- •
О'
Рис. 3. Трехмерная модель состояний вариантов объектов проектирования
поковки, техпроцессы) всех четырех состояний с одинаковым обозначением и номером варианта. Профильные вертикальные слои представляют собой множество объектов только одного класса, но для всех состояний и вариантов. Горизонтальные слои объединяют множество вариантов объектов всех классов по признаку нахождения в одном из четырех возможных состояний. Из-за того что число вариантов деталей не равно числу вариантов поковок, а число вариантов поковок не равно числу вариантов техпроцессов, в модели могут отсутствовать отдельные элементарные столбики (см. рис. 3). Таким образом, каждый параллелепипед можно считать экземпляром информационной модели объектов и состояний для самого старшего родительского объекта -детали, идентифицирующимся в пространстве всех деталей своим обозначением или номером чертежа. Все информационное пространство можно представить в виде комплекта сотен и тысяч параллелепипедов в зависимости от числа деталей, участвующих в информационном процессе.
После иерархического упорядочения классов объектов и их состояний стал очевидным основной принцип перевода состояний, заключающийся в том, что любой объект дочернего класса не может иметь состояние более высокого порядка, чем его родитель. Например, поковка не может быть в актуальном состоянии, если порождающая ее деталь находится в архиве. С другой стороны, поковка не может быть аннулирована, если технологическая карта на нее находится в актуальном состоянии или в архиве.
Технология программной реализации основывалась на методе программирования таблиц решений. Наличие кружка в слое параллелепипеда «объект-состояние» соответствует ситуации истинности условия «Объект < деталь I поковка I техпроцесс > находится в состоянии < актуальном I архивном I аннулированном I удаленном>». Попытка перевода объекта в другое состояние является событием, которое инициирует обработчик проверки условий таблицы решений. При выполнении определенного условия вызывается метод, переводящий другие объ-
екты того же наименования и обозначения в состояния, соответствующие новому состоянию исходного объекта. Например, при попытке перевести деталь из актуального состояния в архив (см. рис. 3) проверяется состояние дочернего объекта - поковки. Так как поковка находится в более высоком состоянии (актуальном), она переводится в архив. Перевод поковки в архив инициирует метод проверки состояния техпроцесса. Поскольку техпроцесс является актуальным, он также переходит в архив. В результате все объекты переведутся в архивное состояние.
Рисунок 4 иллюстрирует возможные дальнейшие изменения состояний объектов. Поковка не может быть переведена в актуальное состояние, поскольку объект родительского класса (деталь) находится в архиве (стрелка вверх перечеркнута). Но поковка может быть аннулирована, если предварительно техпроцесс был удален (аннулирован) из информационного пространства, как показано во втором и третьем профильных слоях модели.
Если построить график зависимости функции-состояния от аргумента-объекта, то данная ступенчатая функция должна быть невозрастающей. На основе этого принципа были выработаны два правила, реализованные в САПР ТП ковки валов:
1) перевод объектов проектирования в более низкие состояния нужно начинать с последних дочерних объектов;
2) перевод в более высокие состояния нужно начинать с родительских объектов.
Разработанное на основе данных правил программное обеспечение автоматически следит за соответствием иерархии состояний в объектах проектирования и в случае некорректных действий со стороны пользователя выдает предупреждения или запрещает неправильный перевод состояний. Исходя из того, что конечным документом, используемым в производственном подразделении, является карта технологического процесса, было решено, что в актуальном состоянии может находиться только один вариант техпроцесса. Поэтому при проектировании второго варианта техпроцесса на одну и ту же по обозначению и номеру варианта поковку система автоматически переводит ранее разработанный техпроцесс в состояние архива, выдавая при этом соот-
Рис. 4. Возможные переводы состояний объектов проектирования
ветствующее предупреждение. Данная функция, как и ряд других задач, реализована непосредственно в базе данных с помощью триггеров.
Предлагаемые методы позволяют внедрить в локальные САПР ТП элементы управления документо-
оборотом, аналогичные большим PDM/PLM системам, и сформировать предпосылки для более эффективной интеграции локальных САПР в общую структуру единого информационного пространства предприятия.
ВСПОМОГАТЕЛЬНЫЕ ВЕЩЕСТВА ДЛЯ ПРОИЗВОДСТВА ТВЕРДЫХ ЛЕКАРСТВЕННЫХ ФОРМ
Н.В. Меньшутина, д.т.н.; А.И. Козлов; Е.А. Ершова; А.О. Касимова
(РХТУ им.. Д.И. Менделеева, г. Москва)
Создание свободно интегрируемых баз знаний как компонентов различных комплексных информационных систем сегодня является актуальной задачей программирования. Подобные компоненты, разработанные отдельно, могут существенно расширить функциональные возможности комплексных информационных систем, таких как системы информационного менеджмента предприятий, в том числе и фармацевтических.
Одним из важнейших направлений фармацевтической отрасли является расширение ассортимента высокоэффективных таблетированных лекарственных препаратов, составляющих около 50 % от общего объема производства готовых лекарственных средств. В состав любого такого препарата входят вспомогательные вещества. Их роль не ограничивается образованием лекарственной формы и обеспечением ее стабильности: вспомогательные вещества влияют как на технологические параметры таблеток, так и на биологическую доступность лекарственных средств. Собственная фармакологическая активность вспомогательных веществ, как правило, незначительна по сравнению с активностью лекарственного вещества.
Вспомогательные вещества в таблеточном производстве предназначены для придания таблеточной массе необходимых технологических свойств, обеспечивающих точность дозирования, механическую прочность, распадаемость и стабильность таблеток в процессе хранения.
Простой и быстрый доступ к актуальной информации о вспомогательных веществах, их свойствах, производителях и поставщиках важен для сотрудников службы снабжения предприятий, технологов и персонала исследовательских лабораторий предприятия.
При разработке новой лекарственной формы технолог сталкивается с проблемой выбора вспомогательных веществ из широкого ассортимента, представленного на рынке. Задача выбора осложняется наличием огромного числа синонимов и различных марок определенного компонента.
Данная статья посвящена разработке и созданию единого систематизированного источника
данных о вспомогательных веществах, их свойствах, производителях и поставщиках, который существенно облегчит задачу поиска вспомогательных веществ и ускорит процесс разработки конечной лекарственной формы.
Специфика применения информации и особенности ее использования требуют достаточной гибкости данного информационного модуля при интеграции с другими информационными системами. Примерами подобных информационных систем в химико-фармацевтической промышленности являются системы глобальной автоматизации и управления, такие как ERP или LIMS.
В ходе работы были определены следующие этапы разработки информационного модуля:
• систематизация и классификация информации о вспомогательных веществах, используемых в производстве твердых лекарственных форм, об их применении и свойствах;
• создание эффективной модели хранения данных;
• разработка механизма интеграции базы знаний в информационные системы, а также механизма поддержания актуальности и обновления информации.
Модель хранения данных
На этапе проектирования была создана концептуальная модель информационного модуля. Для этого проведен тщательный анализ информации о вспомогательных веществах.
В первую очередь вспомогательные вещества были разделены на группы согласно выполняемым функциям, например, наполнители, связывающие вещества, разрыхляющие вещества и т.д.
На втором этапе выделены физические, химические и физико-химические свойства веществ, а также в базе знаний отражена информация об их размерностях.
Отдельно была проанализирована информация о производителях и поставщиках химических веществ.
Часть концептуальной модели и структуры организации информации о вспомогательном веществе представлена на рисунке 1.
