CC BY
109
ду ПК и микросхемой авторы использовали драйвер WinUSB [7, 8]. С его помощью можно достаточно просто и быстро реализовать пользовательское приложение в ОС Windows для работы с СнК К1867ВЦ3АФ через интерфейс USB. Драйвер состоит из двух частей: функциональный драйвер WinUsb.sys, а также библиотека WinUsb.dll, содержащая набор функций WinUSB API.
Приведем список некоторых функций WinUSB API: GetDevicePath - получение дескриптора устройства с применением его GUID, WinUsb_Initiali-ze - инициализация WinUSB-устройства, WinUsb_ ControlTransfer - передача управляющего пакета, WinUsb_WritePipe - запись данных в указанную конечную точку, WinUsb_ReadPipe - чтение данных из конечной точки (подробнее см. [8]).
Пользовательское приложение может взаимодействовать с драйвером WinUsb.sys через функции WinUSB API. Демонстрационное приложение написано в среде Microsoft Visual Studio .NET 2008 на языке С#.
Следует отметить, что используемый драйвер имеет несколько недостатков: доступ к устройству возможен только со стороны одного приложения, драйвер не поддерживает изохронные передачи данных. Если для пользователя это критично, необходимо написать специальный драйвер, используя Windows Driver Model.
Таким образом, создан аппаратно-программный комплекс, состоящий из СнК К1867ВЦ3АФ, ПК и ПО, позволяющий обмениваться информацией на скорости до 480 Мбит/с.
Литература
1. Микросхемы интегральные 1867ВЦ3Ф. Техническое описание. URL: www.niiet.ru/product/product.htm (дата обращения: 31.07.2012).
2. Попов С.О., Крюков В.П., Данильченко Н.В. Двухпроцессорная СБИС СнК К1867ВЦ3АФ // МЭС 2011: сб. тр. С. 7378.
3. Universal Serial Bus Specification Revision 2.0. URL: www.usb.org (дата обращения: 31.07.2012).
4. USB 2.0. Transceiver Macrocell Interface (UTMI) Specification. Intel Corp, URL: www.intel.com (дата обращения: 31.07.2012).
5. USB3250, Data Sheet, SMSC. URL: www.smsc.com (дата обращения: 31.07.2012).
6. Айгуров П.В. Интерфейс USB. Практика использования и программирования. СПб, БХВ-Петербург, 2004. 576 с.
7. Конарев М.В. Опыт создания USB 2.0 устройства на основе системы на кристалле К1867ВЦ3АФ // Современные проблемы информатизации: сб. тр. междунар. открытой науч. конф. Воронеж: Научная книга, 2012. Вып. 17. С. 305-308.
8. How to Use WinUSB to Communicate with a USB Device., URL: http://www.microsoft.com/whdc/connect/usb/winusb howto.mspx (дата обращения: 31.07.2012).
References
1. 1867VTS3F Integrated microcircuits. Technical manual, available at: www.niiet.ru/product/product.htm (accessed 31 July 2013).
2. Popov S.O., Kryukov V.P., Danilchenko N.V., Sbornic trudov konf. MES 2011 [Proc. of MES 2011 conf.], pp. 73-78.
3. Universal Serial Bus Specification Revision 2.0, available at: www.usb.org (accessed 31 July 2013).
4. USB 2.0. Transceiver Macrocell Interface (UTMI) Specification. Intel Corp., available at: www.intel.com (accessed 31 July 2013).
5. USB3250. Data Sheet. SMSC, available at: www.smsc. com (accessed 31 July 2013).
6. Aigurov P.V., Interfeys USB. Praktika ispolzovaniya i programmirovaniya [USB interface. Using and programming], SPB, BHV-Peterburg, 2004.
7. Konarev M.V., Sovremennye problemy informatizatsii: sbornik trudov otkrytoy nauchnoy konf. (Modern problems of informatization: proc. of openscientific conf.), Voronezh, 2012, pp. 305-308.
8. How to Use WinUSB to Communicate with a USB Device, available at: http://www.microsoft.com/whdc/connect/usb/ winusb_ howto.mspx (accessed 31 July 2013).
УДК 002.53(+004.62/.63.65)
РАЗРАБОТКА МОДЕЛИ ДАННЫХ ИНФОРМАЦИОННОЙ СИСТЕМЫ ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА ИЗДЕЛИЙ ДЛЯ ЗАДАЧ КОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
А.А. Вичугова, аспирант (Национальный исследовательский Томский политехнический университет, просп. Ленина, 30, г. Томск, 634050, Россия, [email protected])
В статье дается понятие объектов проектирования, описаны их взаимосвязь и компонентный состав применительно к задачам космического приборостроения. Рассмотрены информационные системы и технологии для поддержки процессов проектирования изделий. Показана схема структурированного хранения разнородных информационных сущностей в системе управления данными. Рассмотрены аспекты концептуального проектирования модели данных информационной системы для поддержки жизненного цикла изделия, включая интеграцию с системами автоматизированного проектирования. Учтена необходимость электрического и механического проектирования приборов. Определены классы модели данных, которые позволяют описать состав и отношения объектов проектирования. Разработана UML-диаграмма, иллюстрирующая иерархию и взаимосвязь типов объектов проектирования на примере радиоэлектронной аппаратуры. Предложена модель хранения проектных данных об изделии в системе управления данными Enovia SmarTeam, позволяющая реализовать управление жизненным циклом изделия и связанных с ним информационных сущностей.
Ключевые слова: проектирование радиоэлектронных приборов, управление жизненным циклом изделия, информационная модель изделия, конструкторская документация, объектно-ориентированный подход, модель данных.
DATA MODEL DEVELOPING OF INFORMATION SYSTEM TO SUPPORT LIFECYCLE OF AEROSPACE ELECTRONIC DEVICES
Vichugova A.A., postgraduate (National Research Tomsk Polytechnic University, LeninaAv., 30, Tomsk, 634050, Russia, [email protected]) Аbstract. The article describes the concept of design objects, their correlation and the component structure in relation to the space instrumentation problems. Information systems and technologies to support the processes of product design are considered. The scheme of diverse information entities structured storage in the data management system is shown. The aspects of the conceptual design of a information system data model to support the product life cycle, including integration with CAD systems are supplied. The article conseders the need of electrical and mechanical engineering equipment, the classes of data models allowing describing the composition and the relationship of design objects. The UML-diagram that illustrates the hierarchy of object types and relationship of design as an example of electronic equipment is developed. The example of developed model applying to the design data storage in PLM-system Enovia SmarTeam is described.
Keywords: of electronic devices design, product lifecycle management, digital mockup, design documentation, object oriented approach, data model.
Проектирование приборов, в частности радиоэлектронной аппаратуры (РЭА), - это совокупность технологически сложных процессов, которые характеризуются высоким уровнем применения современных информационных систем и технологий, а также взаимодействием большого количества различных специалистов (схемотехники, конструкторы, топологи и др.).
Главным результатом проектирования является конструкторская документация, необходимая для производства новой продукции. Кроме того, в настоящее время состав комплекта конструкторской документации дополняется его электронной моделью, которая используется для получения чертежей и должна содержать полный набор конструкторских и физических параметров, необходимых для выполнения расчетов и математического моделирования. Однако проектирование включает в себя не только разработку массогабаритных свойств изделия посредством его электронной модели, но и определение других характеристик, необходимых для производства и эксплуатации изделия, например электромагнитных параметров и пр. Для моделирования, расчетов и анализа применяются САПР. Разрабатываемый в САПР виртуальный образец продукции называется информационной моделью изделия (ИМИ). Согласно ГОСТ 2.053-2006, ИМИ является источником данных для формирования конструкторской документации, необходимой для производства продукции. Фактически ИМИ представляет собой файл формата САПР для описания каких-либо свойств изделия. Например, твердотельная ИМИ, созданная в САПР SolidWorks, используется на этапе механического проектирования изделия; ИМИ для описания электрических свойств изделия может представлять собой набор файлов проекта, разработанного в САПР Altium Designer, и т.д. Кроме того, ИМИ отражает состав изделия с точки зрения иерархической совокупности его составных частей, которую принято называть электронной структурой изделия (ЭСИ).
Таким образом, ИМИ является первичным документом для получения ЭСИ и различных конструкторских документов. Например, спецификация, один из самых важных конструкторских документов, необходимых для производства изделия, формируется на основе ЭСИ и данных из информационных моделей, разработанных в различных САПР. Изменение ИМИ влечет изменение конструкторской документации. Поскольку функции интерактивного проектирования и инженерных расчетов реализуются в ИМИ, основным назначением конструкторской документации становится статическое представление информации об изделии по ГОСТ 2.102-68.
Обобщая понятия создаваемых в процессе проектирования сущностей (изделие, ИМИ, ЭСИ, конструкторская документация), примем единый термин для их обозначения. Рекомендуется использовать понятие «объект проектирования» [1]. Таким образом, далее под этим термином подразумеваются проектируемое изделие, его информационные модели и конструкторские документы, необходимые для его производства.
Взаимозависимость разнородных объектов проектирования обусловила появление проблемы структурированного хранения информационных сущностей, которые описывают их. Цель настоящей статьи - формализация структуры хранения информации об объектах проектирования для ее последующей программной реализации. Для этого предлагается использовать аппарат теории множеств и положения объектно-ориентированного подхода, что позволит выполнить концептуальное проектирование программной системы управления информацией об изделии.
Информационные системы и технологии для поддержки процессов проектирования изделий
Для структурированного хранения информации об изделии применяются информационные
технологии поддержки жизненного цикла продукции, которые принято называть PLM (Product LifeCycle Management). Центральное место в PLM-технологиях занимает информационная система управления данными (СУД) о продукции. Кроме структурированного хранения информации об изделии, для реализации полноценного управления данными СУД должна поддерживать интеграцию с другими программными средствами, использующимися для поддержки жизненного цикла изделия, в частности САПР.
Существует множество готовых программных продуктов от крупнейших российских и мировых компаний-разработчиков ПО (ENOVIA, Smar-Team, Вертикаль, Lotsia PLM, Oracle PLM, Wind-chill, SAP PLM, TeamCenter, T-FLEX DOCs, ЛОЦ-MAH:PLM, 1C: PDM 2.0). Однако несмотря на множество решений для различных отраслей промышленности, остается актуальной задача настройки правил хранения и управления информацией в СУД к специфике предметной области, включая особенности предприятия. В частности, изделия космического приборостроения разрабатываются в нескольких вариантах - для каждой стадии испытаний наземно-экспериментальной отработки, например, лабораторно-отработочных, конструкторско-доводочных и т.д. Аналитический обзор существующих СУД не выявил готовых программных решений для специфики отрасли космического приборостроения, которая включает проектную организацию деятельности, сложную структуру взаимосвязей объектов проектирования и взаимозависимую динамику изменения их жизненного цикла. Поэтому адаптация СУД к решению этих задач имеет высокую практическую значимость.
В СУД предусмотрены логическое разделение информационных сущностей и представление их в виде структурированной совокупности однотипных объектов, например, дерево проектов, дерево изделий, дерево документов, дерево элементов, дерево материалов и т.д. При этом все информационные сущности, относящиеся к одному изделию, связаны между собой.
На рисунке 1 показана взаимосвязь объектов проектирования. Например, Проект_2 из существующего множества проектов сопровождается набором документов, объединенных в дерево документов. В рамках Проекта_2 осуществляется разработка Изделия_1, которое состоит из множества Элементов, образующих структуру изделия. Информация об Изделии_1 фиксируется в связанном с ним Документец.
Согласно [2], правила хранения и обработки информации в информационной системе задаются ее схемой (моделью) данных. В свою очередь, зависимости между объектами проектирования, показанные на рисунке 1, позволяют выделить типы рассматриваемых сущностей. Структуризация ти-
пов объектов в соответствии с положениями объектно-ориентированного подхода является начальным этапом концептуального проектирования модели данных информационной системы [3]. Рассматривая эту модель с позиции объектно-ориентированного подхода, видим, что семантическая типизация информационных сущностей соответствует выделению объектов с одинаковым поведением в классы с одним набором характеристик-атрибутов. Таким образом, схема данных является объектной моделью, которая описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами.
Концептуальное проектирование модели данных СУД
Для управления жизненным циклом объектов проектирования в модели данных СУД необходимо предусмотреть следующие классы объектов: «Проекты», «Изделия», «ЭСИ», «Документы». При этом между данными классами существуют определенные отношения:
- в рамках одного проекта может выполняться разработка одного или более изделий;
- для одного изделия может существовать множество вариантов его электронной структуры;
- к одному проекту может относиться множество документов;
- ЭСИ и ее составные части описываются одним (или более) документом;
- к одному изделию может относиться один (или более) документ.
Рис. 1. Схематичное представление иерархии и взаимосвязи информационных сущностей объектов проектирования в PLM-системе в виде структурированных деревьев
Рассматривая специфику прикладной области, следует детализировать состав ЭСИ. В ГОСТ 2.101-68 устанавливаются следующие виды изделий: детали, сборочные единицы, комплексы и комплекты. Между ними существуют отношения:
- в состав сборочной единицы могут входить детали, комплекты и другие сборочные единицы;
- комплект может состоять из деталей, сборочных единиц и других комплектов;
- в комплекс могут входить детали, сборочные единицы, комплекты, а также другие комплексы.
Кроме того, согласно выделению разделов спецификации по ГОСТ 2.106-96, изделия и их составные части также принято делить на стандартные, прочие и материалы, непосредственно входящие в специфицируемое изделие, иногда их называют «изделия из материалов».
Стандартные изделия используются по межгосударственным, государственным и отраслевым стандартам, а также стандартам предприятий; прочие - по техническим условиям, а импортные - по сопроводительной технической документации зарубежных изготовителей (поставщиков).
В рамках данной классификации электрора-диоизделия (ЭРИ), которые являются основой РЭА, относятся к прочим изделиям. Учитывая компонентный состав ЭСИ, следует согласно принципу подстановки [4] объявить данный класс базовым (суперклассом). Его подклассами будут составные части изделия по ГОСТ 2.106-96, ГОСТ 2.108-68, ГОСТ 2.112-70: «Стандартное изделие», «Комплект», «Деталь», «Сборочная единица», «Прочее изделие», «Изделие из материала». При этом между данными подклассами суперкласса «ЭСИ» существуют следующие отношения:
- к одному экземпляру класса «Комплект» может относиться множество экземпляров классов «Деталь», «Сборочная единица», «Стандартное изделие», «Комплект»;
- к одному экземпляру класса «Сборочная единица» может относиться множество экземпляров классов «Деталь», «Сборочная единица», «Прочее изделие», «Изделие из материала», «Стандартное изделие».
Каждый элемент ЭСИ описывается совокупностью данных из файлов его информационных моделей, разработанных в САПР при механическом и электрическом проектировании. По технологии проектирования РЭА этап электрического проектирования, на котором решаются задачи схемотехнического и радиотехнического характера, предшествует этапу механического моделирования, на котором рассматриваются конструктивные и теплотехнические вопросы.
Специфика приборостроения определяет неоднородный состав множества ИМИ, которое включает подмножества информационных моделей, разработанных в различных САПР при электриче-
ском и при механическом проектировании. Однако в космическом приборостроении не все составные части изделия подлежат электрическому моделированию, некоторые детали создаются только на этапе механического конструирования, например крепежные элементы. В свою очередь, все ЭРИ, помимо электрических характеристик, моделирование которых осуществляется с помощью электрических САПР, имеют конструктивное воплощение (корпус), пространственные параметры которого являются объектом моделирования в механических САПР.
Отличия механического и электрического проектирования позволяют сделать вывод о необходимости объявления классов, объекты которых будут использоваться для описания информационной модели изделия с точки зрения механического и электрического проектирования соответственно. Кроме того, одной из особенностей механического проектирования является компонентный состав трехмерной модели: сборка включает множество подсборок и деталей. Аналогично организован компонентный состав модели изделия с точки зрения электрического проектирования: проект модели представляет собой набор ссылок на структурированную совокупность электрических схем, печатных плат и программного кода.
Таким образом, применительно к исследуемой специфике космического приборостроения на этапе концептуального проектирования СУД класс «ИМИ» следует объявить абстрактным, потомками которого будут два базовых класса: MCAD (Mechanical Computer Aided Design), используемый для хранения сущностей механического проектирования, которыми являются файлы, экспортированные в СУД из соответствующих САПР; ECAD (Electrical Computer Aided Design), используемый для хранения сущностей электрического проектирования, которыми являются файлы, экспортированные в СУД из соответствующих САПР.
В свою очередь, классы MCAD и ECAD имеют потомков, при этом между данными классами существуют следующие отношения: MCAD_As-sembly, используемый для хранения сборки, с которой ассоциируется множество экземпляров классов сборки MCAD_Assembly и деталей MCAD_Part; ECAD_Project, используемый для хранения проекта, с которым ассоциируется множество экземпляров класса входящих в него файлов электрических схем, печатных плат, программного кода ECAD_File.
Поскольку фактически ИМИ и конструкторская документация являются документами, целесообразно объявить класс «Документы» абстрактным суперклассом, потомками которого будут суперклассы «конструкторская документация» и «ИМИ». В свою очередь, ГОСТ 2.102-68 регла-
ментирует состав основного и полного комплектов конструкторской документации, которые включают множество отдельных текстовых, табличных и графических документов. Однако в связи с большим количеством документов в составе конструкторской документации на этапе концептуального проектирования БД СУД целесообразно не детализировать потомков данного базового класса. Поскольку первоисточником данных для конструкторских документов является совокупность файлов САПР, импортированных в СУД, следует отметить, что один экземпляр класса «конструкторская документация» может ассоциироваться с множеством экземпляров класса «ИМИ».
Кроме того, следует учитывать, что в реальности каждый элемент изделия выполняется из одного или целого набора материалов. В свою очередь, каждый материал может описываться одним или несколькими документами. Следовательно, целесообразно выделить суперкласс «Материалы» и связать его с суперклассами «ЭСИ» и «Документы», используя следующие отношения ассоциации:
- каждый экземпляр суперкласса «ЭСИ» может быть связан с множеством экземпляров суперкласса «Материалы»;
- каждый экземпляр суперкласса «Материалы» может быть связан с множеством экземпляров суперкласса «Документы».
Суперкласс «Материалы» может быть детализирован на подклассы, однако в связи с большим
количеством типов материалов на этапе концептуального проектирования БД СУД целесообразно не детализировать потомков данного базового класса.
Описанные взаимосвязи объектов проектирования и их компонентный состав можно формализовать с помощью языков графического моделирования. Одним из наиболее часто используемых в сфере программной инженерии языков моделирования является UML, который предоставляет широкие возможности для разработки алгоритмического базиса ПО и БД [5]. На рисунке 2 показана диаграмма классов модели данных СУД, составленная на основе вышеописанных взаимосвязей объектов проектирования и их компонентного состава.
Поскольку диаграмма классов с концептуальной точки зрения описывает модель предметной области [5], в ней присутствуют только те классы, которые описывают объекты проектирования (конструкторская документация, ИМИ, ЭСИ, Изделия) и связанные с ними сущности (Проект, Материал). Данная диаграмма описывает иерархию, состав и взаимосвязь объектов проектирования космического приборостроения. Кроме того, статическая структурная диаграмма позволяет формализовать отношения кратности между классами. Это используется на дальнейших этапах проектирования БД СУД, в частности, при определении отношений между сущностями в случае наиболее часто применяемой реляционной модели данных [3].
Стандартное из£ «елие
7СТ
7Т
£
ж
КД *- ИМИ
1
£
МСАР
г
т
МСА0_Аз5етЫу
К
ЕСАО_Рг<че<Л
Рис. 2. UML-дuаграмма классов модели данных СУД
Предложенная структура хранения проектных данных была реализована в СУД Enovia Smar-Теат, БД которой основана на объектно-реляционной модели. Для практического применения разработанной структуры взаимосвязи объектов проектирования рассмотрим пример выполнения проекта по разработке изделия «Блок электронный устройства поворота батареи солнечной». Данное изделие является составной частью космического аппарата (КА), поэтому его разработка фактически является одной из задач в составе комплекса работ по проектированию КА. В разработанной модели данных СУД Enovia SmarTeam экземпляр класса «Проект» является ключевым объектом, который обеспечивает семантическую связь между разнотипными сущностями (изделием, элементами его электронной структуры, документами) с помощью ссылок. Таким образом, проект представляет собой портфель данных о предмете разработки, а экземпляр класса «Проект» - контейнер для структурированного хранения информации о временных, стоимостных и качественных ограничениях (параметрах) работ. Под качественными характеристиками проекта по разработке изделия следует понимать соответствие разрабатываемого объекта требованиям технического задания.
Таким образом, целевым результатом проекта по разработке изделия является непосредственно само изделие. Поэтому с экземпляром класса «Проект», который хранит сведения общего характера о разрабатываемом изделии, связан экземпляр класса «Изделие», предназначенный для структурированного хранения обобщенной технической информации о проектируемом изделии, такой как, например, наименование, массогабарит-ные характеристики, функциональное назначение и т.д. Все эти данные являются значением атрибутов класса «Изделие». Поскольку специфика космического приборостроения предполагает одновременное существование нескольких вариантов изделия (на каждую стадию испытаний, например, лабораторно-отработочных, конструкторско-дово-дочных и т.д.), для отслеживания степени завершения проектирования на этих стадиях в разработанной модели данных СУД Enovia SmarTeam для класса «Изделие» введен соответствующий атрибут.
Компонентный состав разных версий изделия для каждой стадии испытаний реализуется с использованием объектов класса «ЭСИ». В разработанной модели данных СУД Enovia SmarTeam на верхнем уровне абстракции компонентный состав изделия аккумулируется объектом класса «Сборочная единица».
На рисунке 3 показаны иерархическая структура дерева проектов и взаимосвязь объектов различных классов в СУД Enovia SmarTeam, модель данных которой основана на типизации объектов согласно разработанной UML-диаграмме классов
(рис. 2). Разработка изделия выполняется в рамках проекта, являющегося хранилищем всех связанных с изделием информационных сущностей: ИМИ, конструкторской документации и элементов ЭСИ. К экземпляру класса «Проект» присоединен экземпляр класса «Изделие»; к нему, в свою очередь, относятся несколько экземпляров класса «Сборочная единица» (ЭСИ), среди дочерних элементов которых показаны экземпляры классов «Прочие изделия» и «Детали».
Элементы ЭСИ подробно описаны в связанных с ними экземплярах классов «Документы», в файлах ИМИ и конструкторской документации, содержание и состояние которых определяют состояние объектов класса «ЭСИ».
Таким образом, в модели данных СУД Enovia SmarTeam, основанной на разработанной UML-диаграмме классов, не только осуществляется структурированное хранение информации об изделиях, формализованной в виде документов (ИМИ и конструкторской документации), но и визуализируется электронная структура изделия, которая используется в том числе для автоматической генерации некоторых конструкторских документов. Кроме того, большое внимание уделено поддержке версионности: объекты (ИМИ, конструкторская документация, изделие и элементы его электронной структуры) могут иметь различные версии, отражающие степень разработки или испытаний.
На основании изложенного можно сделать следующие выводы. В результате исследований предложено понятие объектов проектирования космического приборостроения, а также проанализирован их структурный состав, который формализован в виде ЦМЬ-диаграммы классов.
Разработанные модели позволяют формализовать взаимозависимости объектов проектирования и фактически являются алгоритмической основой для разработки программного обеспечения управления информацией о продукции, в частности, для разработки модели данных СУД в рамках PLM-решения.
Созданная UML-диаграмма классов модели данных СУД нашла практическое применение при настройке СУД Enovia SmarTeam к задачам
Проекты:
РгчесЬ Т|ее
□ 3 Разработка КА серии К21 -134 выполи»«« и 3 Разработка КА серии М115-11 выполнен Ц Разработка КА серии ГЛОНАСС приостановлен В □ 21 Разработка КА серии М-72 выполнение
В и2 Разработка модуля служебных систем выполнение
В С] 71 Разработка системы ориентации солнечных батарей выполнение В1-1Сг1 Разработка устройства поворота батареи солнечной выполнение В □ 72.0-0 Устройство поворота батареи солнечной в разработке В О 3 Разработка блока электронного устройства поворота батареи солнечной выполнение. Б и 72 0-1 Блок электронный устройства поворота батареи солнечной в разработке ЛОИ В ц] 708.20-10 Рамка с платами ЛОИ д 34203.320Микросхема О М1У Д01
сборочная единица
J ДиойЗД713В ^ 606.30-5Трансформатор ЛОИ J Шайба С 1.4,1.11 ГОСТ 1045 78 _] _ Проволока ММ-5 ТУ1§ 5.492-25
И в разработке УД01
в разработке | г-25М5мм ^
элементы ЭСИ (прочие изделиял детали)
Рис. 3. Дерево проектов PLM-сuстемы Enovia SmarTeam со ссылками на экземпляры класса «Изделия» и «ЭСИ»
ОАО «Информационные спутниковые системы» имени академика М.Ф. Решетнева (г. Железно-горск, Красноярский край). Однако общие положения относительно иерархии классов и связей объектов проектирования, описанные в работе, могут быть использованы при настройке и внедрении практически любой СУД в процессы проектирования и производства изделий различных отраслей промышленности.
Литература
1. Боргест Н.М. Онтология проектирования: теоретические основы. Понятия и принципы: учеб. пособие. Самара: Изд-во СГАУ, 2010. Ч. 1. 88 с.
2. Дейт К.Дж. Введение в системы баз данных = Introduction to Database Systems М.: Вильямс, 2006. 8-е изд. 1328 с.
3. Кузнецов С.Д. Основы баз данных. М.: ИНТУИТ; БИНОМ. Лаборатория знаний, 2007. 2-е изд. 484 с.
4. Liskov B., Program development in Java: Abstraction, specification and object-oriented design, 2001.
5. Фаулер М., Скотт К. UML. Основы; [пер. с англ.]. СПб: Символ-Плюс, 2002. 192 с.
References
1. Borgest N., Ontologiya proektirovaniya: teoreticheskie osnovy. Ponyatiya i printsipy: ucheb. posobie [Design ontology: theoretical foundations. Concepts and Principles: study guide], SSAU Publ., 2010.
2. Date C.J., Introduction to Database Systems, 8th ed., Ad-dison-Wesley, 2006.
3. Kuznetsov S., Osnovy baz dannykh [Foundations of databases], 2nd ed., Moscow, INTUIT, BINOM, Laboratoriya Znaniy, 2007.
4. Liskov B., Program development in Java: Abstraction, specification and object-oriented design, Addison-Wesley Professional, 1st ed., 2001.
5. Fowler M., Scott K., UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd ed., Addison-Wesley, 2000.
УДК 004.7
КОРПОРАТИВНАЯ МУЛЬТИСЕРВИСНАЯ СЕТЬ БАНКА. ПРИМЕР ПОСТРОЕНИЯ
Ю.М. Лисецкий, к.т.н., генеральный директор (Компания «ЭС ЭНД ТИ УКРАИНА», просп. Академика Палладина, 44а, г. Киев, 03680, Украина, [email protected])
Статья посвящена построению мультисервисных сетей, которые сегодня являются основой ИТ-инфраструктуры, практически любой организации корпоративного уровня, имеющей территориально распределенную структуру. Дано определение мультисервисной сети, сформулированы требования к современным корпоративным мультисервис-ным сетям, соответствующей им инфраструктуре и функциональности систем. Описаны основные компоненты мультисервисной сети и их назначение. Приведена топология ее построения. Рассмотрены принципы, требования и подходы к построению корпоративной мультисервисной сети банковского учреждения и интеграция в нее контакт-центра. Приведена последовательность задач, решаемых в ходе их интеграции. Описан пример построения корпоративной мультисервисной сети для ВТБ Банка в Украине: состояние проблемы, постановка задачи, разработка решения и проектирование, этапы внедрения, опыт реализации проекта и его результаты для банка.
Ключевые слова: мультисервисная сеть, ИТ-инфраструктура, контакт-центр, надежность, доступность, отказоустойчивость, контроль качества, мониторинг, территориально распределенные организации, гетерогенная структура.
BANKING INSTITUTION CORPORATE MULTISERVICE NETWORK. CONSTRUCTION EXAMPLE
Lysetsky YuM., Ph.D., director general («S&T Ukraine», Akademika Palladina Av., 44а, Kiev, 03680, Ukraine, [email protected]) Аbstract. The article is concerned with the question of multiservice networks' construction, which are now the basic of the IT-infrastructure of almost every corporate tier organisation with geographically dispersed structure. The article defines the term "multiservice network", represents a set of requirements to modern corporate multiservice networks, to corresponding infrastructure and to systems' functionality. Basic components of the multiservice network, their functions and its construction topology are described. The principles, requirements and approaches to corporate multiservice network construction of banking institution and the way of integration of call centre to it are considered in the article. It also presents the task sequence solved during the process of their integration. The example of corporate multiservice network construction for VTB Bank in Ukraine is described, and namely: the problem state, task setting, solution and project development, implementation phases, project realisation experience and its results for the bank.
Keywords: multiservice network, call center, safety, availability, fail-safety, quality control, monitoring, geographically dispersed organizations, heterogeneous structure.
В условиях жесткой конкуренции в банковской сфере для достижения успеха банку уже недостаточно просто предоставлять клиенту набор стандартных услуг. Для обеспечения стабильного рос-
та бизнеса на первое место выходит уровень качества обслуживания, которое напрямую зависит от оперативности и эффективности работы обслуживающего персонала.
