Введение в CALS-технологии

ВВЕДЕНИЕ

Современные условия характеризуются все более жесткой конкуренцией на международном рынке, повышением сложности и наукоемкости продукции, что ставит перед промышленниками и предпринимателями страны новые проблемы. К их числу относятся:

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

- снижение всех видов затрат, связанных с созданием и сопровождением изделия;

- повышение качества процессов проектирования и производства;

- обеспечение гибкого и надежного эксплуатационного обслуживания.

Действенным средством решения этих проблем в последнее десятилетие выступают новые информационные CALS-технологии сквозной поддержки сложной наукоемкой продукции на всех этапах ее жизненного цикла (ЖЦ) от маркетинга до утилизации. Базирующиеся на стандартизованном едином электронном представлении данных и коллективном доступе к ним, эти технологии позволяют существенно упростить выполнение этапов ЖЦ продукта и повысить производительность труда, согласно западному опыту, примерно на 30%, автоматически обеспечить заданное качество продукции.

За рубежом работы по созданию и внедрению CALS-технологий ведутся более 25 лет. В этом направлении достигнуты существенные результаты. CALS-технологии в настоящее время рассматриваются как выгодная глобальная экономическая стратегия во всех отраслях промышленности. Работы ведутся во всех ведущих индустриальных странах, создаются международные кооперации производителей сходных видов продукции, так называемые «виртуальные» предприятия, объединяющие поставщиков, производителей и потребителей продукции.

         Впервые элементы CALS-технологий начали применяться в середине 80-х годов при взаимодействии Министерства обороны США со своими поставщиками, когда была поставлена задача перевести все операции с ними в электронный вид. Впоследствии сфера применения CALS-технологий расширилась до всего жизненного цикла изделия и вышла за пределы военных ведомств.
Несмотря на это, наиболее передовыми пользователями CALS-технологии все же являются военные разработчики.   Например, с помощью CALS-технологий были созданы истребитель F-22 (США), подводная лодка Viking (Дания, Норвегия и Швеция), самоходная гаубица Crusader (США). Во всех этих проектах делалась попытка организовать полномасштабное единое информационное пространство для всех участников жизненного цикла изделия. В области гражданского внедрения CALS-технологий в мире и в России лидируют аэрокосмическая и атомная промышленности, автомобиле- и судостроение.
         В России подобные работы начались в середине 90-х годов, на рубеже столетий при Госстандарте был создан комитет № 431, координирующий работы по CALS-технологиям; создан НИЦ CALS-технологий «Прикладная логистика»; разработана программа стандартизации в сфере CALS-технологий в 2000 - 2003 годах; в авиастроении, судостроении, оборонной промышленности реализуются пилотные проекты по внедрению CALS-технологий. В нашей стране среди пионеров внедрения CALS — АВПК «Сухой», ОАО «Туполев», Конструкторское бюро приборостроения (Тула), Воронежский механический завод. Эти проекты поддерживаются Минпромнауки РФ, Минатомом РФ. Тем не менее, для нормального внедрения CALS в России необходимы переподготовка специалистов предприятий, подготовка специалистов в вузах и т. п.
         В настоящее время CALS-технологии в России рассматриваются как средство интеграции в мировую экономику, как важный инструмент реструктуризации оборонной промышленности, судостроения, авиастроения и других отраслей, коренным образом упрощающий внутреннюю и международную промышленную кооперацию, повышающий привлекательность и конкурентоспособность промышленных изделий, обеспечивающий качество продукции, ускорение взаиморасчетов поставщиков и потребителей, совершенствование организации управления на конверсируемых и реформируемых предприятиях. Примерная цена внедрения CALS-технологий на отечественных предприятиях — от 50 до 900 тыс. долл. При этом реализация уже начального этапа дает существенный эффект за счет сокращения времени выхода изделия на рынок, повышения качества изделия, удовлетворения требований заказчика.

Отставание с внедрением CALS- технологий сделает для предприятий невозможным участие в международной кооперации, негативно отразится на конкурентоспособности и привлекательности производимой продукции, послужит причиной потери определенных сегментов рынка.
         Литературы по CALS-технологиям пока недостаточно, она зачастую носит специализированный, односторонний характер. Настоящее учебное пособие имеет целью изложение основных положений CALS-технологий. Его выпуск следует считать попыткой обобщить и систематизировать достижения в этой области, проанализировать аспекты процесса внедрения CALS.
1. ИСТОРИЯ РАЗВИТИЯ CALS-технологиЙ
         Впервые концепция CALS
возникла в середине 70-х годов в оборонном комплексе США в связи с необходимостью повышения эффективности управления и сокращения затрат на информационное взаимодействие в процессах заказа, поставок и эксплуатации средств вооружения и военной техники. Движущей силой явилась естественная потребность в организации «единого информационного пространства», обеспечивающего оперативный обмен данными между заказчиком (федеральными органами), производителями и потребителями военной техники. Данная концепция изначально базировалась на идеологии ЖЦ продукта и охватывала фазы производства и эксплуатации. На первоначальном этапе аббревиатура CALS расшифровывалась как Computer Aided Logistic Support - компьютерная поддержка поставок. Предметом CALS являлась безбумажная технология взаимодействия между организациями, заказывающими, производящими и эксплуатирующими военную технику, а также формат представления соответствующих данных.
         CALS базировалась на результатах реализации программы Integrated Computer-Aided Manufacturing (ICAM) – программы интегрированной компьютеризации производства, реализованной в Министерстве обороны США. Цель этой программы состояла в повышении эффективности производства посредством применения компьютерных информационных технологий. Комплексное применение этих технологий в рамках программы ICAM потребовало унификации и стандартизации методов описания и анализа организационных и производственных систем.

На основе уже имевшихся технологий структурированного анализа и проектирования систем SADT (Structural Analisis and Design Technolody) было разработано семейство (более десяти) методов IDEF (Integrated DEFinition), ряд из которых был принят в качестве федеральных стандартов, а метод функционального моделирования IDEF0 принят в качестве стандарта CALS.
          CALS-технологии, доказав свою эффективность, перестали быть прерогативой военного ведомства и начали активно применяться в промышленности, строительстве, транспорте и других отраслях экономики, расширяясь и охватывая все этапы жизненного цикла продукта. Новая концепция сохранила аббревиатуру CALS, но получила более широкую трактовку Continuous Acquisition and Life Cycle Support – непрерывная поддержка ЖЦ продукта (изделия). Таким образом, возникшая в Министерстве обороны США идея, связанная с единой информационной поддержкой логистических систем, быстро превратилась в глобальную бизнес-стратегию перехода на безбумажную электронную технологию работы, повышения эффективности бизнес-процессов, выполняемых в ходе ЖЦ продукта, за счет информационной интеграции и совместного использования информации на всех его этапах.
         В 1987 году по инициативе 1100 ведущих представителей промышленности США был создан Американский Промышленный Управляющий Комитет в области CALS для координации работы различных организаций США в области CALS.
        Работы по внедрению CALS-технологий велись в 2 этапа. На первом этапе (рубеж 90-х годов) основное внимание уделялось представлению в электронном виде технической документации. На этом же этапе была определена технология представления технической и конструкторско - технологической документации в так называемом «нейтральном» электронном формате. На втором этапе (начало 90-х годов), в рамках всемирного консорциума 25 ведущих технических организаций США, было достигнуто соглашение об использовании нового «нейтрального» стандарта описания данных ISO 10303 (STEP- Standart for the Exchange of Product Model Data).

Сразу же после разработки стандарта STEP была начата разработка стандартов ISO 13584 (PLIB), ISO 15531 (MANDATЕ), предназначенных для описания и представления информации о компонентах и комплектующих изделия, производственно-эксплуатационной среды и обмена данными, которые имеют общую со STEP структуру и технологию построения. Эти стандарты заложили основу CALS-технологий.
       В 1995 году в США был заключен меморандум по общему пониманию и кооперации в использовании стандарта нового поколения ISO 10303 (STEP). В меморандуме отмечено, что новый стандарт является ключевой технологией описания данных об изделии для мирового рынка. Этот стандарт обеспечивает описание физических и функциональных параметров изделия на протяжении всего его жизненного цикла. Меморандум, подписанный руководителями главных аэрокосмических компаний США, содержит обязательство участников использовать STEP в реализации CALS. Он подталкивает поставщиков, других участников аэрокосмической отрасли и продавцов ее технических систем к участию в разработке и внедрении STEP-технологии. В меморандуме указывается, что в настоящее время различные компании нуждаются в эффективном обмене информацией с их партнерами, заказчиками и поставщиками во всем мире. Для того, чтобы сохранить конкурентоспособность на мировом рынке, эти компании должны быть уверены, что обмен является совместимым, точным и своевременным. Используя эти международные стандарты, компании устраняют существовавшие при обмене информацией барьеры, что позволяет обеспечить максимальную гибкость при конструировании, производстве и логистической поддержке (поддержке поставок) продукции. Использование международных стандартов STEP дает возможность этим аэрокосмическим компаниям (и компаниям других отраслей) достигнуть новых, более высоких показателей качества и производительности, снижения стоимости продукции и сокращения времени выхода ее на рынок. Характерно, что рассматриваемый меморандум, заключенный главными аэрокосмическими компаниями,

аналогичен с международным меморандумом автомобилестроительных компаний.
         Аналогичные комитеты и, соответственно, проекты в области CALS были созданы и развернуты в других странах. Так, например, в Великобритании CALS стала известна с 1988 года. В 1991 году был сформирован Промышленный Совет Великобритании в области CALS. С 1993 года департамент торговли и промышленности Великобритании начал содействовать развитию CALS. В том же году было выпущено руководство по внедрению CALS. Свою задачу Промышленный Совет видит в продвижении и поддержке
наилучших методов реорганизации предпринимательской деятельности так, чтобы компании Великобритании могли пользоваться преимуществами электронного обмена информацией. Самыми первыми предприятиями, начавшими применение CALS, являются: аэрокосмический комплекс, военно-промышленный комплекс, крупные нефтяные и нефтеперерабатывающие компании. Самыми первыми проектами в области CALS в Великобритании были проекты, связанные с организацией цепных поставок между «первопроходцами» в области CALS.
         В Европе CALS также нашла достаточно широкое распространение. Cоздана Европейская Промышленная Группа в области CALS, созданы и создаются национальные программы по CALS, а также отдельные проекты по CALS, например такие, как PROSTEP, PISTEP.
         НАТО уделяет значительное внимание вопросам CALS. Ведомство по вопросам CALS в структуре НАТО создано в 1994 году. В рамках данного ведомства осуществляются исследования, охватывающие: технические стандарты, функциональные метамодели, сетевую инфраструктуру, анализ рентабельности, принципы электронной коммерции, правовые вопросы и контрактное право.
         Внедрение CALS набирает темпы и в Тихоокеанском регионе. Так, например, Промышленный Форум по CALS в Японии был создан в мае 1995 года. В рамках Промышленного Форума осуществляются различные проекты в области CALS. Два из них оцениваются особенно высокой вероятностью их реализации:

- национальный проект N-CALS (ассигнования 35. 3 млн. долларов за три года);
- международный проект МАТ1С (ассигнования 17.7 млн. долларов за три года).
В международном проекте МАТ1С участвуют Сингапур, Малайзия,
Индонезия, Таиланд, Китай и Япония.
         В настоящее время в мире действует более 25 национальных организаций, координирующих вопросы развития CALS-технологий, в том числе в США, Канаде, Японии, Великобритании, Германии, Швеции, Норвегии, Австралии, а также в рамках НАТО.
         В России, хотя и с некоторым отставанием во времени от передовых индустриальных стран, начиная с середины 90-х годов, на CALS начинают обращать свое внимание специалисты различных отраслей промышленности. Создан Межведомственный Промышленный Совет по вопросам CALS при Миноборонпроме
РФ. Его основными целями являются:
- развитие российской индустриальной инфраструктуры по поддержке эффективных связей и взаимного обмена между предприятиями при реализации стратегии CALS ;
- поддержка согласованных работ в области CALS по интеграции предприятий в целях повышения их эффективности и производительности;
- устранение возможных барьеров в процессе интеграции CALS-стандартов и технологий.
         Одной из причин отставания в области CALS - технологий является отсутствие отечественной нормативной базы, регламентирующей основные принципы электронного ведения работ при проектировании, производстве, поставке и сервисном обслуживании изделия. Для организации и осуществления работ по стандартизации в области CALS-технологий (в соответствии с решением коллегии министерства экономики России) в рамках Госстандарта России в 1999 году создан Технический Комитет № 431 «CALS - технологии». В рамках ТК № 431 действует подкомитет № 2 «Представление данных и обмен данными об изделиях и процессах», организованный на базе НИЦ CALS – технологий «Прикладная логистика» и объединяющий специалистов ведущих отечественных предприятий. Работы по подготовке нормативных документов ведутся в соответствии с «Программой стандартизации в области CALS-технологий в 2000 – 2003 г.г.», утвержденной Госстандартом России и рядом заинтересованных министерств и ведомств.

         В настоящий момент CALS
понимается как глобальная стратегия повышения эффективности бизнес-процессов, выполняемых в ходе жизненного цикла продукта за счет информационной интеграции и преемственности информации, порождаемой на всех этапах жизненного цикла. Средствами реализации данной стратегии являются CALS-технологии, в основе которых лежит набор интегрированных информационных моделей: самого жизненного цикла и выполняемых в его ходе бизнес-процессов, продукта, производственной и эксплуатационной среды. Возможность совместного использования информации обеспечивается применением компьютерных сетей и стандартизацией форматов данных, обеспечивающей корректную интерпретацию информации.
2. КОНЦЕПЦИЯ CALS

2.1. Основные определения
         В условиях постоянного и значительного усложнения инженерно-технических проектов, программ разработки новой продукции и роста наукоемкости изделий конкурентоспособными окажутся предприятия, достигшие совершенства в управлении бизнесом, обладающие отлаженными процессами проектирования, производства, поставки и поддержки продукта, ориентированные на функционирование в условиях быстроменяющейся экономической ситуации и способные мгновенно реагировать на возникающие новые запросы рынка.
         Такая цель не может быть достигнута частными, постепенными изменениями традиционных методов работы и точечным внедрением средств автоматизации. Предприятия должны провести кардинальное реформирование в сфере управления, опираясь на высокотехнологичные, положительно зарекомендовавшие себя стратегии организации современного бизнеса. Такой стратегией, принятой в настоящее время в качестве международного стандарта, является CALS.
         CALS (Сontinuous Acquisition and Life Cycle Support) - непрерывная информационная поддержка жизненного цикла изделия или продукта. Это стратегия повышения эффективности, производительности и рентабельности процессов хозяйственной деятельности предприятий за счет внедрения современных методов информационного взаимодействия участников ЖЦ продукта.

         Жизненный цикл продукта, как его определяет стандарт ISO 9004-1, — это совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта. Основные стадии жизненного цикла показаны далее на рисунках.
         Процесс - это структурированный набор функций, охватывающий различные сущности и завершающийся глобальной целью (определение по ISO/CD 15531-1). По определению, приведенному в стандарте ISO 8402:1994, процесс - это совокупность взаимосвязанных ресурсов и деятельности, которая преобразует входящие элементы в выходящие. Ресурсами являются персонал, средства обслуживания, оборудование, технология, методология.
          ЖЦ продукта присуще большое разнообразие процессов. Наиболее известные: производственный процесс, процесс проектирования, процесс закупок. Каждый из этих процессов, в свою очередь, состоит из технологических процессов и организационно-деловых процессов. Под технологическим процессом понимается часть производственного (или другого процесса), содержащая целенаправленные действия по изменению и (или) последующему определению состояния предмета труда. Под организационно-деловыми процессами понимаются процессы, связанные с взаимодействием людей (подразделений, организаций). Все процессы ЖЦ взаимосвязаны (см. рис.1).
         Для общей характеристики этих процессов используется понятие «бизнес-процесс».
         Бизнес-процесс – совокупность технологических и организационно-деловых процессов, выполняемая целенаправленно в рамках заранее заданной организационной структуры.
         Бизнес-процессы могут быть разного масштаба: масштаба предприятия (в него вовлечены работники нескольких подразделений, например, снабжающих предприятие материалами и комплектующими), внутрицеховые, внутрилабораторные (например, изготовить деталь). Внутри одного бизнес-процесса часть составляющих его технологических и организационно-деловых процессов может быть организована в отдельный вложенный бизнес-процесс меньшего масштаба.

Отдельные технологические и организационно- деловые процессы могут раскладываться на операции (законченные части процесса, выполняемые на одном рабочем месте – выписать накладную, составить договор), которые в свою очередь делятся на переходы
(законченные части операции, выполняемые одними и теми же средствами – позвонить, записать, фрезеровать).

                           Рис.1. Жизненный цикл продукта как взаимосвязь процессов
         Бизнес-процессы также различаются по типу деятельности:
-     основные
бизнес-процессы (определяют основное направление деятельности предприятия: производитство продукции, сервисное обслуживание, оказание услуг и т. п.);
-     вспомогательные
бизнес-процессы (процессы, связанные с решением внутренних задач предприятия по обслуживанию основных бизнес-процессов);
-     бизнес-процессы управления (планирование деятельности предприятия, организация производства, контроль);
-     бизнес-процессы сети
(взаимодействие с поставщиками и потребителями).
         Анализ бизнес-процессов позволяет по-новому взглянуть на работу предприятия, уточнить обязанности работников, оценить эффективность использования ресурсов, увидеть недостатки, скрытые в организационной структуре. С момента введения термина «бизнес-процесс» появилось понятие «реинжиниринг бизнес-процессов» (Business Process Reengineering, BPR), которое подразумевает фундаментальное переосмысление и перепроектирование бизнес-процессов предприятия с целью повышения эффективности его работы.
         В общем случае ЖЦ необходимо рассматривать как совокупность ЖЦ конечного продукта и ЖЦ входящих в него компонентов, результатов деятельности субпоставщиков. С этой точки зрения ЖЦ представляет собой древовидную
структуру (см. рис. 2).

                                     Рис. 2. Жизненный цикл продукта и его компонентов
         Рассмотрим определение CALS детальнее.

         В дословном переводе аббревиатура CALS означает «непрерывность поставок продукции и поддержки ее жизненного цикла». Первая часть определения - «непрерывность поставок продукции» требует и подразумевает оптимизацию процессов взаимодействия заказчика и поставщика в ходе разработки, проектирования и производства сложной продукции, срок жизни которой, с учетом различных модернизаций, составляет десятки лет. Для обеспечения эффективности, а также сокращения затрат средств и времени, процесс взаимодействия заказчика и поставщика должен быть действительно непрерывным. Вторая часть определения CALS - «поддержка жизненного цикла» - заключается в оптимизации процессов обслуживания, ремонта, снабжения запасными частями и модернизации. Поскольку затраты на поддержку сложного наукоемкого изделия в работоспособном состоянии часто равны или превышают затраты на его приобретение, принципиальное сокращение «стоимости владения» обеспечивается инвестициями в создание системы поддержки ЖЦ.
          Целью применения CALS-технологий, как инструмента организации и информационной поддержки всех участников создания, производства и пользования продуктом, является повышение эффективности их деятельности за счет ускорения процессов исследования и разработки продукции, придания изделию новых свойств, сокращения издержек в процессах производства и эксплуатации продукции, повышения уровня сервиса в процессах ее эксплуатации и технического обслуживания.
         Предметом CALS
являются технологии информационной интеграции, то есть совместного использования и обмена информацией об изделии (продукте), среде и процессах, выполняемых в ходе жизненного цикла продукта.
         Основой CALS является использование комплекса единых информационных моделей, стандартизация способов доступа к информации и ее корректной интерпретации, обеспечение безопасности информации, юридические вопросы совместного использования информации (в том числе интеллектуальной собственности), использование на различных этапах ЖЦ автоматизированных программных систем (CAD/CAM/CAE, MRP/ERP, PDM и др.), позволяющих производить и обмениваться информацией в формате CALS.

         Иногда термин CALS, отождествляется с различными АСУ и компьютерными технологиями вообще. CALS, в отличие от ИАСУ и АСУП, охватывает все стадии ЖЦ (см. рис.3).

Рис.3. Позиционирование АСУП, ИАСУ и CALS-систем
внутри жизненного цикла продукта
Информационное взаимодействие субъектов, участвующих в поддержке ЖЦ, должно осуществляться в едином информационном пространстве (ЕИП). Для разрушения коммуникационных барьеров и реализации концепции CALS необходимо создать ЕИП для всех участников ЖЦ изделия (в том числе и для эксплуатационников). ЕИП должно:
·         аккумулировать всю информацию об изделии;
·         быть единственным источником данных о нем (прямой обмен данными между участниками ЖЦ исключен);
·         формироваться на основе международных, государственных и отраслевых стандартов.
ЕИП создается с помощью программно-аппаратных средств, уже имеющихся у участников ЖЦ. В условиях отечественного производства лучше организовывать ЕИП в два этапа:
I этап — автоматизация отдельных процессов ЖЦ изделия и представление данных на них в электронном виде;
II этап — интеграция автоматизированных процессов и относящихся к ним данных.
ЕИП может быть создано для структур разного уровня: от отдельного подразделения до предприятия или корпорации.
В основе концепции ЕИП лежит использование открытых архитектур, международных стандартов и апробированных коммерческих продуктов обмена данными. Стандартизации подлежат форматы представления данных, методы доступа к данным и их корректной интерпретации. Стандарты являются основным строительным блоком CALS. Более детально они будут рассмотрены далее.
        Информационная интеграция базируется на использовании:

-       информационной модели ЖЦ продукта и выполняемых в его ходе бизнес-процессов;
-       информационной модели продукта;
-       информационной производственной и эксплуатационной среды.
         Укрупненная классификация информационных моделей и их связь со стадиями ЖЦ продукта приведена в табл. 1.
Таблица 1

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

2.2. Задачи, решаемые при помощи CALS-технологий
         Моделирование жизненного цикла продукта и выполняемых бизнес-процессов.          Это первый и очень существенный шаг к повышению эффективности организационной структуры, поддерживающей одну или несколько стадий ЖЦ продукта, — моделирование и анализ ее функционирования.
        Цель бизнес-анализа — выявить существующее взаимодействие между составными частями и оценить его рациональность и эффективность. Для этого с использованием CALS-технологий разрабатываются функциональные модели, содержащие детальное описание выполняемых процессов в их взаимосвязи. Формат описания регламентирован CALS-стандартами IDEF и ISO 10303 AP208.

Полученная функциональная модель не только является детальным описанием выполняемых процессов, но также позволяет решать целый ряд задач, связанных с оптимизацией, оценкой и распределением затрат, оценкой функциональной производительности, загрузки и сбалансированности составных частей, то есть вопросов анализа и реинжиниринга бизнес-процессов.
Методы функционального моделирования, например, с успехом могут быть использованы при создании систем обеспечения качества продукции (см. далее). В этом случае в качестве функциональной модели могут быть описаны функции системы обеспечения качества продукции, регламентированных стандартами ISO серии 9000. Разработанная функциональная модель позволяет выявить логические ошибки, допущенные при построении системы обеспечения качества, уточнить распределение полномочий и ответственности, автоматически генерировать отчетные документы по структуре системы. Функциональная модель системы качества продукции описывает сеть процессов обеспечения качества продукции и их интерфейсы, связанные с ними обязанности, полномочия, процедуры и ресурсы, распределение обязанностей и полномочий подразделений и персонала предприятия. При моделировании системы качества также используются информационные модели.
         Проектирование и производство изделия. Совместное, кооперативное проектирование и производство изделия может быть эффективным в случае, если оно базируется на основе единой информационной модели изделия (электронной модели изделия).
         Разрабатываемая на данной фазе конструкторско-технологическая информационная модель базируется на использовании стандарта ISO 10303 (STEP). Созданная однажды модель изделия используется многократно. В нее вносятся дополнения и изменения, она служит отправной точкой при модернизации изделия. Модель изделия в соответствии с этим стандартом включает: геометрические данные, информацию о конфигурации изделия, данные об изменениях, согласованиях и утверждениях.
        Стандартный способ представления конструкторско-технологических данных позволяет решить проблему обмена информацией между различными подразделениями предприятия, а также участниками кооперации, оснащенными разнородными системами проектирования.

Использование международных стандартов обеспечивает корректную интерпретацию хранимой информации, возможность оперативной передачи функций одного подрядчика другому, который, в свою очередь, может воспользоваться результатами уже проделанной работы. Это особенно важно для изделий с длительным ЖЦ, когда необходимо обеспечить преемственность информационной поддержки продукта, независимо от складывающейся рыночной или политической ситуации.
        Эксплуатация изделия. Известно, что объемы разрабатываемой документации для сложного наукоемкого изделия очень велики. Поэтому традиционное бумажное документирование сложных изделий требует огромных затрат на поддержку архивов, корректировку документации, а также снижает эксплуатационную привлекательность и конкурентоспособность изделия.
         Решение проблемы заключается в переводе эксплуатационной документации на изделие, поставляемой потребителю, в электронный вид. При этом комплект электронной эксплуатационной документации - интерактивные электронные технические руководства (ИЭТР), электронные справочники и др. следует рассматривать как составную часть интегрированной информационной модели изделия. Электронная документация может поставляться на электронных носителях (например, на компакт-дисках) или размещаться в глобальной сети Интернет. Стандартизация гарантирует применимость такой электронной документации на любых компьютерных платформах.
        Эксплуатационная документация может содержать информацию различных типов в соответствии со стандартами CALS: ISO 10303 (STEP), ISO 8879 (SGML), ISO 10744 (HyTime) и MIL-PRF-28001C — для графической, текстовой и мультимедийной информации, MIL-PRF-28000A, MIL-PRF-28002C, MIL-PRF-28003A — для векторных и растровых графических иллюстраций.
         Важно отметить, что в электронный вид может быть преобразована эксплуатационная документация, созданная ранее без использования компьютерных систем. Для изделий, уже находящихся в эксплуатации длительный период и спроектированных традиционными методами, задача поддержки документации не менее актуальна.

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

2.3. Что дают CALS-технологии
         CALS рассматривается как комплексная системная стратегия повышения эффективности всех процессов ЖЦ промышленной продукции, непосредственно влияющая на ее конкурентоспособность. Применение стратегии CALS является условием выживания предприятий в условиях растущей конкуренции и позволяет:
-    расширить области деятельности предприятий (рынки сбыта) за счет кооперации с другими предприятиями, обеспечиваемой стандартизацией представления информации на разных стадиях и этапах жизненного цикла. Благодаря современным телекоммуникациям, уже не принципиально географическое положение и государственная принадлежность партнеров. Новые возможности информационного взаимодействия позволяют строить кооперацию в форме виртуальных предприятий, действующих в течение ЖЦ продукта. Становится возможной кооперация не только на уровне готовых компонентов, но и на уровне отдельных этапов и задач: в процессах проектирования, производства и эксплуатации;
-     за счет информационной интеграции и сокращения затрат на бумажный документооборот, повторного ввода и обработки информации обеспечить преемственность результатов работы в комплексных проектах и возможность изменения состава участников без потери уже достигнутых результатов;
- повысить «прозрачность» и управляемость бизнес-процессов путем их реинжиниринга, на основе интегрированных моделей ЖЦ и выполняемых бизнес-процессов, сократить затраты в бизнес-процессах за счет лучшей сбалансированности звеньев;

- повысить привлекательность и конкурентоспособность изделий, спроектированных и произведенных в интегрированной среде с использованием современных компьютерных технологий и имеющих средства информационной поддержки на этапе эксплуатации;
-     обеспечить заданное качество продукции в интегрированной системе поддержки ЖЦ путем электронного документирования всех процессов и процедур.
-     сократить издержки производства и снизить стоимость продукции;
- сократить время создания изделия, его модернизации и увеличить его реальное время «жизни», функционирования в работоспособном состоянии за счет высокого качества и электронной поддержки во время эксплуатации.
3. Стандарты CALS
3.1. Объекты стандартизации
         Фундаментом CALS-технологии является система единых международных стандартов.
         CALS-стандарты можно подразделить на три группы:
- функциональные стандарты, определяющие процессы и методы формализации;
- информационные стандарты по описанию данных о продуктах, процессах и средах;
- стандарты технического обмена, контролирующие носители информации и процессы обмена данными между передающими и принимающими системами.
         Поскольку целью CALS является обеспечение информационной интеграции, важную роль в данной проблематике играет применение международных
стандартов (серии ISO). Перечень основных стандартов приведен в табл.2.

Таблица 2

Информационные модели	Стандарт представления информации	Содержание стандарта
Модель ЖЦ продукта и выполняемых в его ходе бизнес-процессов	IDEF – Integrated Definition,	Функциональное моделирование жизненного цикла и выполняемых бизнес-процессов
ISO 10303 AP208
Модель продукта	Конструкторская	ISO 10303 (STEP)	Структура, конфигурация и геометрия изделия
Производственная	ISO-13584 (PLIB)	Формат данных о библиотеках деталей у поставщиков
MIL-STD- 1388-1/2 Logistic Support Analysis (LSA) Record	Формат данных в процессах материально-технического снабжения
Эксплуатационная	MIL-M-87268 – Manuals, Interactive Electronic Technical General Content, Style, Format, and User-Interaction Requirements (IETM)	Требования к электронным руководствам: содержание, стиль, формат, Интерфейс с пользователем
MIL-D-87269 –Data Base, Revisable Interactive Electronic Technical Manuals, for the support of	Требования к оформлению баз данных и электронных справочников по изделиям
ISO 8879 (SGML) – Standard Generilized MarkUp Language	Способ представления информации в тексто-графических документах
MIL-PRF-28001C - Markup Requirements and Generic Style Specification for Electronic Printed Output and Exchange of Text	Требования к оформлению электронных документов (рекомендации по применению SGML для оформления электронных документов)
MIL-PRF-28002C –Requirements for Raster Graphics Representations in Binary Format	Требования к представлению растровых изображений в двоичном формате в электронной документации
MIL-PRF-28003 – Color Graphics Metafile (CGM)	Требования к представлению иллюстраций для технической документации в электронном виде
ISO 10744 HyTime - (Hypermedia/Time Based Structuring Language	Требования к мультимедийной информации в электронных документах
Модель среды	ISO 15531 (MANDATE)	Форма представления и методы использования информации о производстве и используемых производственных ресурсах, их характеристиках и ограничениях с точки зрения управления производством.

<

3.2. Стандарты и методы семейства IDEF
3.2.1. Общая характеристика методов IDEF

 Методы IDEF (Integrated DEFinition), как отмечено в историческом введении, изначально были разработаны в рамках реализации программы интегрированной компьютерной поддержки производства ICAM в США в середине 70-х годов с целью улучшения взаимодействия специалистов, занимающихся интеграцией существующих производственных и организационных систем. В основу была положена технология структурированного анализа и проектирования SADT (Structured Analysis and Design Technique), разработанная в начале 70-х годов фирмой SoftTech. Они направлены на различные методы описания и анализа процессов, потоков, структур промышленных и организационных систем с целью улучшения их характеристик. Методы взаимодополняют друг друга, обеспечивая возможность многоаспектного анализа систем. На их основе разработаны федеральные стандарты США (FIPS), их методологические основы используются при разработке новых стандартов CALS.
 Кратко охарактеризуем основные методы IDEF.
 IDEF0 - метод функционального моделирования; был разработан для описания функций различных систем путем создания наглядной графической модели. Функциональные модели строятся методом декомпозиции от главной (контекстной) функции к более мелким простым с учетом их взаимной связи. Цель моделирования и степень детализации модели определяется разработчиком. Элементы модели каждого уровня представляют собой действия по переработке информационных или материальных ресурсов при определенных условиях (ограничениях, управляющих воздействиях) с использованием определенных механизмов. Как правило, моделирование средствами IDEF0 является начальным этапом изучения любой системы. Модели используются для детального функционального анализа с целью улучшения структуры функций объекта (реинжиниринга). На методе IDEF0 базируется функционально-стоимостной анализ - ФСА (АВС – Activity Based Costing).

Стандарт IDEF0 выпущен в 1981г., последняя его версия – в 1993 г. (FIPS 183).
 IDEF1- метод моделирования информационных потоков внутри системы, позволяющий отображать структуру системы, то есть ее элементы (сущности), их свойства (атрибуты) и взаимосвязи (отношения) между ними. Полученная в процессе моделирования детальная информация позволяет выявить «узкие места» в анализируемом объекте и является основой для принятия решений об улучшении структуры системы и информационных потоков, осуществления правильной политики управления информацией.
 IDEF1X- метод моделирования данных и проектирования реляционных баз данных. Он, так же как и IDEF1, относится к типу методологий «сущность-взаимосвязь» (ER- Entity-Relationship), однако сущности здесь понимаются не как реальные объекты, а как их типы, обладающие общими свойствами. Связи между сущностями более сложны. Это позволяет хранить информацию в форме абстрактной схемы (семантической модели), которая связывает хранящиеся в компьютере символы с реальным миром и является верным его отражением. Подобный способ хранения информации является относительно независимым, «нейтральным» и позволяет получить ответ на различные запросы пользователя о свойствах описанной в модели среды. Стандарт IDEF1Х выпущен в 1993 году (FIPS 184).
 IDEF2- метод динамического моделирования систем. В связи с весьма серьезными сложностями анализа динамических систем развитие этого стандарта происходит медленно. Однако в настоящее время существуют алгоритмы и их компьютерные реализации, позволяющие превратить набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets), т.е. отслеживать изменение состояние систем с помощью фиксации ряда дискретных квазистационарных состояний. Подобный подход широко используется при динамическом моделировании технических систем, описываемых дифференциальными уравнениями различного типа.
 IDEF3 -метод получения описания функционирования системы и моделирования как причинно-следственных связей внутри

одного бизнес-процесса, так и между различными процессами. Он предоставляет пользователю два типа диаграмм: описания процесса PFD (Process Flow Description) – «внутреннее описание» и описания переходов из одного состояния в другое OSTD (Object State Transition Description) – «внешнее описание», когда дополнительно рассматривается вход и выход объекта. Эти два способа моделирования дополняют друг друга и позволяют описать любой процесс функционирования системы.
 IDEF4 – метод объектно-ориентированного проектирования. Средства метода позволяют наглядно отображать структуру объектов и принципы их взаимодействия, позволяя анализировать и оптимизировать и создавать сложные системы. В отличие от других методов, кроме констатации взаимодействия, здесь учитывается его принцип (в частности, физический). Поэтому он, как и IDEF1Х, является методом проектирования.
 IDEF5 - метод получения онтологического описания и исследования сложных систем. Основной чертой онтологического анализа является разделение реального мира на классы, определение совокупности их фундаментальных свойств и прогнозирование на этой основе поведения объектов данного класса. Это
метод сбора фактов и получения знаний. Типичный пример онтологического исследования – научное. С помощью данного метода онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные суждения о состоянии рассматриваемой системы в некоторый момент времени. На основании этих утверждений формируются выводы о дальнейшем развитии системы, проводится возможная ее реорганизация, что полезно при управлении сложными системами, имеющими искусственный характер. На основе онтологического описания строятся системы получения новых знаний – экспертные системы. Исследователь имеет возможность строить разнообразные схемы и диаграммы с помощью языка схем (Schematic Language-SL), комментировать их с помощью языка уточнений (Elaboration Language-EL).

Не исключено, что методологические основы IDEF5
в дальнейшем будут использованы для анализа сложных CALS-моделей (например, так называемых виртуальных моделей предприятий) для формирования возможных вариантов бизнес-стратегии.
 В CALS-технологиях наибольшее применение нашли методы IDEF0 и IDEF1Х.
 Метод IDEF0 является стандартом CALS, однако он не обеспечивает прямой интеграции функциональных моделей с моделями продукции. Для этого разрабатывается один из прикладных протоколов стандарта STEP – ISO 10303 AP208, который базируется на методологии IDEF0.
 Метод IDEF1Х по своей идеологии близок к языку EXPRESS стандарта ISO 10303 STEP, предназначенного для описания продукции в нейтральном формате (в форме EXPRESS-схем, характерных для реляционных баз данных).
 Поэтому методы IDEF0 и IDEF1Х рассмотрим более детально.

3.2.2. Метод IDEF0

 Графический язык IDEF0 прост и гармоничен. В основе метода лежат 4 основных понятия.
 Первым
из них является понятие функционального блока (Activity Box). Функциональный блок изображается в виде прямоугольника (см. рис.4) и олицетворяет некоторую конкретную функцию в рамках рассматриваемой системы, которая выражается глагольной формой. Например: «Обработать заготовку», а не «Обработка заготовки».

Рис. 4. Функциональный блок
 Каждая из сторон блока имеет определенное значение (роль):
- верхняя сторона имеет значение «Управление» (Control);
- левая сторона имеет значение «Вход» (Input);
- правая сторона имеет значение «Выход» (Output);
- нижняя сторона имеет значение «Механизм» (Mechanism).
 Каждый блок должен иметь уникальный идентификационный номер.
 Вторым понятием метода является понятие интерфейсной дуги (Arrow). Графическим отображением интерфейсной дуги является однонаправленная стрелка (поэтому дуги часто называют стрелками, потоками). Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label), которое должно быть оборотом существительного.

С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Это могут быть элементы реального мира (люди, изделия, детали и др.), потоки данных и информации (документы, инструкции и др.). «Источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только блоки, причем «источником» может быть только выходная сторона блока, а «приемником» – любые из трех оставшихся. Функциональный блок должен обязательно иметь управляющую и исходящую интерфейсную дугу, поскольку каждый процесс должен происходить по каким –то правилам и давать некоторый результат (иначе его рассмотрение не имеет смысла).
 При построении IDEF-диаграмм важно отделять входящие дуги от управляющих.
Например, в реальном процессе рабочий получает заготовку и технологические указания по ее обработке. Ошибочно может показаться, что и заготовка, и указания – входящие объекты. На самом деле технологические указания (нормативы, правила техники безопасности) должны изображаться управляющей дугой, поскольку они регламентируют процесс. Другое дело, когда технологические указания редактируются технологом. Тогда они изображаются входящей дугой, а управляющей дугой могут быть новые стандарты.
 В случае рассмотрения деятельности предприятий существует 5 основных видов объектов: материальные потоки (детали, товары), финансовые потоки (наличные, безналичные), потоки документов (коммерческие, организационные), потоки информации (данные о намерениях, распоряжения), ресурсы (сотрудники, станки, машины). При этом входящими и исходящими дугами могут отображаться все виды объектов, управляющими – только потоки документов и информации, а дугами-механизмами – только ресурсы.
 Третьим основным понятием метода является декомпозиция (Decomposition), то есть разбиение сложной функции на ее составляющие. Декомпозиция позволяет представить модель в виде иерархической системы диаграмм, что делает ее менее перегруженной и легко усваиваемой.

 Процесс моделирования начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами. Эта диаграмма называется контекстной и обозначается идентификатором «А0». В пояснительном тексте к контекстной диаграмме в краткой форме должна быть указана цель (Purpose) и зафиксирована точка зрения (Viewpoint). Цель определяет области в анализируемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Она позволяет отказаться от несущественных свойств в данном аспекте рассмотрения. Например, функциональные модели предприятия с точки зрения главного технолога и финансового директора будут различаться, поскольку финансового директора интересуют финансовые потоки, а главного технолога – аспекты переработки сырья.
 В процессе декомпозиции функциональный блок в контекстной диаграмме подвергается детализации на другой диаграмме – дочерней. На ней фиксируются все функциональные дуги родительской
диаграммы, за счет этого достигается структурная целостность модели. Связана также нумерация блоков и диаграмм: каждый блок имеет свой уникальный номер - цифра в правом нижнем углу, а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы (см. рис. 5, 6).
 Следует отметить, что рис.6 выполнен с использованием специализированного программного средства – CASE-средства Design/IDEF для построения диаграмм в соответствии с методами IDEF0 и IDEF1X. Design/IDEF автоматически контролирует основные правила построения диаграмм, автоматически выполняет оцифровку блоков, переносит интерфейсные дуги с родительской диаграммы, вписывает в соответствующие поля необходимую информацию (например, в нижней части диаграммы указано имя родительской функции и номер родительской диаграммы).
 Часто бывают случаи, когда отдельные дуги не имеет смысла продолжать рассматривать на дочерних диаграммах, или наоборот, отдельные дуги не имеют практического смысла выше какого-то уровня.

Это будет усложнять диаграммы. Для этого вводится понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала дуги обозначает, что она была не унаследована, а появилась из «туннеля» на данной диаграмме. Если скобки стоят у конца дуги, то это означает, что дуга не будет наследоваться. Бывает, что некоторые дуги сначала «погружаются» в туннель, а потом «возвращаются» из туннеля.

Рис. 5. Декомпозиция диаграмм при функциональном моделировании

Рис.6. Функциональная диаграмма создания и модификации проекта изделия (второй уровень)

         Четвертым из основных понятий метода является глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) создаются и поддерживаются определения, ключевые слова, повествовательные изложения, которые характеризуют объект. Глоссарий снабжает диаграммы дополнительной информацией.
         Для удобочитаемости рекомендуется ограничить количество блоков на диаграмме тремя-шестью. Верхний предел заставляет прибегать к декомпозиции, нижний гарантирует, что на диаграмме достаточно деталей, чтобы оправдать ее создание. Желательно, чтобы количество интерфейсных дуг, подходящих к стороне блока или исходящих от нее не превышало 4-х.
         Метод IDEF0 предполагает групповую работу над проектом или проектами. Группа, состоящая из различных специалистов, опрашивает компетентных лиц и строит черновую модель. Эта модель обсуждается специалистами предприятия, письменно критикуется и передается группе разработчиков. Этот цикл продолжается до тех пор, пока разработчики и рецензенты не придут к одному мнению. Далее происходит официальное утверждение модели и ее использование (например, для реструктуризации функций системы).
         Одно из достоинств метода IDEF0 заключается в том, что он абстрагируется от организационной структуры объекта и анализирует его функции. Это позволяет после построения модели взглянуть на организационную структуру, реализующую эти функции с точки зрения ее совершенства, выявить похожие функции или их дублирование и дать предложения по реорганизации системы.

         Если использовать термин «бизнес-процесс», то можно сказать, что метод IDEF0 позволяет идентифицировать бизнес-процессы, рассмотреть функционирование предприятия «как есть» и на основе их анализа дать предложения «как должно быть», то есть по-новому взглянуть на работу предприятия, уточнить обязанности работников, оценить эффективность использования ресурсов, увидеть недостатки, искусно скрытые в обычной организационной структуре. Следовательно, выявление, анализ и внесение изменений в бизнес-процессы может быть использовано для повышения эффективности работы предприятия.
         С момента введения термина «бизнес-процесс» появилось несколько методик улучшения бизнес-процессов. Наиболее популярная из них – это реинжиниринг бизнес-процессов предприятия, которая подразумевает фундаментальное переосмысление и перепроектирование бизнес-процессов предприятия. Выявление, анализ и перепроектирование этих процессов – вот содержание предлагаемой методики. Общая схема методики анализа и реинжиниринга бизнес-процессов предприятия выглядит следующим образом (см. рис. 7):
-   сбор информации о предприятии;
-     идентификация бизнес-процессов предприятия и создание функциональной модели бизнес-процессов предприятия;
-     анализ и возможный реинжиниринг бизнес-процессов предприятия.
          Для анализа распределения затрат
применяется метод ABC, базирующийся на IDEF0. Метод ABC основывается на том, что выполнение каждой функции в процессе функционирования предприятия обладает определенной стоимостью, то есть вносит свой вклад в появление издержек. АВС аналогично понятию ФСА - функционально-стоимостного анализа. При помощи метода АВС рассчитываются затраты на выполнение всего процесса или отдельной функции, стоимость продукции на выходе процесса, выявляются источники основных затрат. Затраты на выполнение декомпозируемой функции определяются как сумма затрат на выполнение всех составных элементов в этой функции.
         Применение метода ABC позволяет получить количественные оценки процесса, необходимые для оценки нескольких вариантов.

В отличие от традиционной бухгалтерии, учитывающей в основном прямые издержки (учет косвенных издержек сложен, но в ряде случаев необходим), метод ABC позволяет учитывать различные факторы, влияющие на формирование издержек предприятия.
         Для построения функциональной модели предлагается выбрать CASE-пакет Design/IDEF, так как помимо возможностей создания функциональной модели этот пакет содержит встроенный механизм АВС подсчета затрат на выполнение функций, позволяющий анализировать бизнес-процессы и их составляющие. Каждый вид ресурса, потребляемый (обрабатываемый) функцией, а также механизмы, выполняющие функцию, добавляют стоимость к этой функции, при этом учитываются элементы затрат, игнорируемые при обычном представлении предприятия как совокупности организационных структур. Следовательно, каждой функции h модели IDEF0 можно поставить в соответствие значение затрат на выполнение этой функции Ex(h). Математический аппарат АВС для решения конкретной задачи изложен в Приложении 2.

Рис. 7. Общая схема методики анализа и реинжиниринга бизнес-процессов предприятия
 Совмещение методов IDEF0 и ABC позволяет решить одну из важнейших задач – анализ совершенства функций системы, возможностей ее улучшения, что не в такой мере присуще другим методам и стандартам.
Подключение метода АВС позволяет провести сравнение существующей структуры (как есть) с рациональной структурой (как должно быть), поскольку одни и те же функции могут быть реализованы различными структурами (например, можно объединить подразделения, выполняющие аналогичные функции с несущественным различием или малой загрузкой).

3.2.3. Метод моделирования данных IDEF1X

 Стандарт FIPS 184 на основе этого метода, выпущенный в 1993 году, не входит в перечень CALS-стандартов.

Однако разработанные на его основе структуры реляционных баз данных напрямую могут быть использованы для создания информационных систем с использованием языка EXPRESS стандарта ISO 10303 (STEP), который составляет основу CALS-технологий. Аналогия положений IDEF1X и требований языка EXPRESS
станет очевидной при рассмотрении EXPRESS.
 IDEF1X - это метод для разработки реляционных баз данных. Он использует условный синтаксис для описания семантических конструкций, необходимых для построения концептуальной схемы. Концептуальная схема - это единое интегрированное определение данных предметной области, не ориентированное на какое-либо конкретное приложение и независимое от способов доступа и способов физического хранения данных.
 Наиболее полезен IDEF1X как средство логического проектирования баз данных, после того как информационные требования уже выяснены и решение о разработке реляционной базы данных принято. Следовательно, системной перспективой IDEF1X являются элементы реальных данных в реляционной базе данных. Если целью разработки является не реляционная, а, например, объектно-ориентированная система, IDEF1X не является лучшим решением.
 Существуют несколько причин, почему IDEF1X не совсем подходит для реализаций нереляционных систем. Например, IDEF1X требует, чтобы разработчик задавал ключи классов для отличия одной сущности от другой, в то время как объектно-ориентированные системы не требуют ключей для индивидуализации одного объекта от другого. Более того, в тех ситуациях, когда более одного атрибута или набор атрибутов будет использоваться для идентификации сущностей IDEF1X, разработчик обязан задать один ключ как первичный и список всех остальных ключей, как вторичный. Также требуется явное именование внешнего ключа.
 Предполагается, что окончательный логический проект моделей IDEF1X будет использоваться программистами, которые берут схему логического проекта базы данных и реализуют этот проект (например, с использованием языка EXPRESS).

 Концепция IDEF1X несколько отличается от IDEF1, хотя их терминология схожа. Сущность в IDEF1X ссылается на коллекцию или набор аналогичных экземпляров данных, которые могут отличаться друг от друга. Отдельные члены набора называются экземплярами сущности. Таким образом, блок в IDEF1X представляет набор экземпляров реального мира. Атрибут - это значение, ассоциированное с каждым конкретным экземпляром набора. Отношению, существующему между отдельными экземплярами этих наборов, даётся имя, которое выражено глагольной формой.
 Сильной особенностью IDEF1X является его поддержка моделирования логических типов данных через использование структуры классификации. Эта конструкция является попыткой отразить модель реального мира, данные о которых представляются либо блоками, либо сущностями, попыткой промоделировать типы данных вещей. Эти отношения категоризации представляют взаимно исключающие подмножества родовой сущности или множества. Подмножества общего надмножества не могут иметь общих экземпляров. Например, родовая сущность ОСОБА имеет два подмножества, представляющих полный набор категорий, а именно, МУЖЧИНА и ЖЕНЩИНА. Ни один экземпляр подмножества МУЖЧИНА не может быть экземпляром подмножества ЖЕНЩИНА, и наоборот. Уникальный идентификатор атрибута для каждого подмножества - это тот же атрибут, что и для экземпляра родовой сущности.
 Сущности в IDEF1X сущности являются либо идентификационно независимыми, либо идентификационно зависимыми. Экземпляры идентификационно независимых
сущностей могут существовать независимо от другого экземпляра сущности, в то время как экземпляры идентификационно зависимых
сущностей являются бессмысленными (по определению) без другого ассоциированного экземпляра сущности. Зависимость и независимость являются спецификой модели.
 Отношения связности
(сплошные или пунктирные линии с кружками с одной или двух сторон) показывают, как сущности (множества экземпляров данных) относятся друг с другом.

Отношения связности существуют всегда только между двумя сущностями. Отношение связности, начинающееся с независимой родовой сущности и заканчивающееся на зависимой порождённой сущности, помечается глагольной фразой, описывающей отношение. Каждое отношение связности имеет соответствующую мощность. Мощность определяет число экземпляров зависимой сущности, связанных с экземпляром независимой сущности.
 Отношения категоризации позволяют проектировщику определить категорию общей сущности. Сущность может принадлежать только одной категории. Например, может существовать общая сущность МАШИНА, являющаяся родовой сущностью для категории, представляющей различные марки машин (ВОЛГА, ОКА, НИВА). Каждая сущность-категория должна иметь одинаковый первичный ключ с общей сущностью. Кроме того, обязаны существовать различия между сущностями-категориями. Сущности-категории различаются атрибутом – дискриминатором (описателем), который обязан иметь различные значения для каждой сущности-категории. В рассмотренном примере дискриминатор - МАРКА МАШИНЫ.
 Атрибуты - это свойства, используемые для описания сущностей. Имена атрибутов являются уникальными для всей модели IDEF1X, значения имён должны быть согласованными. Например, атрибут «цвет» можно использовать для цвета волос, цвета кожи, цвета радуги. Каждое такое использование имеет допустимый диапазон значений, и, следовательно, сущность необходимо раздельно именовать. Каждый атрибут принадлежит только одной сущности. Например, атрибут «страховой номер» может использоваться в модели во многих местах, но должен принадлежать только одной сущности (например, ПЕРСОНА). Все другие появления атрибутов страхового номера будут наследоваться через отношения.
 Каждый атрибут должен иметь значение (правило непустоты); не существует атрибутов, имеющих несколько значений (правило неповторения). Использование этих правил обеспечивает создание правильных моделей, отражающих реальный мир.

В случае, когда кажется, что правило не может быть применено, вполне вероятно, что модель является ошибочной.
 Ключ - это группа атрибутов однозначно идентифицирующих экземпляр сущности. Существуют первичные и вторичные ключи. Каждая сущность имеет только один первичный ключ, отображаемый над горизонтальной линией в блоке сущности. Сущности могут иметь переменные ключи, которые также однозначно идентифицируют сущность, но не используются при описании отношений между сущностями.
 В отношении связности первичный ключ родителя мигрирует к потомку. Если отношение - это связь категоризации, то первичный ключ потомка - это ключ родителя. Если отношение - это идентифицирующее отношение, то первичный ключ потомка обязан содержать наследуемые от родителя атрибуты.
 Помимо того факта, что ключ обязан однозначно идентифицировать сущность, все атрибуты ключа должны удовлетворять условию однозначной идентификации (правило наименьшего ключа). Таким образом, при определении должен ли наследуемый атрибут быть частью ключа, следует ответить на вопрос: «Необходим ли этот атрибут для однозначной идентификации?» Однозначной идентификации родителя при этом недостаточно. 
 Внешние ключи - являются не совсем настоящими ключами, а атрибутами, наследуемыми от первичных ключей других сущностей. Внешние ключи помечаются меткой (FK - foreign key), чтобы выделить, что они не принадлежат сущности. Внешние ключи весьма важны для изображения отношений между сущностями. Так как сущности определяются своими атрибутами, если сущность состоит из атрибутов, наследованных из других сущностей, то эта сущность является подобной тем сущностям. Это свойство используется для реализации сложных выборок из базы данных.
 IEF1X является мощным средством моделирования данных наряду с множеством других методов, таких как ER и ENALIM. Достоинство IDEF1X лежит в его истоках. Благодаря жесткой стандартизации всех проектов МО США методу IEF1X удалось избежать неоднозначности в толковании основных положений, что повредило использованию метода ER.

Наличие стандарта и твёрдое следование ему является существенным для обмена информацией между организациями.
 Недостатком всех таких методов, включая IDEF1X,
является тот факт, что разработчик обязан быть опытным специалистом. Моделирование носит итеративный и коллективный характер (разработчик, эксперт и др.).

3.3. Стандарт ISO 10303 (STEP)

3.3.1. Структура стандарта
 ISO 10303 (STEP - Standard for the Exchange of Product Model Data) — это международный стандарт для компьютерного представления и обмена данными о продукте (изделии). Цель стандарта — дать нейтральный механизм описания данных о продукте на всех стадиях его ЖЦ, не зависящий от конкретной системы. Природа такого описания делает его подходящим не только для нейтрального файла обмена, но и в качестве базиса для реализации и распространения баз данных о продукте, а также для архивирования.
 В соответствии с названием, STEP определяет «нейтральный» формат представления данных об изделии в виде информационной модели. Для обеспечения возможности единообразного описания изделий в различных прикладных областях, предполагается, что информационные модели (в терминах стандарта «прикладные протоколы») создаются на базе типовых блоков («интегрированных ресурсов»), причем для описания схем данных используется специально введенный язык EXPRESS. Язык EXPRESS является одним из разделов стандарта ISO 10303 STEP и описан в 11 томе стандарта ISO 10303. Он регламентирует черчение (прямое и ассоциативное), проектирование конструкций, инженерный анализ, технологическую подготовку, производство, тестирование данных и обмен ими (в том числе с IDEF-моделями) в специальном текстовом формате, который обеспечивает безопасность и надежность передачи информации по Интернет партнерам.

Рис.8. Структура стандарта ISO 10303
Стандарт ISO 10303 включает в себя 8 разделов, тесно связанных друг с другом (рис.8), каждый из которых, в свою очередь, состоит из томов (см. Приложение 1). Перечень разделов включает в себя:
· методы описания (язык EXPRESS);
· стандартные решения (способы применения);
· структура и методология проверки на совместимость;
· общие интегрированные ресурсы;
· прикладные интегрированные ресурсы ;
· прикладные протоколы (в различных отраслях);
· набор абстрактных тестов (абстрактные примеры);
· элементы для конкретных приложений
 Каждый том документации по ISO 10303 начинается с одной и той же преамбулы, определяющей назначение и
структуру ISO 10303, а именно: «ISO 10303 — международный стандарт для компьютерного представления и обмена данными о продукте». Цель стандарта—дать нейтральный механизм описания данных о продукте на всех стадиях его ЖЦ, не зависящий от конкретной системы.
 Приведенное определение ISO 10303 нуждается в комментариях.
 1. Под продуктом не обязательно понимать материальный продукт производства, продуктом считается результат любого процесса, в частности, разработки технологического плана.
 2. Утверждать, что ISO 10303 является стандартом обмена данными о продукте, можно лишь при расширенной трактовке STEP (ISO 10303) как стандарта, включающего в себя стандарты PLIB и MANDATE. С технологической точки зрения это так и есть, поскольку PLIB и MANDATE строятся на базе стандарта STEP, заимствуя из него методы описания (язык EXPRESS), формы реализации (обменный файл и интерфейс доступа к данным) и, при необходимости, интегрированные ресурсы (информационные структуры).

С потребительской же точки зрения каждый из трех стандартов имеет свою предметную область:
 ISO 13584 (PLIB) дает средства описания продукта внутри производства во внутренней сфере обращения (здесь под продуктом уже понимается материальный продукт производства, участвующий в товарообмене). Он представляет информацию о библиотеке изделий вместе с необходимыми механизмами и определениями, обеспечивающими обмен, использование и корректировку данных библиотеки изделий. Имеется в виду обмен между различными компьютерными системами и средами, связанными с ЖЦ продукта, где могут использоваться изделия библиотеки, включая проектирование, изготовление, эксплуатацию, обслуживание и утилизацию продукта.
 ISO 15331(MANDATE) описывает динамику производства как снаружи (связи производства с внешней средой), так и изнутри (материальные и информационные потоки в организационно-производственной структуре, короче — интегрированная модель производства).
 Конструкторские данные об изделии занимают значительную часть в объеме информации, используемой в ходе его жизненного цикла. На основе этих данных решается ряд задач производства изделия, материально-технического снабжения, сбыта, эксплуатации и т. д. Сегодня, несмотря на широкое применение компьютерных технологий, преимущества электронного представления информации не используются в полной мере. Хотя объем проектных работ, выполняемых с использованием автоматизированных систем проектирования, достаточно высок, полученные результаты, как правило, все равно переводятся из электронного вида в форму бумажных документов. Одна из причин – сложность интеграции результатов различных процессов.
 CALS-технологии, в частности стандарт ISO 10303 STEP, предлагают способ решения этой проблемы при помощи использования стандартизованного интегрированного описания изделия.

 Интегрированное электронное описание изделия - это набор данных различного типа, полученных в ходе проектирования различными способами, а затем преобразованных в стандартизованный вид и достаточных для решения задач последующих этапов ЖЦ. Например, конструкторское электронное описание в соответствии со стандартом STEP содержит структуру и варианты конфигурации изделия, геометрические модели и чертежи, свойства и характеристики составных частей и др. (см. рис. 9).

Рис. 9. Конструкторское электронное описание изделия в соответствии со стандартом STEP
         База данных, логическая структура которой соответствует стандарту, является основой информационной интеграции автоматизированных систем, использующихся на предприятии и нуждающихся в информации об изделии. При этом единое представление и расположение данных позволит обеспечить полноту и целостность информации, а также избавит от возможного искажения информации.
Данные о конструкции в формате STEP могут быть использованы для технической подготовки производства, планирования потребностей, управления производством и т.д.
Стандарт STEP регламентирует: логическую структуру базы данных (БД), номенклатуру информационных объектов, хранимых в БД, их связи и атрибуты. Типовые информационные объекты, такие как данные, о составе изделия, материалах, геометрических изделиях, независимые от характера описания изделия, называются в стандарте «интегрированными ресурсами», на основе которых строятся схемы баз данных об изделии для разных предметных областей автомобилестроения, судостроения, аэрокосмической промышленности и т.д. (см. рис. 8, 10).
         Готовые схемы баз данных называются в стандарте «протоколами применения» (прикладными протоколами, как это показано на рис.8) и представляют собой типовые решения.
         Практически, стандарт STEP может быть применен несколькими способами.
         1. Данные могут храниться в виде текстового обменного файла. В этом виде их удобно передавать между автоматизированными системами, имеющими соответствующий модуль (конвертор) работы с файлом в формате STEP.

         2. Структуры данных могут быть созданы в готовой PDM системе путем ее соответствующей настройки и разработки соответствующих визуальных приложений.
         3. Могут быть использованы готовые решения.
База данных, логическая структура которой соответствует стандарту, является основой информационной интеграции автоматизированных систем, использующихся на предприятии и нуждающихся в информации об изделии. При этом единое представление и расположение данных позволит обеспечить полноту и целостность информации, а также избавит от возможного искажения информации.

Рис. 10. Новый базис для информационной интеграции
         Такой подход создает новый базис для информационной интеграции и преемственности в использовании информации и позволяет решить большой круг задач, вот только некоторые из них.
         1.Организация обмена данными о составе изделия между двумя организациями, например, между заводом-производителем и дистрибьютором с тем, чтобы дать потребителю возможность заказать запасные части. Соответствующий том стандарта дает готовое решение – стандартизованный обменный файл. Создать его и работать с ним можно, используя конверторы, имеющиеся практически во всех современных CAD системах, либо программные системы третьих фирм, в том числе отечественных.
         2. Продажа лицензии на производство продукта. Фактически, речь идет о необходимости поставки конструкторской и технологической документации в электронной форме. Аналогичная ситуация возникает при кооперации с зарубежными партнерами. Решением этой проблемы также является использование стандартизованного обменного файла.
         3. Создание на предприятии интегрированного хранилища конструкторских данных по изделиям. Стандарт ISO 10303 предлагает готовую модель данных для такого хранилища. Преимуществом такого подхода является то, что он позволяет организовать взаимодействие с хранилищем на уровне программного интерфейса любых источников и потребителей данных, в том числе разнородных систем проектирования и управления производством.

         4. Ведение библиотек изделий (каталогов запасных частей, стандартных элементов). Логическая структура базы данных, описанная в стандарте STEP, позволяет создавать категории изделий и наделять их характеристиками.
3.3.2. Продукты поддержки стандарта STEP
         ST-Developer включает набор средств для разработки STEP-приложений: средства информационного моделирования, средства верификации данных в формате STEP и библиотеки для организации доступа к STEP-моделям для языков С, С++, Java
         ST-Database Adaptors содержит набор программных продуктов, расширяющих возможности ST-Developer. Они обеспечивают загрузку и выгрузку данных в формате STEP в популярные СУБД: Oracle, Object Store и Versant.
         ST-EXPRESS - средства информационного моделирования для аналитиков и разработчиков прикладных протоколов STEP. Включают в себя собственно компилятор языка информационного моделирования EXPRESS и набор средств для работы с графическим представлением языка - EXPRESS-G.
         ST-ACIS обеспечивает конвертирование твердотельных моделей в формате ACIS в геометрию STEP и обратно. Поддерживает геометрические модели STEP согласно прикладному протоколу АР203. Представляет из себя либо отдельно исполненный транслятор, либо библиотеку для С++ с целью использования в собственных разрабатываемых приложениях.
         ST-Visualizer - средство просмотра геометрических 3D моделей, описанных в формате STEP. Отображает тонированные твердотельные модели и может импортировать векторную и поверхностную геометрию по стандарту IGES. Обеспечивает функции вырезки и вставки геометрических примитивов между STEP-файлами и редактирование топологии твердотельных моделей.
         ST-WebPublisher позволяет обеспечить доступ к моделям в формате STEP с использованием Web-технологии. Обеспечивает как просмотр геометрии в STEP-модели, так и данных конфигурации изделия. В состав ST-WebPublisher входят средства и шаблоны для создания HTML-страниц, растровых образов в формате GIF и Java по исходному обменному файлу STEP Part 21.

3.3.3. Основные элементы языка EXPRESS
        Накопленные человечеством знания всегда формулируются в контексте иерархической системы (более строго — ациклической сети) понятий и функцио нальных связей между этими понятиями. Такая структура представления знаний моделируется при объектно-ориентированном подходе в виде иерархии классов с механизмом наследования общих свойств.
         Реализация объектно-ориентированного подхода возможна в двух вариантах.
         Первый вариант — некоторый набор знаний сразу доводится до уровня машинной программы. В этом случае необходим язык программирования, поддерживающий функционально полное описание класса. Практически это означает, что описание класса должно включать как данные (перечень атрибутов класса), так и «методы» (программы, реализующие полный набор операций над объектами данного класса). C++, Симула-67 — примеры языков объектно-ориентированного программирования, то есть реализации подхода по первому варианту.
         Второй вариант — моделирование иерархии понятий и функциональных связей раздельно. В этом случае из описания класса исключаются методы. Описание становится декларативным и уже не связано с использующей его программой. Независимость описания классов от программной реализации делает излишней конкретизацию формата внутреннего преставления данных в ЭВМ. В итоге мы приходим к языку EXPRESS , предназначенному для описания иерархических систем понятий. Поскольку разнообразие таких систем определяется только разнообразием предметных областей знания, интеграция понятий в единую международную (стандартную) систему понятий становится реально достижимой целью, приближающей к решению глобальной проблемы представления знаний в ЭВМ.
         Во втором варианте проектирование программного продукта включает три вида деятельности: информационное моделирование, функциональное моделирование и программную реализацию.

Стандарт STEP (в расширенной трактовке) должен обеспечить интеграцию понятий в предметной области «промышленное производство продукции», то есть представить единую информационную модель этих понятий в виде, формализованном на уровне спецификаций EXPRESS .
         Информационное моделирование (на базе методологии IDEF1Х) представляет информацию о сущностях, их связях и атрибутах, которое может быть использовано далее при создании спецификаций EXPRESS.
          Функциональное моделирование отвечает за второй элемент представления знаний — функциональные связи между понятиями. Интеграция знаний в этой области пока осуществляется без привлечения ЭВМ, хотя предпринимаются попытки как-то регламентировать представление знаний, в частности, средствами IDEFO. В стандарте STEP средства IDEFO используются для иллюстративного представления сферы использования приложения — программной реализации стандартного протокола приложения АР, содержащего специализированную информационную модель.
         Наконец, стандарт STEP касается и третьей компоненты
проектирования — программной реализации стандартного АР. Для каждого стандартного протокола его разработчиками составляется набор абстрактных тестов, по которому проверяется реализация протокола на соответствие требованиям АР (см. рис.8). Следует отметить, что структура функциональной модели приложения (и, следовательно, представление в ЭВМ функциональных связей между понятиями) не определяется стандартом STEP, а лишь ограничивается снизу требованием, чтобы ЭВМ «владела» понятиями информационной модели, по крайней мере, на уровне минимальных требований, заданных набором абстрактных тестов.
         Второй вариант является предпочтительным для использования в CALS, поскольку информация для создания информационных систем предварительно систематизируется и верифицируется.
         В разработке первой версии языка EXPRESS участвовало порядка 20 человек в период с 1985 по 1991 год.

Проблема не ограничивалась изъятием методов из структуры описания класса. Требовалось разработать специализированный язык информационного моделирования, достаточно полный для описания любой системы понятий, связанных с производственной деятельностью, достаточно простой для освоения пользователем-непрограммистом и, наконец, достаточно технологичный для работы приложений с языковыми конструкциями. Конкретизация предметной области использования языка EXPRESS была необходима по существу, так как имеются области знания с более сложными структурами понятий (например, семиотика), ориентация на которые могла бы привести к чрезмерному усложнению проблемы.
Итак, язык EXPRESS предназначен для описания информационных моделей (как и метод IDEF1Х). Информационная модель описывается одной или несколькими взаимосвязанными схемами. Схема состоит из набора элементов, который может включать в себя:

	- объекты (ENTITY);
	- типы (Type);
	- константы (Constant);
	- правила (Rule);
	- функции (Function) и процедуры (Procedure), необходимые для проверки правил и для вычисления значений производных атрибутов.

         Прикладной протокол AP - это схема, описывающая некоторую предметную область. Прикладной протокол включается в стандарт как один из томов стандарта. Имена объектов, констант, функций, процедур, правил и типов уникальны в пределах данной схемы.
         База данных (БД), формируемая в соответствии с описанием EXPRESS -схем, предназначена для хранения произвольного количества экземпляров каждой из сущностей, представленных в схемах. Сущность — информационный объект, характеризующийся идентификатором и списком атрибутов, определяющих свойства каждого из экземпляров сущности. Остальные элементы описания схемы играют вспомогательную роль, а именно: type-объявления определяют структуру представления атрибутов сущности. Алгоритмы и правила служат для проверки соответствия содержимого БД информационной модели, а интерфейс предназначен для унификации описания объектов (типов, алгоритмов, правил),

используемых более чем в одной схеме.
         Возможности описания информационных структур в языке EXPRESS сводятся, в основном, к следующим. Прежде всего, имеется набор стандартных (встроенных в EXPRESS) данных, состоящий из группы простых типов, включающей типы number, integer, real, logical, boolean, binary, string, и из группы агрегативных типов, включающей типы array, bag, list, set — разновидности множества однотипных компонент. При использовании в схеме простых типов real, binary, string можно специфицировать их формат, а при использовании агрегативных типов — их размеры (границы).
         С помощью entity-объявлений и type-обьявлений разработчик схемы вводит собственный набор именованных типов, дополняя набор стандартных
типов до набора «базовых».
Базовый тип может использоваться в качестве
компоненты агрегативного,
а также в entity-объявлении
для описания атрибута посредством конструкции: идентификатор атрибута: базовый тип
         В type-объявлениях определяемый тип описывается ссылкой на «определяющий» тип, который может быть простым, агрегативным,
определяемым, перечисления или селекторным. Тип перечисления — это упорядоченный список конкретных строк-наименований. Селекторный тип — это любой из именованных типов, перечисленных в объявлении селекторного типа.
         Каждому типу данных соответствует
определенная область допустимых значений — домен. Областью допустимых значений атрибута является домен соответствующего базового типа, который определяется деревом определений типов, связывающих базовый тип с терминальными
типами (простыми типами и/или entity-типами), которые и определяют структуру атрибута. В этой структуре каждому простому типу в атрибуте экземпляра сущности должно соответствовать конкретное значение из домена этого типа и каждому entity-типу — ссылка (указатель) на конкретный экземпляр соответствующей сущности.
         Домен стандартных типов может иметь переменные размеры.

Поэтому структура атрибута может варьироваться по размерам в разных экземплярах сущности. Более того, при наличии в entity-обьявлении
необязательных (optional) атрибутов их структуры в некоторых экземплярах сущности могут отсутствовать вообще. По аналогии с использованием термина «популяция» в документации по EXPRESS для обозначения содержимого БД популяцией сущности называют совокупность
всех имеющихся в БД ее экземпляров. Если трактовать популяцию сущности как файл записей — экземпляров сущности, — то, как видим, придется уточнить, что запись может варьироваться в файле по размерам и составу атрибутом (в пределах максимального состава).
         Ограниченность значений атрибута рамками домена соответствующего базового типа является необходимым, но не всегда достаточным условием соответствия БД информационной модели. Для описания подобных ограничений в языке предусмотрены логические функции типа глобальных правил (rules).
         Для спецификации локальных и глобальных правил язык EXPRESS дополнен широким набором операций с данными, тремя формами описания алгоритмов (функция, процедура, правило), наконец, набором стандартных функций и процедур оперирования данными,
короче — средствами функционального моделирования, присущими процедурным языкам программирования.
         Описание языка EXPRESS начинается с утверждения, что значение атрибута не может служить ключом поиска нужного экземпляра. Очевидно, это утверждение не следует понимать как отрицание необходимости процедур поиска по ключу в вычислительном процессе. Скорее всего, это намерение разделить проблему установления связей между экземплярами (это сфера программирования) и проблему описания информационной структуры, позволяющей зафиксировать установленную связь в виде соответствующей ссылки (это сфера применения языка EXPRESS). На самом деле полного разделения этих проблем достичь не удается. В связи с этим в EXPRESS вводится понятие уникальности значений группы атрибутов в популяции сущности, связанное с понятием ключевых атрибутов для процедуры поиска.

         Рассмотренный выше тип связи между экземплярами сущностей по атрибутам (с помощью ссылок на необходимые экземпляры) является одним из двух имеющихся в языке EXPRESS типов связей. Второй тип связи — «генетический», или механизм множественного наследования, — состоит в следующем. С помощью subtype-предложения в entity-объявлении можно указать список сущностей — непосредственных «предков» данной сущности, от которых она наследует все свойства — атрибуты, правила и алгоритмы. Отношение наследования транзитивно, то есть вместе с наследованием свойств непосредственных предков наследуются свойства предков вышестоящего уровня, а в итоге — свойства всей «родословной». Наследование атрибутов означает их непосредственное включение в структуру собственных атрибутов сущности, в результате чего образуется «сложный» экземпляр.
         При формировании сложного экземпляра необходимо задать значения как собственным атрибутам сущности, так и атрибутам всех предков. Следует заметить, что структура сложного экземпляра, относящаяся ко всей совокупности предков и рассматриваемая с уровня одного из предков сущности, однозначно определена информационной моделью лишь в сторону его предков, но не потомков, состав которых может зависеть от экземпляра. Поэтому при работе со сложным экземпляром на уровне сущности-предка доступу к атрибутам потомков предшествует обращение к стандартной функции type of, возвращающей список сущностей, представленных в экземпляре.
         Помимо механизма наследования, язык EXPRESS заимствовал из генетики и идею мутации, реализованную следующим образом: при наличии в одной схеме нескольких подтипов некоторой сущности по умолчанию считается, что в популяции этой сущности возможны экземпляры со свойствами, характерными для любого сочетания указанных подтипов, в связи с чем система обеспечивает автоматическую генерацию entity-объявлений всех возможных подтипов-мутантов.

         Остается перечислить языковые средства, обу словленные необходимостью компромисса между объемом памяти (длиной описания) и эффективностью вычислений.
        Во-первых, это вычисляемые (derive) атрибуты, функционально зависящие от явных атрибутов экземпляра-сущности. Хранение derive-атрибутов
в БД привело бы к избыточности информационной структуры, но их наличие в структуре экземпляра может сократить объем вычислений. Компромисс достигается следующим образом: в структуре хранения популяции сущности в БД derive-атрибуты
отсутствуют, а при загрузке экземпляра в оперативную память системой обеспечивается пополнение структуры derive-атрибутами
и вычисление из значений.
         Во-вторых, это инверсные атрибуты сущности, или «обратные» ссылки. При работе с экземпляром сущности может потребоваться доступ к другим экземплярам той или иной сущности, из которых исходят «прямые» ссылки (по атрибуту) на данный экземпляр. Хотя в системе предусмотрена стандартная функция used in,
формирующая множество таких экземпляров на основе полного просмотра популяции сущности, меньших вычислительных затрат потребовала бы технология фиксации всех «обратных» ссылок на эти экземпляры на этапе появления прямых ссылок при формировании популяции сущности. Такая технология реализуется системой по «заказу» разработчика схемы, представленному в виде соответствующих инверсных атрибутов.
         Как уже указывалось, цель ISO 10303 — дать стандарт
описания данных о продукте на всех стадиях его ЖЦ. Поскольку состав данных о продукте существенно зависит как от дисциплины (классификационной группы) продукта, так и от стадии его ЖЦ, конечной целью ISO 10303 является разработка множества частных информационных моделей АР, каждый из которых характеризуется своим контекстом — дисциплиной и стадией ЖЦ продукта. В то же время было бы неверно разрабатывать АР без учета их частичной пересекаемости по информационным объектам, то есть возможности выделения в каждом АР контекстно-независимой части и объединения этих частей в группу моделей верхнего уровня — интегрированных ресурсов.

        Выбран наиболее простой способ реализации этой
возможности, а именно: сначала разработать в достаточно полном объеме структуру и состав интегрированных ресурсов и соответствующий набор первичных сущностей, разработку каждого АР регламентировать условием, что сущностями EXPRESS -схемы АР (так называемой «интерпретированной модели приложения» —AIM)
могут быть только подтипы (потомки сущностей, представленных интегрированными ресурсами (ИР), при возникновении исключительной ситуации, когда для сущности, необходимой приложению, не удается найти предков в ИР, его состав пополняется необходимыми о6ъектами.
Состав документации по информационным моделям ISO 10303 открыт для пополнения новыми томами в рамках соглашения о том, что для ИР отводятся номера томов в интервале 41-199, а для АР — в интервале 201-1199 (см. Приложение). Кроме того, документация по ИР разделяется на серию общих ресурсов (тома 41-99) и серию ресурсов приложения (тома 101-199). В отличие от общих ресурсов, сфера применимости которых полностью контекстно-независима, ресурсы приложения ориентированы на конкретные области применения. Наконец, к категории ИР можно отнести и библиотеку А1С EXPRESS-схем, описывающих отдельные понятия предметной области, используемые в двух и более АР. Такая форма обеспечения информационной совместимости различных АР поддерживается централизованным ведением этой библиотеки специальной службой.
         В настоящий момент происходит процесс замены стандартов первого поколения вновь разрабатываемыми и процесс этот еще далеко не завершен. Поэтому существующий комплекс стандартов представляет собой комбинацию стандартов обоих типов, позволяющих, тем не менее, хотя и с ограничениями, строить интегрированные информационные модели и обмениваться данными на всех стадиях ЖЦ.

3.4. Стандарт ISO 13584 (PLIB)
         Продукт, как правило, включает в себя компоненты и комплектующие изделия, получаемые от поставщиков. Одни и те же компоненты и комплектующие одновременно могут входить в разные продукты, поэтому существует потребность в средствах их самостоятельного информационного описания, отдельно от продуктов, в которые комплектующие изделия могут входить.

          ISO 13584 Parts Library - это серия международных стандартов для представления и обмена доступными для компьютерной интерпретации данными о поставляемых компонентах и комплектующих изделиях (узлах, деталях). Схема информационного взаимодействия с поставщиком деталей (комплектующих изделий) в соответствии с ISO 13584 приведена на рис. 11.
         Стандарт ISO 13584 PLIB включает в себя 7 разделов:
- общий обзор и основополагающие принципы;
- концептуальная модель библиотеки деталей;
- основные ресурсы;
- логическая модель библиотеки поставщика;
- данные о поставщике;
- программный интерфейс к данным;
- методология структуризации классов (семейств) деталей.

Рис.11. Схема информационного взаимодействия с поставщиком деталей
            (комплектующих изделий) в соответствии с ISO 13584
         Стандарт ISO 13584 регламентирует:
- средства описания и технологию представления информации о компонентах и комплектующих;
- технологию обработки данных, в том числе хранения, передачи, доступа изменения и архивирования.
         В отличие от стандарта ISO 10303 STEP, предназначенного для описания конкретного экземпляра продукта, стандарт PLIB позволяет описывать классы продуктов (компонентов и комплектующих):
- стандартные детали, определенные международными или национальными стандартами (например, крепеж или подшипники);
- библиотеки (базы) данных о деталях конкретного поставщика.
         В процессах проектирования, обмен данными о деталях и комплектующих, например между системами проектирования A и B, может иметь два контекста: обмен метаданными (данными об информационных моделях деталей) и обмен собственно данными о деталях. В последнем случае должен использоваться стандарт ISO 10303 STEP.
3.5. Стандарт ISO 15531 (MANDATE)

         Стандарт ISO 15531 MANDATE (Manufacturing Data for Exchange) - регламентирует некоторые вопросы представления производственных данных. Областью стандартизации является форма представления и методы использования информации о производстве и используемых производственных ресурсах, их характеристиках и ограничениях с точки зрения управления производством.

         Стандарт MANDATE состоит трех разделов (см. Приложение 1):
- представление производственных данных для внешнего обмена;
- данные по управлению использованием производственных ресурсов;
- представление данных по управлению производственными потоками.
         Первый раздел
определяет требования к обмену производственной информацией между компаниями, на основе использования протоколов «электронного обмена данными» EDI (Electronic Data Interchange). Особое внимание уделено следующим вопросам:
- данные, которыми обменивается между собой коммерческая и производственная сферы;
- информация, требуемая для планирования производства;
- информация, содержащаяся в получаемых заказах;
- информация, получаемая от сферы закупок;
- информация, необходимая для управления поставщиками и дочерними компаниями;
- информация, необходимая для приема и распределения изделий.
         Второй раздел
посвящен представлению данных по управлению использованием производственных ресурсов (оборудование, энергоснабжение, транспорт и пр.). Сюда относятся описание и характеристики ресурсов, управление работой промышленного оборудования, вопросы качества, обслуживания и безопасности.
         Описание производственных ресурсов может быть представлено в виде баз данных, содержащих:
- параметры ресурсов;
- входы и выходы;
- объем и мощность;
-прикладное программное обеспечение;
- степень внутреннего управления и уровень интеллектуальности;
- ссылки на стандартные ресурсы;
- планы работы и управление обслуживанием;
- данные о стоимости и т.д.
         Третий раздел
посвящен представлению данных об управлении производственными потоками, в том числе данных о материальных потоках в дискретном производстве, информации, необходимой для планирования, управления и мониторинга потоков материалов. Рассматриваются следующие вопросы:
- определение объемов производства;
- управление производством;
- планирование производства;
- планирование потребности в ресурсах;
- работа по схеме «точно вовремя» (just in time);

- оптимизация технологии производства;
- оценка планов;
- мониторинг производства;
- учет стоимости;
- планирование процессов;
- спецификации изделий.
3.6. Стандарт ISO 8879 (SGML)
         Вследствие возникшего многообразия способов представления текстовой и тексто-графи-ческой информации, связанных с применением разнородных программных средств, технологий форматирования и верстки текста, методов кодировки и поддержки национальных языков, появилась потребность в разработке унифицированных решений.
         Такое решение содержится в стандарте ISO 8879 (SGML, Standard Generalized MarkUp Language), определяющем «обобщенный стандартный язык разметки» текста.
        Термин «разметка» носит исторический характер - имеются ввиду метки, которые обычно делает редактор в процессе подготовки текста к верстке. Технология электронной разметки текста, основанная на вставке в текст специальных меток, широко используется в современных программных средствах верстки и форматирования. Метки условно можно разделить на два класса: процедурные и описательные.
         Процедурные метки используемые, например, в программах Microsoft Word и Quark XPress чаще всего представляют собой коды форматирования, вставленные в текст документа.
        Описательные метки, известные также под названием «обобщенных» (generalized), определяют не способ появления текста на странице, а назначение текста в документе. Описательные метки отделяют структуру документа от стиля его отображения, позволяя для одного документа иметь различные способы его отображения на экране или бумаге.
         С точки зрения стандарта SGML документ рассматривается как совокупность:
- содержания
(информации, содержащейся в документе в текстовой, графической и мультимедийной форме);
- данных о структуре документа (взаимосвязи глав, разделов, параграфов, ссылки, прав доступа к элементам документа);
- данных о стиле оформления документа (используемых шрифтах, интервалах, размерах полей, способе нумерации и т.д.).

         Стандарт ISO 8879 SGML определяет способ описания структуры документа, а также формат вставляемых в документ описательных меток, но не определяет формат данных о стиле оформления документа. Структура документа задается при помощи «определения типа документа» (в терминах стандарта - Document Type Definition или сокращенно DTD), описывающего структуру документа подобно тому, как схема базы данных описывает типы поддерживаемых данных и отношения между полями. Определение типа документа (ОТД) задает взаимосвязь глав, заголовков глав, разделов и других фрагментов текста, образующих документ. Кроме того, ОТД задает правила для отношений между элементами документа, например: «заголовок главы должен быть первым элементом после начала главы» или «каждый список должен содержать по меньшей мере два пункта». Правила, содержащиеся в ОТД, позволяют автоматически контролировать правильность логической структуры документа. Таким образом, разные ОТД позволяют получить из одного и того же набора элементов разные документы (см. рис.12).
         Помимо текстовой и графической информации, в SGML-документ могут быть вставлены мультимедийные элементы: аудио и видео-записи и клипы. Технология встройки мультимедийных элементов регламентируется специальным расширением SGML, описанным в стандарте ISO 10744 HyTime (Hypermedia/TimeBased Structuring Language) - языком «привязки» мультимедийных объектов.
         В разделе, посвященном подготовке интерактивных электронных технических руководств, рассмотрен наглядный пример использования SGML – технологии.
Основные преимущества SGML - технологии:
1) формализация структуры документа, обеспечивающая возможность:
- описать правила, по которым формируется структура документа,
- автоматической генерации и контроля структуры документа,
- автоматического наполнения документа;
2) возможность распределенной подготовки различных разделов по строго определенным правилам (единая структура документа, единое стилевое оформление) и централизованная композиция конечного документа;

                 Рис.12. Формирование документов из составных элементов на основе ОТД
3) возможность создания многовариантных документов: например предназначенных для работы с гаммой или семейством изделий, имеющих отличия;
4) возможность обеспечивать доступ к содержимому документа в соответствии с ролью пользователя (техник, инженер, и т.д.);
5) возможность создавать многоязычные документы;
6) поддержка любых способов представления информации – текстовая информация, изображения (растровые, векторные);
7) аудио-, видеоинформация, навигация и поиск по структуре документа.
       Недостатком стандарта ISO 8879 SGML является его некоторая избыточность и громоздкость. По этой причине в последние несколько лет в мире ведутся активные работы по его совершенствованию. Одним из результатов такой работы является «облегченная» версия SGML, названная XML (Extensible Markup Language) - расширяемым языком разметки.

4. ЭЛЕКТРОННАЯ МОДЕЛЬ ИЗДЕЛИЯ

4.1.Требования к электронной модели изделия
и средствам ее поддержки
         Сразу отметим, что в некоторых источниках электронную модель изделия (ЭМИ) называют единой информационной моделью (ЕИМ). По нашему мнению, ЕИМ больше подходит к информационной модели предприятия или их совокупности. Но, видимо, и термин ЕИМ имеет право на существование, тем более, что терминология в такой новой области, как CALS, еще не устоялась.
         Для того, чтобы служить единым источником информации об изделии, ЭМИ должна удовлетворять ряду требований:
- состав данных должен соответствовать потребностям в конструкторской информации на всех стадиях жизненного цикла;
- обеспечивать возможность поддержки установленных регламентов и процедур процесса проектирования в части доступа к данным, их использования и модификации;
- средства поддержки электронной модели изделия должны обеспечивать возможность параллельного проектирования;
- состав данных и средства поддержки должны обеспечивать управление конфигурацией изделия;

- средства поддержки электронной модели изделия должны обеспечивать преобразование информации, получаемой из различных источников в стандартный электронный вид.
         Рассмотрим эти требования подробнее.
         Состав данных должен обеспечивать потребности в конструкторской информации на всех стадиях жизненного цикла.
         Автоматизированные системы, предназначенные для поддержки ЭМИ, в современной литературе обозначаются термином PDM - системы управления данными о продукте. Как уже отмечалось, для информационного описания изделия разработан стандарт ISO 10303 STEP. В соответствии с ISO 10303 электронная конструкторская модель изделия включает в себя геометрические данные, данные о конфигурации изделия, административные данные, неструктурированные данные.
         Средства поддержки ЭМИ должны обеспечивать возможность соблюдения регламентов и процедур процесса проектирования.
         В ходе проектирования конструкторская информация создается и многократно модифицируется. На последующих стадиях разработанная информация в основном только используется. На этапе проектирования очень важно обеспечить соблюдения установленных регламентов, связанных с принятием решений и их утверждением, процедурами проведения изменений и т.д., с тем чтобы не нарушить целостность и корректность электронной модели
         Средства поддержки электронной модели должны обеспечивать возможность параллельного проектирования.
         Электронная модель изделия и средства ее поддержки должны обеспечивать возможность параллельного проектирования. Это означает, что информация, полученная на очередном этапе проектирования, немедленно должна стать доступной для решения других задач. Например, при проектировании автомобиля, геометрическая модель кузова может быть передана на этап технологической подготовки для разработки штампов, не дожидаясь пока будет спроектирован вакуумный усилитель тормозов.
         Средства поддержки ЭМИ должны обеспечивать управление конфигурацией.

         Такой продукт как машиностроительное изделие характеризуется многовариантным составом и конфигурацией, означающее, что изделие может иметь несколько модификаций в соответствии с требованием покупателя, может состоять из различных элементов в зависимости от условий производства, рынка и материально-технического снабжения.
         Стандарт ISO 10303 STEP и его подраздел AP203 определяет представление конструкторских данных о машиностроительном изделии согласно концепции управляемой конфигурации. Термин «управляемая конфигурация» означает возможность определения комплектации изделия в зависимости от условий проектирования, производства или заказа. Современный рынок все больше поворачивается лицом к потребителю. Идя навстречу покупателю, производители предусматривают различные варианты и модификации изделий. Более того, согласно стандартам обеспечения качества ISO серии 9000, поставщик обязан предоставить потребителю возможность выбора комплектации изделия.
         Средства поддержки ЭМИ должны обеспечивать преобразование информации, получаемой из различных источников в стандартный электронный вид.
         В процессе проектирования электронная модель изделия наполняется данными, при этом не все данные могут быть получены сразу в желаемом виде. Средства поддержки должны обеспечивать преобразование информации, получаемой из различных источников, в стандартизованную форму.
         В общем случае информация об изделии может быть получена из следующих источников:
- непосредственно в формате STEP из систем CAD/CAM;
- преобразованием форматов электронных данных, полученных в различных автоматизированных системах;
- путем сканирования бумажной документации и ее перевода в электронный вид. Как правило, это чертежи и текстовые документы: пояснительные записки, отчеты и т.д.
4.2. Способы реализации средств поддержки
электронной модели изделия
         В настоящее время для работы с электронной моделью изделия используются средства автоматизации, относящиеся к классу PDM-систем (Product Data Management).

         Согласно стандартам серии ISO 9000 PDM-система должна:
- однозначно идентифицировать варианты каждого изделия;
- идентифицировать состояние изделия, находящегося в разработке или уже поставленного потребителю;
- управлять модификацией изделия, проводимой более чем одним человеком;
- обеспечивать координацию работ по модификации многочисленной продукции, производимой в одном или более местах;
- идентифицировать и прослеживать все мероприятия и изменения, вызванные изменившейся заявкой, начиная с самого зарождения до выпуска продукции.
         Функции системы поддержки электронной модели изделия:
- поддержка полной конструкторской модели изделия;
- обеспечение регламента проведения изменений;
- обеспечение управления конфигурацией и составом изделия;
- обеспечение преобразования информации, получаемой из различных источников в стандартный вид.
Перечисленные функции реализуются за счет:
- хранения электронной модели изделия с использованием международных стандартов (ISO 10303, ISO 8879, и т.д.);
- организации доступа к электронной модели изделия для ПО с помощью программных интерфейсов (API), для персонала с помощью клиентских приложений;
- тесной интеграции с существующими у пользователей решениями.
С системотехнической точки зрения система поддержки электронной модели изделия является трехзвенной системой (см. рис.13): сервер хранения данных на основе СУБД, сервер предварительной обработки данных и клиентские части.
         Сервер хранилища. Сервер хранилища хранит информацию пользователей и предоставляет доступ к ней. Базовым элементом является СУБД Oracle 8, единственная в России СУБД, сертифицированная ФАПСИ для хранения информации, содержащей Государственную тайну (сертификат №168 о соответствии требованиям безопасности №РОСС RU.0001.01БИ00). На сервер хранилища стекается вся информация от предприятий, участвующих в процессе проектирования, поэтому доступ к серверу производится через Интернет.
         Сервер обработки данных. Сервер обработки данных выполняет предварительную обработку данных перед их загрузкой или получением от сервера хранилища.

Один сервер хранилища может обслуживать несколько серверов обработки данных.

                     Рис.13. Система электронной поддержки модели изделия

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

         Административные данные. Эта группа данных имеет дело с организационной структурой, сведениями о проекте, ролями, утверждениями, секретностью, контрактами, данными о сертификации и т.д.
Неструктурированные данные. С помощью этой группы данных удается хранить в ЭМИ документацию, программное обеспечение, мультимедийные данные и т.д.
Высокоуровневый интерфейс построен по аналогии с широко известным языком запросов к реляционным БД – SQL.
4.3. Пример системы управления данными об изделии: PDM STEP Suite
        Разработчик PDM STEP Suite: НИЦ CALS-технологий «Прикладная логистика».
       Назначение PDM STEP Suite - собрать всю информацию об изделии в интегрированной базе данных (БД) и обеспечить совместное использование этой информации в процессах проектирования, производства и эксплуатации.
В основе PDM STEP Suite лежит международный стандарт ISO 10303 (STEP) (в РФ действует ГОСТ Р ИСО 10303), определяющий схему (модель) данных в БД, набор информационных объектов и их атрибутов, необходимых для описания изделия.

На стадии проектирования база данных используется для накопления в стандартизованной форме результатов работы разработчиков и обмена данными между ними. Подготовленные, проверенные и утвержденные данные используются в процессах материально-технического снабжения, производства и эксплуатации изделия. В соответствии с требованиями стандрта ISO 10303 база данных системы PDM STEP Suite содержит информацию о структуре, вариантах конфигурации изделий и входимости компонентов в различные изделия, идентификационную информацию об изделии и его компонентах, геометрические модели различных типов или электронные образы бумажных документов (чертежей), данные об организационной структуре предприятия и соподчиненности ее элементов, роли и полномочия людей, данные о процессе разработки: выполненных утверждениях результатов работы, изменениях. Кроме того база данных может содержать ассоциированные с элементами изделия документы, а сами элементы иметь набор функциональных или технических характеристик, измеряемых в различных единицах. PDM STEP Suite ориентирована на использование в интегрированных системах автоматизации проектирования, производства и эксплуатации сложных машиностроительных изделий.

         Функции системы
         1. Ввод, проверка корректности, накопление, хранение данных об изделии, включающих в себя:
- структуру и состав изделия с учетом версий (модификаций) и условий комплектации, то есть перечень, соподчиненность и условия вхождения в сборку компонентов изделия, например, изделие, агрегаты, узлы, детали;
- геометрические трехмерные модели компонентов изделия (например каркасные, граничные точные и фасеточные твердотельные модели с топологией или без) – в соответствии с прикладным протоколом ISO 10303 АР203;
- конструкторскую текстовую и графическую документацию на изделие в целом и его компоненты (технические задания, рабочие проекты, расчетные и пояснительные записки, дизайнерские наброски и эскизы, геометрические модели и т.д.);
- данные о ролях, согласованиях и утверждениях на изделие в целом и его компоненты.
         Данные могут вноситься интерактивно, импортироваться из CAD/CAM (САПР) систем или заноситься любыми приложениями с помощью стандартного программного интерфейса SDAI или специального высокоуровневого интерфейса.
         2. Экспорт данных об изделиях в стандартный нейтральный формат STEP AP203 (ISO 10303-203) или в текстовый файл с настраиваемой структурой для последующей загрузки в различные прикладные системы.
         3. Обеспечение удаленного оперативного доступа к информации об изделии с контролем прав доступа.
        4. Обеспечение доступа к данным через унифицированный интерфейс, регламентированный стандартом ISO10303. Данный интерфейс (Standard Data Access Interface - SDAI) обеспечивает единообразный доступ ко всем данным, хранимым в системе.
         Состав системы PDM – STEP Suite
         С системотехнической точки зрения система PDM STEP Suite представляет собой трехуровневую информационную систему (см. рис.14), состоящую из сервера СУБД (Oracle 8), сервера приложений и клиентского модуля. Клиентский модуль обеспечивает диалоговое взаимодействие с базой данных через сервер приложений.
         Пользователь работает с базой данных, представляя ее себе в виде дерева изделия (или пересекающегося семейства деревьев изделий), ветви которого декомпозируются на сборочные узлы, агрегаты и отдельные детали (см.рис.15) .

С элементами дерева связаны документы, данные о выполненных действиях, характеристики.

Рис.14. Система электронной поддержки PDM STEP Suite

Рис.15.
Верхний уровень дерева отображает классификацию данных. Пример возможной классификации приведен на рис.16.

                                                              Рис.16
         Создание системы классификации - первый этап настройки системы PDM STEP Suite. Одновременно с этим необходимо создать описание организационной структуры, пользователей и их функции (роли). Затем - типы данных (элемент структуры, документ), возможные состояния документов (разработан, утвержден, отменен), грифы секретности, единицы измерения и характеристики компонентов (см. рис.17).
         Ввод данных осуществляется путем загрузки обменного файла из системы CAD/CAM, либо в диалоговом режиме: путем ввода обозначений входящих компонент, либо установлением ссылки на уже имеющиеся в базе данных объекты (компоненты). Последнее означает, что многократно используемые объекты, например, типовые детали, узлы, агрегаты описываются только один раз. Такие компоненты целесообразно поместить в категорию "…типовые решения" и использовать на них ссылки при создании структуры изделия.

                                                                     Рис.17
         Внутри категории "…типовые решения" равноценные компоненты могут быть помечены как "взаимозаменяемые изделия" (см. рис.18). При этом взаимозаменяемость может быть односторонней (изделие 1 заменяет изделие 2 , но изделие 2 не заменяет изделие 1) или двухсторонней (изделия 1 и 2 эквивалентны).



                                                               Рис.18

К элементам "дерева изделия" (см. рис.19) присоединяются геометрические модели, например, в формате STEP, электронные чертежи в формате DWG и пр., а также документы (растровые изображения, текстовые документы или файлы в иных форматах).

                                                                    Рис.19
         В процессе коллективной работы хранимый в базе данных документ, чертеж или модель могут быть взяты для дальнейшей доработки (создания новой редакции). При этом в базе данных исходная версия документа "замораживается" и помечается как находящаяся в процессе редактирования. После завершения редактирования создается новая версия, и хранится вместе с предыдущей. При этом запоминается порядок создания версий документа образующий дерево. То есть для каждой версии документа можно определить ту, на основе которой она была сделана.

Одна из версий документа является активной, то есть действительной на данный момент. При обращении пользователя к документу рассматривается именно активная версия. Но всегда можно обратиться к любой конкретной версии документа.
         Разработанные модели, чертежи или документы могут быть утверждены. Информационный объект "утверждение" (электронная подпись), присоединенный к документу, содержит данные о статусе утверждения и лице, осуществившем утверждение (см. рис.20). Все версии документов утверждаются отдельно. То есть при назначении активной неподписанной версии документа все подписи теряют актуальность, а при откате к ранее утвержденной версии все подписи снова становятся действительными.

                                                                Рис.20
         Система PDM STEP Suite реализована на основе технологии "клиент - сервер" и имеет трехуровневую архитектуру, что обеспечивает эффективное распределение вычислительной нагрузки при одновременной работе большого числа пользователей.

В отличие от большинства других систем, уровень доступа определяется не для класса (типа) информационных объектов, а для конкретного информационного объекта, что обеспечивает большую гибкость при организации параллельного проектирования
        В системе имеется встроенный двухуровневый программный интерфейс удаленного доступа, низший уровень которого соответствует спецификации международного стандарта ISO 10303-22 Standard Data Access Interface - SDAI), а высший включает в себя набор высокоуровневых функций доступа к данным из разрабатываемых приложений.
         Система PDM STEP Suite может хранить данные необходимые для подготовки электронных публикаций (интерактивных электронных технических руководств на изделие) и взаимодействовать с системой автоматизированной подготовки электронных руководств. В этом случае обеспечивается централизованное управление всеми данными проекта.
       Пользователи системы
        Сотрудники предприятия - конструкторы и технологи, сотрудники отделов материально технического снабжения, сотрудники отделов сопровождения и поддержки.
Системы автоматизации:
-     системы автоматизированного проектирования, производства и документооборота CAD/CAM/CAE/PDM-системы (UG, PRO/Engineer, SolidWorks и др.);
-     автоматизированные системы управления производством МRP/ERP-системы;
-     специализированные прикладные системы.
5. ИНТЕРАКТИВНЫЕ ЭЛЕКТРОННЫЕ ТЕХНИЧЕСКИЕ
РУКОВОДСТВА

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

- затраты труда на их создание и хранение оказываются напрасными;
- появление новых сложных изделий требует повышения квалификации обслуживающего и ремонтного персонала и необходимости его быстрого переучивания;
- потребителей необходимо снабжать новыми материалами по эксплуатации и техническому обслуживанию новых модификаций изделий;
- применение внутри сложных изделий средств диагностики и контроля, требует использования сервисными службами специальных систем обработки выдаваемой диагностикой информации;
- бумажное документирование процессов эксплуатации не отвечает требованиям времени и уменьшают привлекательность и конкурентоспособность изделия.
         В рамках концепции CALS информационная поддержка процессов эксплуатации обеспечивается путем использования интерактивных электронных технических руководств (ИЭТР), содержащих информацию, связанную с эксплуатацией изделия (эксплуатационную модель изделия) и способных через компьютерные сети получать дополнительную информацию из других источников, например хранилищ конструкторской информации об изделии. ИЭТР включает техническое описание изделия и его узлов, технологию эксплуатации, обслуживания и ремонта, сведения о диагностике неисправностей.
         ИЭТР отличается от простого документа в электронном виде:
- ИТЭР – компонент интегрированной модели продукта, то есть представляет собой либо средство просмотра эксплутационной модели изделия через Интернет при помощи комплекса программных средств - «электронная система отображения» (ЭСО), либо копию фрагмента модели на мобильном носителе (CD-ROM);
- формат представления информации регламентирован международными стандартами SGML, STEP;
- формат представления структуры документа определяется ГОСТом на эксплуатационную документацию;
- формат отображения и интерактивного взаимодействия регламентирован стандартом MIL-M-87268.
5.2. Язык разметки   SGML
         Основную роль в ИЭТР играет SGML – язык разметки текстовой информации. Далее наглядно показано его применение.

         Как уже сказано ранее SGML- документ состоит из трех частей:
- DTD ( Document Type Definition) - набор правил, регламентирующих структуру документа;
- Document Instance - сами размеченные данные;
- Style sheet - таблица стилей.
        Правила построения структуры документа (DTD-Document Type Definition)
         DTD содержит правила, по которым строится логическая структура документа. Аналогичным понятием по отношению к описанию структуры документа является понятие логической структуры базы данных, описывающей типы данных и их взаимосвязь. Описываемые в DTD элементы можно разбить на две группы – элементы первой группы предназначены для разбиения документа на смысловые модули, вторая группа элементов указывает программе-обработчику на необходимость специальной обработки некоторых частей данных. Первую группу элементов назовем ассоциативным видовым уровнем, вторую группу – родовым уровнем
элементов SGML.
         В приведенной схеме (рис.21) элементы: техническое описание, заголовок, версия изделия, система, информация о неисправностях, диагностика неисправностей, информация о детали, очевидно, являются элементами ассоциативного
видового уровня, так как группируют данные
(текст, картинки, видео) по смыслу и не несут кроме этого никакой другой информации. Элементы: текст, аудио, видео, изображение, таблица, столбец таблицы, напротив, не несут в себе никакой смысловой информации о содержании, а лишь являются указаниями для программы-обработчика, о том, что необходимо сгруппировать столбцы в таблицу, проиграть видео запись и т.п., то есть эти элементы принадлежат к родовому уровню.

Рис. 21. Схема документа
 Перечень и взаимосвязи элементов ассоциативного видового уровня сильно зависят от специфики изделий, на которые производится техническое руководство (электроника, машиностроение, химическое производство и т.д.). Поэтому в каждой отрасли промышленности (или на отдельном предприятии) разрабатывается свой набор элементов видового уровня, а соответственно свой набор правил построения структуры документа, так называемые «видовые» DTD.

По сути, такие DTD являются предметом отраслевого (или корпоративного) стандарта на эксплуатационную документацию в электронном виде.
 Элементы родового уровня напротив, не зависят от специфики изделий (таблица является таблицей и в электронике, и в машиностроении).

Размеченный документ SGML
 Размеченный документ SGML представляет собой текстовый файл, либо совокупность текстовых файлов, размеченных в соответствии с некоторым DTD.
Любой размеченный документ SGML должен начинаться с объявления типа документа:
 <!DOCTYPE poem SYSTEM “defs.dtd”>
где после ключевого слова DOCTYPE указывается корневой элемент документа, затем (в большинстве случаев) ставится ключевое слово SYSTEM и указывается имя файла, в котором находится DTD. После такого объявления может идти непосредственно размеченный текст:

Таблица стилей
Третьей частью документа SGML является таблица стилей, определяющая способ отображения на дисплее тех или иных элементов, определенных в DTD. К сожалению, в данной области пока нет единства решений. В различных отраслях используются различные методики описания стилей элементов. Реально в мире используются три конкурирующие спецификации, регламентирующие синтаксис и семантику языка описания стилей:
- MIL28001 FOSI- (Formatted Output Specification Instance) – стандарт американского военного ведомства, используемый в интерактивных руководствах подрядчиков министерства обороны США;
- ISO DSSSL – (Dynamic Style, Semantic and Specification Language)- стандарт ISO, который, однако, не получил пока поддержки у производителей ПО;
- W3C CSS – (Cascading Style Sheets) – рекомендация WWW консорциума. Это популярный стандарт, используемый при разработке Web-страниц. Он широко поддерживается производителями.

5.3.Технология подготовки ИЭТР
Технология подготовки ИЭТР включает в себя (см. рис.15): создание структуры документа на основе правил, содержащихся в DTD, и структуры изделия; автоматическое наполнение созданной структуры документа данными из хранилища конструкторской информации с использованием PDM системы.

Рис.15. Технология подготовки ИЭТР
Сопряжение с хранилищем может быть реализовано с помощью текстового обменного файла, соответствующего требованиям стандарта ISO 10303-21. Основой любых руководств являются технические данные об изделии: его структура, состав, описание и характеристики. Эта информация порождается и используется на протяжении всего цикла разработки изделия. Поэтому основной принцип разработки ИЭТР – интеграция конструкторских данных об изделии с исходными данными для подготовки ИЭТР в единой информационной системе и осуществление разработки ИЭТР параллельно с разработкой изделия. Данный принцип позволяет избежать затрат на повторный ввод информации, облегчает коррекцию технических руководств вследствие изменения конфигурации изделия и снижает вероятность внесения некорректных данных в ИЭТР.
Важную роль в интеграции данных об изделии и данных технического руководства играет использование стандарта STEP для хранения и передачи конструкторской информации. Конструкторские данные, переданные системе подготовки ИЭТР в этом протоколе, позволяют спроектировать структуру сопроводительной документации в соответствии со структурой изделия, передать характеристики изделия, документы, ассоциированные с узлами изделия (см. рис.22).

Рис.22. Интеграция данных об изделии

Пример подготовки ИЭТР

1.Разработка DTD.

Определяется структура документа в виде фрагмента программы

<!ENTITY % nodeattrs "
idID #IMPLIED

name CDATA #IMPLIED

type CDATA #IMPLIED

ref IDREF #CONREF

itemid CDATA #IMPLIED

config CDATA #IMPLIED
">

<!ENTITY % docattrs "

docview (chapter,section,navigator,none) navigator

bookmark (yes,no) no

">
<!ELEMENT manual - - ((para | paraalts)?,techdesc,guide+,faults+)>
руководство включает в себя параграф, альтернативный параграф, знак “?” –
означает, что элемент (параграф или альтернативный параграф) необязательны. Документ обязательно включает одно техническое описание, одну или более инструкцию по эксплуатации, один или более раздел по устранению неисправности.

<

2.Разработка таблицы стилей.
Определяется разметка текста, цветовая палитра, способ отображения на дисплее и др.

PARA {

display : block;

font : normal normal 12pt Arial;

text-indent : 0px;

text-decoration : none;

text-align : left;

border-style : none;

color : black;

background-color : white;

border-color : white;

margin : 0px 0px 0px 0px;

padding : 0px 19px 200px 19px;

border-width : 0px 0px 0px 0px;

}

TEXT {

display : block;

border-style : none;

border-colo : white;

margin : 1px 1px 19px 1px;

padding : 1px 1px 1px 1px;

border-width : 0px 0px 0px 0px;

}

3.Разработка структуры документа на основе правил, регламентированных в DTD.

Рис.23. Структура документа
5.Создание документа (наполнение данными).
Принцип формирования страницы документа - композиция из совокупности элементов: текст, изображение, таблица и т.д. (рис.24)

Рис.24. Создание документа
6. Просмотр документа в системе отображения.

Рис.25. Просмотр документа
 В общем случае ИЭТР может использоваться для решения следующих задач:
- обучения персонала;
- поддержки процессов эксплуатации и выполнения регламентных работ;
- подготовки к проведению регламентных и ремонтных работ;
- диагностики оборудования и поиска неисправностей;
- автоматизированного заказа материалов и запасных частей;
- планирования и учета проведения регламентных и ремонтных работ;
- обмена данными между производителем и потребителем изделий.

6. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ В CALS-СИСТЕМАХ
6.1. Основные понятия и определения

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

Тем не менее, в отличие от защиты информации в отдельной организации, защита информации в виртуальном предприятии имеет свою специфику. В качестве главных особенностей можно указать:
- географически распределенная структура;
- разнородность используемых программно-технических решений;
- необходимость защиты информации и интеллектуальной собственности, принадлежащей нескольким владельцам.
 Под информационной безопасностью
виртуального предприятия (далее предприятия) понимается состояние защищенности его интересов от существующих и вероятных внешних и внутренних угроз информационным ресурсам.
Информационными ресурсами являются:
- технические средства автоматизации (компьютерная техника и средства связи);
- электронные носители всех видов;
- информация в виде файлов и баз данных на электронных носителях;
- хранилища машиночитаемых и бумажных носителей (архивы и библиотеки);
- знания персонала.
 Цель мер по обеспечению информационной безопасности - сократить возможный экономический и моральный ущерб предприятия, связанный с повреждением или неправомерным использованием информационных ресурсов.
 Обеспечение информационной безопасности (ИБ) представляет собой сложный комплекс технических, юридических и организационных проблем.
 Основой для системного решения задач обеспечения ИБ являются: анализ возможных рисков, политика информационной безопасности (ИБ) и план обеспечения ИБ.
 Анализ рисков - первый и необходимый этап в решении задачи ЗИ и проводится с целью выявления перечня потенциально возможных угроз интересам предприятия, событий и возможного ущерба, которые могут возникнуть в результате реализации таких рисков.
 На основе результатов анализа рисков разрабатывается политика безопасности
– документ, содержащий принципы деятельности предприятия в отношении проблем ИБ. Политика безопасности содержит ранжированный перечень угроз, принимаемых во внимание, классификацию защищаемых информационных ресурсов, определяет желаемый уровень защищенности, описывает организационные решения, необходимые для решения задач ИБ.

 На основе утвержденной политики безопасности разрабатывается план обеспечения информационной безопасности, содержащий конкретные организационно-технические решения и планы работ по их внедрению и реализации.
 Задачами обеспечения информационной безопасности (ИБ) и соответственно функциями системы обеспечения информационной безопасности (СОИБ) являются:
- пресечение и выявление попыток уничтожения или подмены (фальсификации) информации;
- пресечение и выявление попыток несанкционированной модификации
информации;
- пресечение и выявление попыток несанкционированного получения
информации ;
- ликвидация последствий успешной реализации перечисленных угроз;
- выявление и нейтрализация проявившихся и потенциально возможных дестабилизирующих факторов и каналов утечки информации;
- выявление и нейтрализация причин проявления дестабилизирующих факторов и возникновения каналов утечки информации;
- определение лиц, виновных в проявлении дестабилизирующих факторов и возникновении каналов утечки информации, и привлечение их к определенного вида ответственности.

6.2. Технологии построения защищенной сети виртуального предприятия

 Основой единого информационного пространства (ЕИП) виртуального предприятия является совокупность сетей входящих в него организаций и открытых сетей - Интернет. Соответственно, необходимо обеспечить:
- защиту сетей внутри организаций;
- управление доступом во внутренние сети организаций из открытых сетей;
- управление доступом из внутренних сетей в открытые сети;
- обеспечить безопасный обмен данными между внутренними сетями организаций через открытые сети.
 Для защиты от несанкционированного доступа (НСД) к данным в рамках локальной сети организации и отдельных компьютерах применяются специальные программно-технические средства, обеспечивающие управление доступом к данным на основе имеющихся у пользователей полномочий.
 Базовый набор функций комплекса средств защиты от НСД включает в себя:

- идентификацию и аутентификацию ( проверку принадлежности субъекту доступа предъявленного идентификатора) пользователя в начале сеанса работы;
- обеспечение доступа к данным и возможности запуска программ в соответствии с заданным списком полномочий и разрешений;
- контроль целостности используемого программного обеспечения и данных;
- протоколирование выполняемых действий.
 Часть упомянутых функций выполняют некоторые современные операционные системы компьютеров, например Microsoft Windows/NT, но эти функции могут отсутствовать, в этом случае должны обеспечиваться дополнительными средствами.
 Идентификация и аутентификация пользователей может выполняться путем ввода имени и пароля, использования смарт-карт (интеллектуальных пластиковых карт) и средств считывания данных с карт, подключаемых к компьютеру, специальных жетонов, хранящих уникальный код и т.д. В особо ответственных приложениях применяются средства идентификации, основанные на распознавании физических характеристик субъекта доступа (голоса, отпечаток пальца, радужной оболочки глаза и др.).
 Основной проблемой обеспечения эффективной работы средств защиты от НСД является создание правильных и полных описаний полномочий пользователей, необходимых для выполнения служебных обязанностей.
 В процессе работы сотрудники организации выполняют различные функции, каждая из которых требует доступа к разным наборам данных и программ. Требуется трудоемкий и кропотливый анализ всех выполняемых сотрудниками функций для того, чтобы определить их полномочия и правильно отрегулировать средства доступа к данным. При этом следует принимать во внимание, что любая организация подвержена изменениям и функции сотрудников нередко меняются и перераспределяются, что требует повторной перенастройки средств защиты.
 Наиболее радикальным подходом является использование (в качестве инструмента управления полномочиями сотрудников) моделей бизнес-процессов, выполняемых в организации. Функциональная модель бизнес-процессов является обозримым, программно-поддерживаемым описанием, содержащим, в частности, сведения обо всех информационных объектах к которым сотрудник должен иметь доступ в процессе работы.

Отбирая полученные данные в подмножества, связанные с должностными обязанностями конкретных лиц или рабочими местами, можно автоматически подготовить конфигурационные файлы для настройки средств защиты от НСД, установленных на рабочих местах. В этом смысле модель является основой для автоматизации настройки средств безопасности. Происходящие в организации изменения вводятся в модель и, соответственно, отображаются в настройке средств безопасности. Например, для того, чтобы на время отпуска заменить одного сотрудника другим, необходимо в описании операции поменять идентификатор сотрудника, при этом полномочия отсутствующего сотрудника будут автоматически переданы работающему.
 Защита от НСД во внутреннюю сеть организации из открытой сети представляет собой отдельную задачу, для решения которой применяются межсетевые экраны (firewall). По сути, это устройство (или группа устройств), расположенное между внутренней (защищаемой) сетью и Интернет и выполняющее задачи по ограничению проходящего через него трафика, регистрации информации о трафике, пресечению попыток несанкционированного доступа при попытке подключиться к ресурсам внутренней сети и т.д. При этом данное устройство обеспечивает «прозрачный» доступ пользователей внутренней сети к службам Интернет и доступ извне (то есть из сети Интернет) к ресурсам ИС предприятия для зарегистрированных во внутренней сети пользователей.
 Особо необходимо рассмотреть вопросы обеспечения антивирусной безопасности (АВБ) компьютерной системы предприятия. Возможность вирусного заражения является одной из серьезных угроз, которой могут подвергнуться программы и данные пользователей.
 Типичными путями попадания вирусов в компьютерную сеть являются:
- электронные носители информации (флоппи и компакт диски, накопители типа Zip и т.д.);
- бесплатное программное обеспечение, полученное через Web или FTP и сохраненное на локальной рабочей станции;
- удаленные пользователи, которые соединяются с сетью через модем и получают доступ к файлам сервера;

- электронная почта, содержащая в сообщениях присоединенные файлы документов (Word ) или электронных таблиц (Excel) , которые могут содержать в себе макровирусы.
 Таким образом, для того, чтобы защитить корпоративную сеть от проникновения вирусов или разрушительных программ, необходимо следить за возможными точками проникновения вирусов, к которым относятся: шлюзы Интернет, файловые серверы, серверы средств групповой работы и электронной почты, рабочие станции пользователей.
 Следует отметить, что решение проблемы АВБ не сводится к установке антивирусных программ на каждый компьютер. Средства АВБ нуждаются в правильной настройке и регулярном обновлении таблиц вирусных сигнатур. Поскольку корпоративная компьютерная сеть может иметь очень сложную структуру, стоимость обслуживания сети и поддержки средств АВБ катастрофически растет вместе с ростом числа подключенных рабочих станций. Одним из основных путей снижения затрат является применение средств централизованного управления средствами АВБ. Средства централизованного управления позволяют администратору безопасности со своего рабочего места контролировать все возможные точки проникновения вирусов и управлять всеми средствами АВБ, перекрывающими эти точки.
 Для того, чтобы эффективно защищать корпоративную сеть, средства АВБ должны удовлетворять целому ряду требований:
- способность обнаруживать большинство известных и неизвестных вирусов, а также разрушительных программ;
- способность производителя средств АВБ быстро выпускать новые модификации при появлении новых вирусов;
- качественная и квалифицированная поддержка;
- функциональная полнота, способность контролировать все точки потенциального проникновения в сеть;
- удобные средства управления;
- наличие средств оповещения о попытках вирусного заражения;
- высокая производительность.
6.3. Нормативно-правовое обеспечение информационной безопасности

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

 7. ВОПРОСЫ ВНЕДРЕНИЯ CALS-ТЕХНОЛОГИЙ

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

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

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

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

 1. Сокращение продолжительности производственного цикла.
 Выпуск продукта на рынок раньше конкурентов позволит предприятию закрепить за собой большую часть рынка и обеспечить более высокую прибыль в течение некоторого периода времени, пока конкуренты не воспроизведут продукт. Сокращение длительности цикла разработки продукта может дать возможность выпустить большее количество версий продукта при тех же затратах ресурсов на разработку. То же можно сказать в случае, если организация занимается проектами. Сокращение длительности цикла может оказаться жизненно важным для снижения затрат за счет сокращения непредвиденных расходов.
 2. Сокращение затрат.
 Процессы проектирования и производства продукта обычно осуществляются с многочисленными итерациями, которые поглощают ресурсы, вызывают необходимость переделок, появление брака и приводят к росту затрат. Предоставление правильной информации в нужное время и в нужной форме с помощью методов CALS может резко сократить затраты и объемы ненужных переделок.
 3. Повышение качества
 Выпуск продукции в более короткие сроки или с меньшими производственными затратами является выгодным в том случае, если продукция имеет соответствующее качество. «Правильно с первого раза» является идеалом и уверенность в том, что получаемая информация - полная и непротиворечивая , способствует выпуску продукции «с первого раза ».
 Помимо указанных выше материальных факторов, стоит принять во внимание и ряд неосязаемых преимуществ, таких как удовлетворенность клиентов, более высокий уровень услуг и обслуживания, выгоды, связанные с наличием корпоративного хранилища данных о продукте . Примером такого неосязаемого преимущества является, например , уверенность в том , что информация о продукте или о разработке не просто находится в головах нескольких работников, а зафиксирована в базах данных компании и доступна для всех. В длительной перспективе такое положение даст конкурентный перевес.
 При оценке преимуществ от внедрения проекта необходимо рассмотреть ситуацию в разрезе всего предприятия и согласиться на некоторые затраты труда и времени.

Потребуются, например, дополнительные затраты времени и ресурсов на стадии проектирования, чтобы подготовить электронное описание продукта. Однако более качественная исходная информация обеспечит экономию на стадиях производства продукции, которая значительно перевесит произведенные все затраты.
 Планирование и внедрение CALS-проекта.
 Для планирования, управления и реализации проекта необходимо создать специальную группу. Численность группы и требования к ее членам определяются размером компании и масштабом предполагаемого внедрения. Ключом к успешному внедрению является тщательное планирование. Оно одинаково важно и в сравнительно скромной компании, намеренной произвести частичные изменения, и в крупной организации, реализующей полномасштабное внедрение CALS. План является критически важным связующим звеном между стратегической концепцией реформирования и тактическими действиями по их внедрению.
 Для проведения работ по внедрению решений CALS необходимо подготовить план управления работами по проекту, нацеленный на внедрение инноваций в заданное время и при установленных затратах. В нем должны отражаться организация проекта, индивидуальные функции и ответственность участников работ, а также процессы, связанные с уточнением проектных требований и планов, с контролем за ходом работ, порядком внесения изменений в планы и графики работ по проекту. Опыт внедрения CALS-технологий показывает, что план должен быть поэтапным, изменения должны вноситься порциями. Следует избегать «шапкозакидательства». В плане необходимо выделить приоритетные задачи, которые могут дать быструю и очевидную отдачу в бизнесе при минимальных затратах, например, проведение относительно простой модификации процессов, внедрение своего рода показательных систем . План не должен быть статическим – его следует своевременно корректировать, инициативно управлять им, периодически «обновлять» по мере того, как выполняются его пункты и при возникновении проблем. План может корректироваться по мере накопления опыта и с учетом обратной связи по результатам внедрения.

Следует быть прагматичными и соразмерять темп работ с темпом разработки стандартов, технологии и прочих обстоятельств, связанных с конкретным бизнесом, цепочкой логистики, снабжения и обеспечения.
 Цели и задачи, поставленные в проекте внедрения CALS, должны быть ясными и понятными, конкретными, поддаваться измерению, достижимыми, радикальными, экономически обоснованными, расписанными по времени.
 Для успешной реализации проекта важно создать условия, при которых инициатива по внедрению системы исходила бы от верхнего уровня руководства головных подразделений организации. Высшее руководство должно понимать, поддерживать и, если нужно, изменять деловую стратегию, принятую концепцию внедрения CALS и ключевые элементы плана. Должен быть предусмотрен контролируемый процесс достижения явно видимых преимуществ и результатов. Ответственность за достижение преимуществ и результатов должна быть подробно расписана, т.е. должен быть назначен ответственный за каждый результат (например, директор по производству принимает на себя обязательство по результатам внедрения CALS добиться 25%-ного снижения затрат рабочего времени проектантами и т .д.).

7.3. Реформирование процессов
 Рано или поздно любая организация начинает чувствовать потребность в совершенствовании организационных и технологических процессов, происходящих внутри компании, и задумываться о выборе методологии и инструментов для решения этой задачи. В мире эта область активно развивается и именуется технологиями анализа и реинжиниринга бизнес – процессов (технологических, организационно - деловых, управленческих).
 Анализ и реинжиниринг бизнес - процессов, как правило, включает в себя следующие этапы:
- определение потребностей бизнеса;
- анализ существующих процессов;
- определение необходимых реформ;
- планирование проведения реформ;
- реализацию намеченных планов.
 Определение потребностей бизнеса.
 Технологии анализа и реинжиниринга бизнес-процессов являются средством, которое дает возможность реформировать и усовершенствовать процессы деятельности предприятия.

К таким процессам относятся проектно- конструкторские разработки, процессы снабжения и материально- технического обеспечения, технологические и производственные процессы, процесс сопровождения продукта после его продажи. Любое мероприятие, связанное с внедрением CALS, должно быть обусловлено реальными потребностями предприятия. Это могут быть внутренние потребности, возникшие в ходе реализации общей стратегической задачи по повышению конкурентоспособности бизнеса, либо внешние потребности, возникшие в ответ на требования важного заказчика. В обоих случаях присутствует наличие желания упростить и оптимизировать процессы.
 В зависимости от потребностей предприятия в оптимизации бизнес-процессов стратегия проведения работ может быть следующей:
- автоматизация существующих процессов;
- замена существующих процессов;
- адаптация существующих процессов к особенностям новых систем, новым возможностям, новой инфраструктуре бизнеса;
- отдельные улучшения.
 Анализ существующих процессов
Для того, чтобы оценить, как из указанных выше стратегий является наилучшей, необходимо четко разобраться в материальных и информационных потоках предприятия. Если проводимые реформы продиктованы отношениями с клиентами, то следует сфокусировать все внимание на вопросах обеспечения и поддержки клиента. Вместе с тем можно воспользоваться появившейся возможностью и расширить область реформирования на другие процессы внутри организации. Если организация широко сотрудничает с другими предприятиями и располагает средствами взаимодействия со многими заказчиками и поставщиками , то в число рассматриваемых процессов стоит включить процессы взаимодействия с заказчиками, партнерами и поставщиками . Если основным стимулом реорганизации является желание внедрить методы «наилучшей современной практики», то необходимо провести широкомасштабное совершенствование бизнес - предприятия.
 Для наглядного представления структуры бизнес - процессов, их взаимодействия используется функциональная модель в виде, регламентированном стандартом IDEF0. Визуально модель выглядит как система иерархических и взаимосвязанных диаграмм, но, по сути, представляет собой базу данных.

Важнейшей особенностью метода является то, что описание строится вокруг процессов, а не вокруг оргструктуры. Из описания процесса видно, кто в него вовлечен, то есть какие элементы оргструктуры задействованы, виден перечень работ, фактически выполняемых подразделением.
 Чтобы вскрыть все проблемы, полезно рассмотреть основные процессы (как создание нового бизнеса, разработка нового продукта, поддержка и обеспечение заказчика) как с точки зрения руководства, то есть «сверху вниз», так и с точки зрения исполнителей работ. Рабочие семинары по отображению и документированию конкретных существующих процессов с точки зрения высшего руководства и конкретных исполнителей работ могут очень быстро указать на расхождения в понимании процесса. При этом выявляются присущие процессу проблемы информационного и коммуникационного характера и реальные возможности рационализации процесса.
 Документирование существующего процесса совместно с заказчиками, партнерами показывает, что реально происходит при обмене информацией или продуктами.
 Установив, что и как происходит в существующих процессах, следует перейти к поиску путей совершенствования процессов, экономии времени, усилий и ресурсов.
 Сущность анализа процессов заключается в изучении их характеристик и составных частей, таких как:
- число и характер взаимосвязей между составными частями процессов;
- затраты и их распределение внутри бизнес - процессов;
- потенциал используемых ресурсов (персонала, оборудования, инфраструктуры);
- фактическая загрузка используемых ресурсов.
 Таким образом, выявляется фактическая картина состояния «как есть», что уже само по себе является чрезвычайно важным результатом, необходимым для принятия управленческих решений.
 Анализ и моделирование бизнес-процессов являются серьезным инструментом повышения эффективности работы предприятия, так как:
- представление о работе предприятия как о выполнении совокупности бизнес - процессов позволяет руководителю по-новому взглянуть на процесс функционирования подчиненной ему структуры, а рядовым сотрудникам осознать свое место и обязанности в ней;

- модель бизнес - процессов предприятия служит источником объективной информации о выполняемых функциях и связях между ними;
- использование количественных характеристик (затрат на выполнение функции, производительности функции и механизма, мощности функции и механизма, коэффициентов загрузки) позволяет оценить оптимальность организации бизнес – процессов и их составляющих, определить источники потерь, контролировать целенаправленно вносимые в систему изменения, обеспечивать оптимальную работу предприятия и взаимодействие его работников при решении различных задач.
 Определение необходимых реформ.
 На основе сложившегося понимания действующих процессов можно приступить к оценке возможных направлений реформ и определить, какие из существующих процессов нужно упростить, отладить или модифицировать. Обычно на этом этапе выявляется целый ряд возможных действий, и следует решить, какое из них больше всего подходит в конкретном случае.
 Логическая последовательность действий по реформированию процессов должна начинаться с анализа возможности упрощения процесса и сокращения количества операций в нем за счет исключения операций, не приносящих прибавочной стоимости. Уменьшение количества операций может повысить эффективность, производительность, снизить производственные издержки. При рассмотрении возможных усовершенствований процессов особое внимание следует уделить поддержке и обеспечению более тесного информационного взаимодействия всех субъектов, задействованных в проектно – конструкторских работах, в производстве и других этапах жизненного цикла продукта.
 Основная мысль – не следует применять информационные технологии для автоматизации существующих сложных процессов. Упрощенные процессы можно перенести в более простую архитектуру и быстро внедрить «стандартные» прикладные программные средства. Вместе с тем применение технологии к существующим сложным процессам может привести к применению сложных архитектурных систем, высоким затратам, к растянутому во времени или бесконечному внедрению.

 Результатами анализа и реинжиниринга бизнес - процессов являются:
- совершенствование организационной структуры;
- совершенствование бизнес - процессов;
- построение оптимальной модели информационных потоков, необходимой для настройки интегрированной системы управления.
 Планирование проведения реформ.
 По завершении описанных выше работ необходимо задокументировать согласованные изменения в процессах и средства реализации таких изменений. Ожидаемый конечный результат документируется в форме модели процесса, часто определяемой как «должно быть». Очень важно, чтобы процессы реформирования и внесения изменений были ранжированы по приоритетам. Необходимо определить приоритеты, последовательность работ по усовершенствованию процессов с учетом потребностей бизнеса, а также подготовить план взаимосвязанных действий и мероприятий. Первые мероприятия такого плана должны быть посвящены действиям, связанным с подготовкой к началу работ. По некоторым процессам невозможно заранее предусмотреть все детали окончательного или предпочтительного решения. В таких случаях целесообразно предусмотреть выполнение пилотного проекта, в других же случаях, когда степень риска или неуверенности может быть меньше, достаточно лишь предусмотреть в графике реализации проекта этап апробирования.
 Все новые процессы должны быть подробным образом задокументированы, поэтому любой план должен содержать работы по разработке и аудиту документации с тем, чтобы обеспечить соблюдение требований контроля качества или сертификации, например, по стандарту ISO 9000. Документирование бизнес - процессов позволяет решить задачу разработки и сертификации системы обеспечения качества продукции. Сама по себе система качества – это совокупность организационной структуры, ответственности, методик, процессов и ресурсов, необходимых для осуществления общего руководства качеством, которая охватывает все планируемые и систематически осуществляемые виды деятельности.

 Формально или, как говорят сами специалисты по ISO 9000, в узком смысле, это обязывает предприятие задокументировать аспекты производственной деятельности (или же деятельности , связанной с оказанием услуг), а также обеспечить реальное функционирование соответствующих бизнес - процессов в организации. Разработанные функциональные модели содержат все типовые элементы системы качества в соответствии со стандартами серии ISO 9000: выполняемые функции, персонал, документацию, полномочия и обязанности.
7.4. Кадровые и организационные изменения
 Кадровые и организационные вопросы представляют наибольшую трудность в любой программе реформ. Совершенствование процессов и технологии должно сочетаться с разумной организацией и эффективным использованием людских ресурсов. Общей чертой успешно работающих организаций является то, что специалисты там работают эффективно (правильно) и производительно (хорошо).
 Анализ существующей организации должен выявить навыки и умения, которые после реорганизации окажутся ключевыми, и персонал, который этими навыками обладает. Для этого следует задаться такими вопросами, как: «Каким образом предприятие собирается выделиться на рынке? Какими профессиональными навыками и умениями должен обладать персонал, чтобы обеспечить выделение предприятия на рынке? Какие виды деятельности будут осуществляться на предприятии при взаимодействии с заказчиками и партнерами и какие специалисты смогут их выполнять?»
 При анализе существующей организации жизненно важный шаг – это определить, какие из нынешних навыков и умений являются сейчас ключевыми, кто ими владеет, как они связаны с ключевыми аспектами бизнеса, какие профессиональные навыки и умения следует развить и взрастить, к каким новым видам деятельности Вы обратитесь, работая с партнером, субподрядчиком или заказчиком, какие новые профессиональные навыки и умения понадобятся для реализации таких новых деловых отношений?
 Внедрение СALS обеспечивает тесное взаимодействие между всеми коллективами и командами, связанными с проектированием, производством и сопровождением продукта в течение жизненного цикла в рамках всего виртуального предприятия.

Чтобы добиться успеха, необходимо установить роль, ответственность и понять заинтересованность всех организаций, входящих в виртуальное предприятие.
 Методы параллельной работы основаны на коллективной работе и быстром обмене результатами работ. Нужен определенный сдвиг в сознании людей, и бывает, что убедить скептиков в эффективности системы удается лишь тогда, когда они сами ощутят ее достоинства на практике. Необходимо понять, что изменение культуры мышления может оказаться наиболее трудным и болезненным вопросом, требующим на решение много времени.
 Определение внутренних потребностей организации.
 Одновременно с расширением масштаба деятельности необходимо создавать условия для большей интеграции внутри предприятия. Для этого следует проанализировать все аспекты деятельности предприятия на протяжении жизненного цикла продукта, начиная с момента зарождения концепции до послепродажного ведения и поддержки продукции, а иногда и до ее утилизации.
 В организации, в которой выполнение проекта распределено по структурным подразделениям, различные элементы продукта разрабатываются до некоторой степени изолированно. При передаче информации из одной части организации в другую возникает необходимость значительных переделок, и для увязки всех элементов конструкции требуется порой затратить весьма большие усилия. Такая структура организации, называемая дивизионной, обеспечивает управление работой функциональных подразделений и персоналом. Однако она не дает эффективного средства для управления реализацией задачи, ходом работ, бюджетом и сроками.
 По этим причинам многие организации прибегают к использованию многопрофильных коллективов, что позволяет объединить усилия, лучше контролировать выполнение стоящих задач и обеспечивает большую прозрачность хода работ по проекту. В многопрофильные коллективы входят специалисты маркетинга, сбыта, проектанты и конструкторы, производственники, сборщики и монтажники, снабженцы, испытатели, представители службы поддержки и обеспечения, представители основных поставщиков и заказчиков, которые работают в тесном контакте и имеют поддержку и обеспечение со стороны CALS-системы.

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

7.5. Совершенствование информационной инфраструктуры

 Анализ существующих систем и инфраструктуры.
 Менять все ранее используемые на предприятии системы при внедрении CALS было бы непрактично. Концепция CALS вовсе не требует революции – выбросить все системы и начать с пустого места. Основной акцент делается на создание такой информационной структуры, в рамках которой существующие системы объединяются и интегрируются, а там, где это необходимо, дополняются новыми технологиями.
 Первым этапом совершенствования информационной инфраструктуры является инвентаризация всех автоматизированных систем, применяемых для поддержки существующих и обеспечения совершенствуемых процессов. Анализ этих систем должен определить, на каком этапе своего жизненного цикла они находятся в данный момент, какие из этих систем сохранить, а какие заменить или заново разработать.
 Во многих организациях имеются информационные системы для автоматизации отдельных операций и процессов, в результате чего возникли своего рода островки автоматизации. Внедрение CALS дает возможность сократить количественный рост и расползание систем островковой автоматизации и усилить интеграцию между ними путем создания эффективных интерфейсов.
 На этапе анализа следует выяснить текущее состояние систем и инфраструктуры, используемых участниками виртуального предприятия, куда входят заказчики, партнеры, поставщики и прочие участники логистической цепочки, а также учесть будущие планы партнеров и их подходы к стандартизации.
 В большинстве случаев выявляется большой объем данных, сохраняемых на бумажных носителях, микрофишах и т.д., которые хотелось бы перенести и в новую среду. Необходимо весьма тщательно рассмотреть целесообразность такого преобразования. Конечно, какие-то данные должны быть перенесены в новые системы. Но нужно четко определить, какая информация, в каком объеме, в какой форме и каким способом будет переноситься.
 Архитектура информационной системы расширенного предприятия (CALS-системы).

 Владея надежной информацией об используемых на предприятии автоматизированных системах, объеме необходимых для общего использования данных, располагая знаниями о ключевых системах партнеров, заказчиков и поставщиков, можно приступать к проектированию будущей архитектуры расширенного предприятия.
 Проектирование архитектуры включает в себя выбор аппаратных средств, сетевой инфраструктуры и программного обеспечения, необходимого для поддержки усовершенствованных процессов и нового стиля работы.
 Критерии проектирования.
 Требования, предъявляемые к системам автоматизации, хранения и управления данными, должны вырабатываться в тесном взаимодействии с заказчиками, партнерами и основными пользователями внутри организации с акцентом на следующие моменты:
- коллективное использование данных. Цель – корпоративные хранилища данных с однократным вводом и многократным использованием данных;
- эффективное управление информацией;
- стандартизация форматов данных и способов доступа к ним.
 Разрабатываемая архитектура должна учитывать быстрое развитие информационных технологий и технологий телекоммуникаций, которые характеризуются высокой степенью изменчивости. Поэтому следует обеспечить максимальную гибкость архитектуры, например, путем применения открытых систем и стандартных промышленных решений и за счет отказа от сильно индивидуализированных специальных решений. Следует помнить и о необходимости регулярного анализа и пересмотра архитектуры, чтобы учесть новые разработки с максимальной эффективностью.
 Прикладное программное обеспечение.
 Одним из жизненно важных компонентов архитектуры является прикладное программное обеспечение. Основные рекомендации по выбору и совершенствованию прикладного программного обеспечения сводятся к следующему:
- использование открытых систем, которые облегчают обмен и совместное использование информации;
- максимально возможный уровень интеграции между системами как внутри организации, так и с внешними участниками.

Степень интеграции и скорость ее осуществления должны определяться стратегией CALS;
- использование коммерческих программных продуктов, позволяющих использовать и предоставлять результаты работ в стандартном виде.
 При разработке архитектуры информационной системы следует рассмотреть все прикладное программное обеспечение, используемое при создании, совместном использовании информации и управлении ею.
 Основные прикладные средства поддержки CALS-технологий включают в себя программные решения для:
- проектно – конструкторских работ – средства автоматизированного проектирования (CAD), визуализации, технологической подготовки производства (CAM), инженерного анализа, моделирования (САЕ), электронного описания (определения) продукта, составления смет финансирования, расходов и т.д.;
- производства – средства для обеспечения функций снабжения, календарного планирования, диспетчеризации, функций планирования производственных ресурсов (MRP/ERP), ЧПУ (CNC), учета хода производства, электронного обмена данными (заказам, расчетам ) и т.д.;
- обслуживания (сопровождения) – средства для систем обслуживания и снабжения запчастями, интерактивные электронные технические руководства (ИЭТР) и справочники, автоматизированное испытательное оборудование, которое может быть связано с ИЭТР, системы интегрированного материально - технического обеспечения и логистики.
- управления данными – средства описания структуры продукта, управления данными о продукте, управления проектом (PDM), технологическими потоками, управления конфигурацией продукта и т.д. В среде CALS-технологий такой инструмент, как управление данными о продукте (PDM), может играть ключевую роль как средство, позволяющее осуществлять создание, доступ, распределение, надежное управление и контроль за едиными обновляемыми хранилищами информации.
 При выборе прикладного программного обеспечения следует учесть требования потенциальных пользователей, сопоставить предлагаемые программные продукты с потребностями предприятия.

Следует отдавать предпочтение открытым системам с функциями поддержки и обеспечения обмена данными в стандартизованном виде.
 Определение и выбор стандартов.
 Основной экономический эффект от внедрения CALS заключается в интеграции и совместном использовании электронной информации, применяемой для проектирования, производства, поддержки и сопровождения продукта.
 Основным строительным блоком при реализации стратегии CALS являются стандарты. Совместное использование данных о продукте в ходе его жизненного цикла возможно на основе стандартизации способа представления данных и технологии их использования. Выбор стандартов является частью корпоративной стратегии внедрения CALS.
Оценив затраты, экономический эффект, риски, связанные с каждым из вариантов, и определив приоритеты, следует провести окончательное уточнение плана внедрения CALS и приступить к внедрению.
 Внедрение.
 Планирование и управление внедрением включает в себя мероприятия по составлению спецификаций, выбору новых систем и технологий, отладку работы существующих систем в новых условиях. В случае серьезных затрат, например при закупке системы управления данными о продукте (PDM) для всей организации, необходимо запланировать пилотные испытания системы и провести совместно с потенциальным поставщиком тщательную и всестороннюю оценку системы до ее приобретения.
 Некоторые рекомендации по внедрению.
 1. Проводите внедрение постепенно, шаг за шагом. Не пытайтесь внедрить слишком много функциональных возможностей за один раз. Множество проектов внедрения информационных технологий провалились именно из-за того, что первоначальный объем внедрения был явно завышен. Помните о том, что значительного экономического эффекта можно добиться при первоочередном внедрении простых, но «привлекательных» функций. Внедрите сначала их, а потом переходите к более продвинутым функциям.
 2. В случаях, когда в информационной системе предусмотрены значительные изменения, следует предусмотреть в плане определенный период параллельной работы со старой системой, прежде чем можно будет полностью переключиться на новую систему.

Запасную поддерживающую систему следует сохранять до тех пор, пока не появится полная уверенность в новой системе.
 3. Тщательно спланируйте перенос информации в новые системы. Определите, какие данные являются наиболее существенными и требуют первоочередного переноса, а с какими можно подождать и перенести их по мере необходимости.
 4. Проследите, чтобы пользователи новых систем прошли необходимую подготовку и чтобы в момент, когда они начнут работать с новой системой, у них имелась бы соответствующая помощь и поддержка.
 5. Прибегайте к пилотным проектам, чтобы в деталях проработать использование новых систем, чтобы набраться практического опыта, нужного для разработки рабочих инструкций, руководств и т.д.

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

 Внедрение методов CALS нацелено на совместное использование информации в электронном виде. Некоторая часть такой информации может попадать под действие нормативных актов РФ о защите информации, поскольку связана с коммерческой и государственной тайнами.
 Вопросы защиты информации в целом изложены в разделе 6. Здесь рассмотрены основные этапы работ на конкретном предприятии по защите информации.
 Тесные связи с внешними участниками, развитие партнерских отношений увеличивают риски нарушения информационной безопасности и требуют активного контроля и гарантии целостности и надежности используемой информации.
 Это требует проведения работ по управлению рисками в области информационной безопасности, а именно:
- определение масштаба защитных мероприятий;
- определение и классификация информации, предоставляемой для совместного использования;
- определение угроз безопасности и требований к безопасности;
- выбор мер защиты информации;
- документирование политики безопасности.
 Поскольку для обеспечения информационной безопасности необходимы определенные затраты, меры защиты должны быть соразмерны уровню существующих рисков. Ниже описаны шаги, которые необходимо предпринять для определения потенциальных рисков, их возможного воздействия на бизнес и выбора мер противодействия, чтобы затем эти меры включить в политику и план обеспечения информационной безопасности.
 Определение рамок системы информационной безопасности.
 Необходимо провести инвентаризацию аппаратных средств, операционных систем, сетей и прикладных программных средств, которые будут использоваться для доступа к информации и задокументировать все это в виде схемы.
 Документирование информационных потоков и оценка чувствительности информации к несанкционированному доступу.
 Определите по всем ключевым бизнес - процессам, какая информация подлежит совместному использованию, с какими информационными потоками она связана.

Проведите классификацию информации по степени ее закрытости. Для информации каждого типа потребуется своя форма защиты целостности, конфиденциальности, доступа. Если ряд организаций пользуется единым виртуальным хранилищем данных о продукте, в котором имеется большой объем коммерческой информации и интеллектуальной собственности, то всегда существует вполне обоснованная озабоченность тем, что именно и в какой мере можно показать различным партнерам и заказчику. Широкий и всеобъемлющий характер такого хранилища данных может сделать доступной конфиденциальную информацию, законного права доступа к которой заказчики, партнеры, поставщики и другие члены организации могут и не иметь. Кроме того, партнер по одному проекту может стать конкурентом в другом проекте. Во избежание каких - либо недоразумений важно точно определить и согласовать, какая информация относится к информации общего пользования, зафиксировать это в ведомости используемых данных и принять меры по защите данных и прикладных программных средств ограниченного доступа. При электронном обмене данными нужно установить, какие наборы данных подлежат обмену, а также те действия, которыми должен сопровождаться каждый случай обмена.
 Определение источников угрозы и требований безопасности.
 Зная о том, какая информация подлежит совместному использованию, определив степень ее конфиденциальности и соответствующие информационные потоки, следует определить вероятные риски в области информационной безопасности. Основную угрозу в среде CALS могут представлять:
- нарушение непрерывности работы системы;
- несанкционированный доступ к системам или данным;
- несанкционированное изменение данных;
- несанкционированное раскрытие данных;
- недостаточность ресурсов системы.
 Кроме того, при электронном обмене данными существует опасность отказа от совершенного действия как со стороны отправителя, так и со стороны получателя.
 Возможность реализации каждой из перечисленных угроз следует сопоставить со стоимостью защиты от нее и, исходя из этого, определить объем мер защиты.

 Выбор мер защиты информации
 Весьма важно обеспечить, чтобы CALS- система была должным образом защищена, и одновременно избежать ненужных расходов на излишние меры безопасности. Задача заключается в том, чтобы выбрать наиболее подходящие меры из широкого набора потенциальных решений, таких как:
- физические методы обеспечения безопасности за счет ограничения доступа персонала в помещения;
- процедурная безопасность, начиная от проверки служащих, имеющих дело с закрытой информацией, до контроля их подготовки к процедурам выполнения работ;
- использование сетевых экранов, способных изолировать сети и хранилища данных компаний от внешних коммуникационных сетей;
- внедрение виртуальных частных сетей (VPN);
- антивирусная защита;
- введение жесткого контроля за всей пересылкой файлов путем назначения лица, выполняющего роль «библиотекаря данных»;
- введение функции «только для чтения» как фактического стандарта на доступ к данным;
- специальная защита коммерческих и других закрытых данных;
- методы аутентификации по установлению правильности и идентификации инициаторов сообщений, включая применение паролей доступа, смарт - карт, криптографии и т.д.;
- должное планирование на случай аварийных ситуаций с хорошо документированными и апробированными процедурами резервирования;
- набор методов для обеспечения целостности сообщений, включая проверку транзакций, подтверждения сообщений, шифрование;
- надежные процессы контроля версий и конфигурации.
 Документирование мер политики безопасности.
 После проведения оценки рисков и принятия решения по типу и объему внедряемых мер безопасности, необходимо утвердить согласованный подход к документу «Политика безопасности». Документ может распространяться на всю организацию, отдельный проект или систему. В развитие политики безопасности должны быть разработаны «Правила информационной безопасности», которые следует довести до всех сотрудников. Всех работников необходимо проинструктировать о согласованных мероприятиях по обеспечению информационной безопасности и их личной ответственности за ее обеспечение.

7.7. Предпосылки внедрения CALS-технологий
 Внедрение CALS – сложный, многогранный процесс, связанный с различными аспектами деятельности организации, поэтому для его осуществления должны существовать определенные предпосылки, а именно наличие:
- нормативно - методической документации разного уровня – федерального, отраслевого, корпоративного, предприятия;
- рынка апробированных и сертифицированных решений и услуг в области CALS-технологий;
- системы подготовки и переподготовки кадров;
- опыта и результатов научно-исследовательских работ ( НИОКР ) и пилотных проектов, направленных на изучение и разработку решений в области CALS-технологий;
- информационных источников (Internet сервер, конференции и т.д.), направленных на информирование научно-технической общественности о существующих решениях и ведущихся работах в области CALS.
 Создание таких предпосылок является важнейшей задачей федеральных органов власти, заинтересованных организаций, научной и инженерной общественности.
 Указанные предпосылки можно отнести к числу «внешних» для предприятия. Наряду с этим для успешного внедрения CALS-технологий должны существовать и «внутренние» предпосылки, о которых уже упоминалось в данном разделе. Это, прежде всего, готовность руководства и персонала предприятия к внедрению CALS-технологий, а также наличие необходимых средств вычислительной техники и сетевого оборудования, программного обеспечения.
8.2. ПРИМЕНЕНИЕ CALS-ТЕХНОЛОГИЙ В ОБЛАСТИ СТАНДАРТИЗАЦИИ
КОМПЛЕКС БАЗОВЫХ ИНФОРМАЦИОННЫХ
МОДЕЛЕЙ СИСТЕМЫ КАЧЕСТВА ПРОДУКЦИИ
 В данном подразделе приведено описание применения CALS- технологий для моделирования системы качества продукции, которая реализована в НИЦ CALS- технологий «Прикладная логистика». На основе CALS- технологий разработан комплекс базовых информационных моделей системы качества продукции предприятия.
 Качество является одной из важнейших характеристик продукта.

В соответствии с определением ISO 8402 «… качество
- совокупность характеристик объекта (продукции, процесса и др.), относящихся к его способности удовлетворить установленные и предполагаемые потребности». Качество продукции обеспечивается путем целенаправленной деятельности, осуществляемой в рамках системы качества и затрагивающей все стадии ЖЦ продукции.
 Система качества (ISO 8402) «.. это совокупность организационной структуры, ответственности, методик, процессов и ресурсов, необходимых для осуществления общего руководства качеством», т.е. аспектов управления, определяющих политику качества, цели, ответственность, а также реализующих управление качеством, планирование, обеспечение и улучшение качества.
 Основой системы качества являются: продуманная идеология, организационная структура, система документов и моделей деятельности всех работающих (от высшего руководства до рабочих). Общая схема системы качества приведена на рис.59.
 Стандарты ISO серии 9000 содержат общие требования к системе качества, которые необходимо реализовать в виде конкретных документированных процедур, выполняемых на предприятии.
 Эта работа может быть систематизирована и частично автоматизирована путем применения функционального, информационного моделирования и проектирования системы качества.
Комплекс базовых информационных моделей системы качества продукции включает в себя набор базовых моделей в формате IDEF/0, описывающих типовые элементы системы качества в соответствии с ISO серии 9000: выполняемые функции, персонал, документацию, полномочия и обязанности (см. рис.60).
В модели учтены основные аспекты обеспечения качества продукции на протяжении жизненного цикла продукта:
- обеспечение качества благодаря определению потребности в продукции, с целью ее соответствия требованиям и возможностям рынка (это процессы маркетинга и изучения рынка);
- обеспечение качества конструкции за счет встраивания в конструкцию свойств, которые влияют на бесперебойность работы изделия в переменных условиях производства и применения;

- обеспечение качества благодаря поддержанию постоянного соответствия конструкции и реализации характеристик, заложенных в проекте (это планирование и разработка процессов, закупки, производство, проверки и все остальное (включая утилизацию несоответствующей продукции) вплоть до ее реализации);
- обеспечение качества благодаря техническому обслуживанию продукции в процессе ее срока службы у потребителя (включая процессы установки, техническая помощь и обслуживание, а также другие аспекты послепродажной деятельности).
Каждый блок на диаграмме понимается как отдельный тщательно определенный объект. Разделение такого объекта на его структурные части (декомпозиция) создает иерархическую совокупность диаграмм со своими четко оговоренными границами. Диаграммы не являются ни блок - схемами, ни просто диаграммами потоков данных. Это предписывающие диаграммы, представляющие входные - выходные преобразования и указывающие правила этих преобразований. Дуги на них изображают интерфейсы между функциями системы, а также между системой и окружающей средой.
На основе базовой функциональной модели системы качества, построенной в среде Design/IDEF, разрабатывается модель системы качества конкретного предприятия, включающая детализированное описание всех элементов системы качества в соответствии с требованиями ISO 9000.

         Применение модели процессов обеспечение качества продукции позволяет:
         1. Разработать и документировать систему обеспечения качества продукции
        Функциональная модель системы качества продукции описывает сеть процессов обеспечения качества продукции и их интерфейсы, связанные с ними обязанности, полномочия, процедуры и ресурсы, распределение обязанностей и полномочий подразделений и персонала предприятия. модель может пониматься как алгоритм создания системы качества конкретного предприятия, содержащий ссылки на все нормативные акты, требования которых должны быть учтены при создании системы качества.

         Функциональная модель системы качества предприятия содержит ответы на следующие
вопросы.
Какая документация должна описывать систему качества организации?
На основании каких требований, указаний и рекомендаций стандартов ISO серии 9000 должна разрабатываться система качества?
Какие элементы обеспечения качества включены в систему качества организации?
Какие процессы влияют на качество продукции и какими процедурами регламентируется их выполнение?
Как обеспечивается выполнение процессов в управляемых условиях?

Рис.60. Набор базовых моделей в формате IDEF/0
         В модели учтено влияние внешней среды:
-    данные о видах деятельности (процессах) организации;
-    требования и возможности рынка;
-     информация о субподрядчиках и их способностях по обеспечению качества;
-     информация о потребителях и их рекламации;
-    информация о продукции конкурентов;
-    информация от органов, осуществляющих надзор.
         Управляющими факторами модели являются требования международных стандартов ИСО серии 9000:
- ИСО 9000 - ИСО 9004;
- ИСО 10001 - 10020
- ИСО 8402.
         Механизмами обеспечения качества являются необходимые ресурсы.
         Модель описывает жизненный цикл документации и данных о качестве на протяжении всех стадий петли качества. Под петлей качества понимается концептуальная модель взаимозависимых видов деятельности, влияющих на качество на различных стадиях от определения потребностей до оценки их удовлетворения.
         2. Провести логический анализ модели обеспечения качества. Подготовить к сертификации систему качества.
         Программно-поддерживаемая электронная модель системы качества позволяет провести логический анализ процессов обеспечения качества продукции - полноту, замкнутость информационных и материальных потоков, полноту описания процессов обеспечения качества и актуальность их применения; анализ документооборота - применяемость, актуальность, информационную достаточность, легальность.

         При решении задачи анализа существующей системы качества разрабатываемая «идеальная» модель сопоставляется с моделью процессов, соответствующей текущему состоянию. На основе выявленных несоответствий формируется план необходимых работ по переходу из текущего состояния к новому.
       Документация системы качества, представленная в форме электронной модели может быть представлена для сертификации, т.е. проверки соответствия системы качества требованиям стандартов ISO серии 9000, поскольку содержит в удобном для анализа виде необходимую информацию о системе качества и может служить инструментом для демонстрации способности управлять качеством продукции.
         3. Создать автоматизированную систему обработки данных о качестве
         На нижнем уровне декомпозиции выявляются все выполняемые элементарные операции, используемые механизмы, данные и условия. В результате работы могут быть сформированы базы данных, содержащие исчерпывающее описание процессов, выполняемых в системе качества. С использованием сформированных баз данных могут быть получены отчеты, содержащие перечень документации системы качества и ее пользователей, перечни функций и работ, выполняемых конкретными сотрудниками или на указанных рабочих местах и др.

Рис.61.Интерфейс программы обеспечения качества
На основе функциональной модели строится информационная модель типа IDEF/1X, содержащая логическую модель базы данных о качестве. Средства моделирования обеспечивают проверку целостности и полноты информационной модели, но и позволяют автоматически сгенерировать текст описания структуры базы данных на языке SQL (Structured Query Language), поддерживаемого большинством современных систем управления базами данных (СУБД). На основе данного описания СУБД автоматически создает необходимые файлы, таблицы и индексы.

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

Современные технологии построения корпоративных сетей предполагают наличие одного или нескольких серверов баз данных и значительное количество рабочих станций персонала. Использование архитектуры клиент-сервер позволяет использовать для хранения данных одну мощную СУБД (типа Oracle, SyBase или им подобных) и клиентское программное обеспечение (ПО) на рабочих станциях (см. рис.62).
Рис.62.
         Преимуществами системы качества, разработанной и документированной с использованием комплекса базовых информационных моделей, являются:
- модель наглядно иллюстрирует функционирование системы качества на предприятии;
- модель может быть использована как справочная информационная система;
- cохраняются и передаются знания;
- модель является основой для дальнейшего совершенствования обеспечения качества;
         Использование комплекса базовых информационных моделей обеспечения качества позволит предприятию сократить сроки разработки системы качества или переработки имеющейся системы КС УКП (приведение ее в соответствие требованиям международных стандартов ИСО серии 9000) за счет следующих факторов.
         Систематизации имеющейся документации (в том числе нормативно – технической) с формированием перечня документов системы качества (вся ли документация действующая и соответствует ли содержание (в том числе по терминологии) требованиям серии ИСО 9000).
         Проверки полноты регламентации (процедур) элементов системы качества и характеристик качества (Наличие в документации заявляемых элементов по ГОСТ Р ИСО 9001 и полнота их описания).
         Анализа документооборота (Применяемость, актуальность, информационная достаточность, легальность).
         Простоты проверки распределения элементов системы качества, полноты описания процедур и ответственности за их выполнение между структурными подразделениями.
         Документированного уточнения организационно – технического взаимодействия.
ЗАКЛЮЧЕНИЕ

         Внедрение CALS – сложный, многогранный процесс, связанный с различными аспектами деятельности организации, поэтому для его осуществления должны существовать определенные предпосылки, а именно наличие:

- нормативной документации разного уровня (федерального, отраслевого, корпоративного, предприятия;
- рынка апробированных и сертифицированных решений и услуг в области CALS;
- системы подготовки и переподготовки кадров;
- опыта и результатов НИОКР и пилотных проектов, направленных на изучение и разработку решений в области CALS-технологий;
- информационных источников (типа Internet), направленных на информирование общественности о существующих решениях и ведущихся работах в области CALS.
Создание таких предпосылок является важнейшей задачей федеральных органов. Реализация CALS предпринимателями и промышленниками позволит: увеличить производительность труда своих сотрудников; сократить временные и общие материальные затраты и обеспечить общее повышение качества. Это достигается путем: упрощения доступа к информации: реорганизации деятельности (без изменения поставленных задач): компьютеризации рабочего окружения; изменения взаимосвязей между предприятиями-партнерами. Например, CALS-ориентированная реорганизация деятельности позволит увеличить производительность труда сотрудников, участвующих в ней; сократить временные затраты; сократить общие материальные затраты за счет повышения показателей качества выполнения следующих операций:
- обработки информации;
- использования информации;
- осуществления консультаций и аналитического обзора результатов работы;
- пересмотра информации;
- добавления новой информации;
- переделки информации;
- просмотра/утверждения информации;
- распространения информации;
- работы над ошибками, анализ причин их возникновения.
         Поэтому любое предприятие - мелкое, среднее или крупное - планирующее освоить производство нового изделия, а также осуществить его эффективную технико-экономическую поддержку, сможет извлечь выгоду, используя такие преимущества CALS-технологий, как одноразовое создание и многоразовое использование общих данных и планирование жизненного цикла продукции.

Эти предпри ятия будут способны: быстрее реагировать на изменение рыночной ситуации (оптимальная реакция на запросы потребителей, сокращение времени на пополнение материальных запасов и снижение их объема); уменьшить свои затраты (устранение трудоемких операций по дублированию данных, значительное сокращение объемов используемой бумаги); повысить качество, особенно надежность своей продукции (уменьшение брака на этапах разработки и производства изделий, улучшение согласованности данных).

СПИСОК   ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.Судов Е.В. CALS-технологии или Информационная поддержка жизненного цикла изделия, PCWeek/RE, № 45(169) (17-23 ноября) 1998 г.
2.Дмитров В.И.
Компьютерная поддержка непрерывных поставок и жизненного цикла продукции — основа обеспечения конкурентоспособности государств в XXI веке. — Вестник машиностроения М., 1996, № 4.
3. Дмитров В.И К вопросу о государственной стратегии России в области CALS-технологий. — Информационные технологии М., 1996, № 5.
4.Дмитров В.И. Опыт внедрения CALS за рубежом - Автоматизация проектирования 1997, №1
5.Дмитров В.И., Макаренков Ю.М. CALS-стандарты - Автоматизация проектирования 1997,№2-4.
6.Дмитров В.И. CALS как основа для проектирования виртуальных предприятий, Автоматизация проектирования 1997, №5
7.Давыдов А.Н., Судов Е.В., Якунина О.В. "Применение расширенной идеологии IDEF для анализа и реинжиниринга бизнес-процессов в производственных и организационных системах" –
Проблемы продвижения продукций и технологий на внешний рынок, специальный выпуск, 1997,с.23-27
8.Барабанов В.В., Ковалева Е.Н., Свирин В.И., Судов Е.Д. "Применение CALS-технологий для создания средств информационной поддержки процессов обеспечения качества продукции" - Проблемы продвижения продукций и технологий на внешний рынок.

Специальный выпуск, 1997,
с.38-40.
9.Шильников П.С., Овсянников М.В. Система электронной документации CALS - реальное воплощение виртуального мира - САПР и Графика, 1997г, №8,.
10.Шильников П.С., Овсянников М.В. Глава семьи информационных CALS-стандартов - ISO 10303 STEP - САПР и Графика, 1997 г.,№11
11Шильников П.С., Овсянников М.В. Как нам реализовать STEP - САПР и Графика, №7, 1998 г.
12.Мыльников В.А. " Системы связи между персональным компьютером и УЧПУ" - САПР и Графика, №7, 1998 г.
13.Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 1996
14.Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение).
М., "Лори", 1996.
15.Марка Д.А., Мак Гоуэн К. Методология структурного анализа и проектирования.
М., "МетаТехнология", 1993.
16. Давыдов А.И., Барабанов В.В. Судов Е.В., Шульга С.С. CALS. Поддержка жизненного цикла продукции. Руководство по применению. М., Минэкономики РФ, НИЦ CALS-технологий “Прикладная логистика”, Всероссийский НИИ межотраслевой информации – информ.-аналитич. Центр оборонной промышленности, 44с.
17. Р 50.1 – 2000 РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ.CALS-ТЕХНОЛОГИИ
ТЕРМИНОЛОГИЧЕСКИЙ СЛОВАРЬ Часть 1. Терминология, относящаяся к стадиям жизненного цикла продукции. Издание официальное ГОССТАНДАРТ РОССИИ   Москва, НИЦ CALS “Прикладная логистика”, 57с.
18. Р 50.1 –2000 РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ.CALS-ТЕХНОЛОГИИ
ТЕРМИНОЛОГИЧЕСКИЙ СЛОВАРЬ Часть 2. Основные термины и определения методологии и функциональных объектов в стандартах серии ISO 10303.Издание официальное
ГОССТАНДАРТ РОССИИ Москва, НИЦ CALS “Прикладная логистика”, 19с.
ПРИЛОЖЕНИЕ 1
ПЕРЕЧЕНЬ СТАНДАРТОВ CALS

Таблица П1.1
СОСТАВ СТАНДАРТА ISO 10303 (STEP)

Descriptions methods	Методы описания

Part 1 (IS): Overview and fundamental principles	Общий обзор и основополагающие принципы
Part 11 (IS): EXPRESS language reference manual	Справочное руководство по языку EXPRESS
Part 12 (IS): The EXPRESS-I language reference manual	Справочное руководство по языку EXPRESS-I

Implementation methods	Стандартные решения

Part 21 (IS): Clear text encoding of the exchange structure	Структура текстового обменного файла
Part 22 (DIS): Standard data access interface specification	Спецификация программного интерфейса доступа к данным
Part 23 (CD): C++ language binding to the standard data access interface	Привязка C++ к программному интерфейсу доступа к данным
Part 24 (CD): C language binding to the standard data access interface	Привязка C к программному интерфейсу доступа к данным
Part 26 (WD): Interface definition language binding to the standard data access interface	Язык описания программного интерфейса доступа к данным

Conformance testing methodology and framework	Структура и методология проверки на совместимость

Part 31 (IS): General concepts	Общие концепции
Part 32 (FDIS): Requirements on testing laboratories and clients	Требования к испытательным лабораториям и клиентам
Part 34 (CD): Abstract test methods	Абстрактные методы тестирования
Part 35 (NWI): Abstract test methods for SDAI implementations	Абстрактные методы тестирования для реализаций программного интерфейса SDAI

Integrated generic resources	Общие интегрированные ресурсы

Part 41 (IS): Fundamentals of product description and support	Принципы описания и поддержки продукта
Part 42 (IS): Geometric and topological representation	Геометрическое и топологическое Представление
Part 43 (IS): Representation structures	Структуры представления
Part 44 (IS): Product structure configuration	Конфигурация структуры продукта
Part 45 (FDIS): Materials	Материалы
Part 46 (IS): Visual presentation	Визуальное представление
Part 47 (IS): Shape variation tolerances	Допуски на вариации форм
Part 49 (DIS): Process structure and properties	Структура и свойства процесса

Integrated application resource	Интегрированные прикладные ресурсы

Part101 (IS): Draughting	Черчение
Part 104 (CDC): Finite element analysis	Анализ методом конечных элементов
Part 105 (IS): Kinematics	Кинематика
Part 106 (WD): Building construction core model	Базовая модель конструкции

Application Protocols	Прикладные протоколы

Part 201 (IS): Explicit draughting	Прямое черчение
Part 202 (IS): Associative draughting	Ассоциативное черчение
Part 203 (IS): Configuration controlled design	Проектирование на основе заданной конфигурации
Part 204 (CD): Mechanical design using boundary representation	Проектирование механической конструкции на основе граничного представления
Part 205 (CD): Mechanical design using surface representation	Проектирование механической конструкции на основе поверхностного представления
Part 207 (FDIS): Sheet metal die planning and design	Проектирование штампов для листового Металла
Part 208 (WD): Life cycle management - Change process	Управление жизненным циклом – Изменение процесса
Part 209 (CD): Composite and metallic structural analysis and related design	Структурный анализ и проектирование изделий из металла и композиционных материалов
Part 210 (CD): Electronic assembly, interconnect and packaging design	Проектирование межсхемных соединений и упаковки электронных изделий
Part 212 (CD): Electrotechnical design and installation	Проектирование и установка электротехнических устройств
Part 213 (DIS): Numerical control process plans for machined parts	Программы ЧПУ для обработки деталей
Part 214 (CD): Core Data for Automotive Mechanical Design Processes	Базовые данные для проектирования автомобилей
Part 215 (WD): Ship arrangement	Схемы судов
Part 216 (WD): Ship moulded forms	Формы фасонных поверхностей для судовых корпусов
Part 217 (CD): Ship piping	Судовые трубопроводы
Part 218 (CD): Ship structures	Судовые надстройки
Part 220: Process planning, manufacture, and assembly of layered electronic products	Проектирование, производство и сборка многослойных печатных плат
Part 221 (CD): Functional data and their schematic representation for process plant	Функциональные данные и их схематическое представление для технологических процессов
Part 222 (WD): Exchange of product data for composite structures	Обмен данными об изделиях из композиционных материалов
Part 223 (WD): Exchange of design and manufacturing product information for casting parts	Обмен конструкторской и производственной информацией по литым изделиям
Part 224 (DIS): Mechanical product definition for process plans using machining features	Описание механических изделий в технологических процессах с использованием станочного оборудования
Part 225 (DIS): Building elements using explicit shape representation	Конструктивные элементы с явным представлением формы
Part 226 (WD): Ship mechanical systems	Судовые механические системы
Part 227 (DIS): Plant spatial configuration	Пространственная конфигурация завода
Part 228: Building services: Heating, ventilation, and air conditioning	Строительство: отопление, вентиляция и кондиционирование воздуха
Part 229: Exchange of design and manufacturing product information for forged parts	Обмен конструкторской и производственной информацией по кованным деталям
Part 230 (WD): Building structural frame: Steelwork	Строительные каркасы: стальные конструкции
Part 231 (CDC): Process engineering data: Process design and process specification of major equipment	Технологические данные: технологическое проектирование и технологические спецификации основного оборудования
Part 232 (NWI): Technical data packaging core information and exchange	Упаковка и обмен техническими данными

Abstract test suite	Набор абстрактных тестов

Part 301: Explicit draughting	Прямое черчение
Part 302 (WD): Associative draughting	Ассоциативное черчение
Part 303 (WD): Configuration controlled design	Проектирование на основе заданной Конфигурации
Part 304 (TR): Mechanical design using boundary representation	Проектирование механической конструкции на основе граничного представления
Part 305: Mechanical design using surface representation	Проектирование механической конструкции на основе поверхностного представления
Part 307: Sheet metal die planning and design	Проектирование штампов для листового металла
Part 308: Life cycle management - Change process	Управление жизненным циклом - Изменение процесса
Part 309: Composite and metallic structural analysis and related design	Структурный анализ и проектирование изделий из металла и композиционных материалов
Part 310: Electronic assembly, interconnect, and packaging design	Проектирование межсхемных соединений и упаковки электронных изделий
Part 312: Electrotechnical design and installation	Проектирование и установка электротехнических устройств
Part 313: Numerical control process plans for machined parts	Программы ЧПУ для обработки деталей
Part 314: Core data for automotive mechanical design	Базовые данные для проектирования Автомобилей
Part 315: Ship arrangement	Схемы судов
Part 316: Ship moulded forms	Формы фасонных поверхностей для судовых корпусов
Part 317: Ship piping	Судовые трубопроводы
Part 318: Ship structures	Судовые надстройки
Part 320: Process planning, manufacture, and assembly of layered electronic products	Проектирование, производство и сборка многослойных печатных плат
Part 321: Functional data and their schematic representation for process plant	Функциональные данные и их схематическое представление для технологических процессов
Part 322: Exchange of product data for composite structures	Обмен данными об изделиях из композиционных материалов
Part 323: Exchange of design and manufacturing product information for casting parts	Обмен конструкторской и производственной информацией по литым изделиям
Part 324: Mechanical product definition for process plans using machining features	Описание механических изделий в технологических процессах с использованием станочного оборудования
Part 325: Building elements using explicit shape representation	Конструктивные элементы с явным представлением формы
Part 326: Ship mechanical systems	Судовые механические системы
Part 327: Plant spatial configuration	Пространственная конфигурация завода
Part 328: Building services: Heating, ventilation, and air conditioning	Строительство: отопление, вентиляция и кондиционирование воздуха
Part 329: Exchange of design and manufacturing product information for forged parts	Обмен конструкторской и производственной информацией по кованным деталям
Part 330: Building structural frame: Steelwork	Строительные каркасы: стальные конструкции
Part 331: Process engineering data: Process design and process specification of major equipment	Технологические данные: Технологическое проектирование и технологические спецификации основного оборудования
Part 332: Technical data packaging core information and exchange	Упаковка и обмен техническими данными

Application interpreted construct	Элементы для конкретных приложений

Part 501 (DIS): Edge-based wireframe	Сетчатые конструкции ограниченные Плоскостями
Part 502 (DIS): Shell-based wireframe	Сетчатые конструкции ограненные Поверхностями
Part 503 (DIS): Geometrically bounded 2D wireframe	Геометрически ограниченные 2D сетчатые Поверхности
Part 504 (CD): Draughting annotation	Аннотирование чертежа
Part 505 (CD): Drawing structure and administration	Структура и реквизиты чертежей
Part 506 (CD): Draughting elements	Чертежные элементы
Part 507 (CD): Geometrically bounded surface	Геометрически заданные поверхности
Part 508 (CD): Non-manifold surface	non-BREPS-поверхности
Part 509 (CD): Manifold surface	BREPS-поверхности
Part 510 (DIS): Geometrically bounded wireframe	Геометрически ограниченные сетчатые Поверхности
Part 511 (DIS): Topologically bounded surface	Топологически ограниченные сетчатые Поверхности
Part 512 (DIS): Faceted boundary representation	Многогранное граничное представление
Part 513 (CD): Elementary boundary representation	Элементарное граничное представление
Part 514 (DIS): Advanced boundary representation	Сложное граничное представление
Part 515 (DIS): Constructive solid geometry	Конструкторская твердотельная геометрия
Part 516 (CD): Mechanical design context	Контекст механического проектирования
Part 517 (CD): Mechanical design geometric presentation	Геометрическое представление в механическом проектировании
Part 518 (CD): Mechanical design shaded representation	Штрихованное представление в механическом проектировании
Part 519 (CD): Associative draughting elements	Элементы ассоциативного черчения
Part 520 (CD): Associative draughting elements	Элементы ассоциативного черчения

<

Таблица П1.2
СОСТАВ СТАНДАРТА ISO 15531 (MANDATE)

Introduction	Введение
Part 1: Overview and fundamental principles of ISO 15531	Том 1. Общий обзор и основополагающие принципы

Production data for external exchange	Производственные данные для внешнего обмена

Part 21: Overview and fundamental principles	Том 21. Общий обзор и основополагающие принципы

Part-22: Conceptual model for external exchange of production data	Том 22. Концептуальная модель внешнего обмена данными (концептуальная модель, ресурсы и потоки)
Part 23: Identification, description and validation of Atomic semantic elements	Том 23. Идентификация, описание и проверка правильности "атомарных семантических элементов производства"

Manufacturing resources usage management data	Данные по управлению использованием Ресурсов

Part 31: Overview and fundamental principles;	Том 31. Общий обзор и основополагающие принципы
Part 32: Conceptual model for resources usage management data;	Том 32. Концептуальная модель данных по управлению использованием ресурсов
Part 33: Conformance testing.	Том 33. Проверка на совместимость

Imanufacturing flow management data	Данные по управлению производственными потоками

Part 41: Overview and fundamental principles;	Том 41. Общий обзор и основополагающие принципы
Part 42: Time model;	Том 42. Временная модель
Part 43: Conceptual model for flow monitoring and control;	Том 43. Концептуальная модель мониторинга и управления потоками
Part 44: Manufacturing data exchange	Том 44. Обмен производственными данными
Part 45: Conformance testing.	Том 45. Проверка на совместимость

ГОСУДАРСТВЕННЫЕ СТАНДАРТЫ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСТ Р ИСО 10303-1-99 Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1. Общие представления и основополагающие принципы.
ГОСТ Р ИСО 10303-11-2000 Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 11. Методы описания. Справочное руководство по языку EXPRESS.
ГОСТ Р ИСО 10303-12-2000. Системы автоматизации производства и их интеграция. Представление и обмен данными об изделии. Часть 12. Методы описания. Справочное руководство по языку EXPRESS-I.
ГОСТ Р ИСО 10303 –21-99. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 21. Методы реализации. Кодирование открытым текстом структуры обмена.
ГОСТ Р ИСО 10303 –41-99. Системы автоматизации производства и их интеграции. Представление данных об изделии и обмен этими данными. Часть 41 Интегрированные обобщенные ресурсы. Основы описания и поддержки изделий.
ГОСТ Р ИСО 10303-45-2000. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 45. Интегрированные обобщенные ресурсы. Материалы.
РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ
Р50.1.029-2001. "Информационные технологии поддержки жизненного цикла изделия. Интерактивные электронные технические руководства. Общие требования к содержанию, стилю и оформлению."
Данный документ определяет требования к стилю, содержанию и средствам диалогового общения с пользователем в интерактивных электронных технических руководствах.
Р50.1.030-2001. "Информационные технологии поддержки жизненного цикла изделия. Интерактивные электронные технические руководства. Логическая структура базы данных".
Данный документ определяет представления технических данных, знакомит производителей промышленных изделий с рекомендациями по подготовке интерактивных электронных технических руководств и осуществлению различных функций материально - технического снабжения.

Р50.1.031-2001. " Информационные технологии поддержки жизненного цикла изделия. Терминологический словарь.Часть 1. Терминология, относящаяся к стадиям жизненного цикла продукции".
Р50.1.032-2001. "Информационные технологии поддержки жизненного цикла изделия. Терминологический словарь. Часть 2. Основные термины и определения методологии и функциональных объектов в стандартах серии ISO 10303."
РС устанавливают термины и определения понятий в области CALS-технологий. Термины, установленные в РС, рекомендуются для применения во всех видах документации и литературы по технологиям непрерывной информационной поддержки жизненного цикла продукции.
Р50.1.027-2001. "Информационные технологии поддержки жизненного цикла изделия. Автоматизированный обмен технической информацией. Основные положения и общие требования".
РС распространяются на обмен между организациями или системами конструкторскими, технологическими, программными и другими проектными данными, представленными в электронном виде. РС определяют основные правила формирования пакета технических данных для электронного обмена, форматы представления технических данных об изделии, а также устанавливают требования и соглашения к логическому распознаванию файлов независимо от среды передачи технической информации.
Р50.1.028-2001. "Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования".
РС описывают язык моделирования IDEF0, правила и методику структурированного графического представления описания процессов (бизнес-процессов) предприятия или организации.

ПРИЛОЖЕНИЕ 2
МЕТОДИКА РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ
        Наличие формального описания бизнес-процессов позволяет решать задачи их анализа и оптимизации. В настоящее время для задач оптимизации (или улучшения) бизнес-процессов широкое распространение получил термин "реинжиниринг бизнес-процессов".
        В процессе оптимизации можно выделить два этапа:

первый - на основе логического анализа модели, путем структурной оптимизации бизнес-процессов, введения обратных связей, устранения дублирования и т.д.; второй - на основе количественного анализа. Для этого необходимо ввести ряд характеристик, аналогичных применяемым для анализа эффективности технологических процессов.
         В соответствии с методом АВС (ФСА - функционально-стоимостной анализ) каждый процесс имеет определенную стоимость. Каждый вид ресурса, потребляемый (обрабатываемый) процессом, а также механизмы, участвующие в реализации процесса, увеличивают стоимость процесса. При этом учитываются элементы затрат, игнорируемые при обычном представлении предприятия как совокупности организационных структур. Следовательно, каждому процессу h модели IDEF0 можно поставить в соответствие значение затрат на выполнение этого процесса Ex(h).
          Выполняемые процессы делятся на два вида:
- процессы, для которых вычисляется обрабатываемый ими поток информационно-материальных ресурсов и время выполнения;
- процессы, для которых вычисляется только время выполнения.
         Для процессов первого вида вводится понятие величин "входного потока" и "выходного потока". Входной поток i-го процесса AFi
– количество единиц информационно-материального обмена, поступившего на вход i-го процесса для обработки за период времени T. Выходной поток i-го процесса UFi – количество единиц информационно-материального обмена, полученных на выходе i-го процесса за период времени T.
         Для одного и того же процесса за анализируемый промежуток времени T входной поток может быть не равен выходному потоку, так как, возможно, не все поступившие за заданный период времени единицы информационно-материального обмена обработаны процессом (некоторые находятся в обработке). В этом случае говорят о возникшем «узком» месте.
         Дополнительно для процессов первого вида можно ввести следующие характеристики:
- производительность j-го механизма MFj – суммарное количество однородных единиц информационно-материального обмена, получающееся за период времени T на выходе всех процессов, использующих j-ый механизм;

                MF j = å UF i × d i j                                                                          (1.)

              i
где
            i = 1…I (I – количество анализируемых процессов),
            j = 1…J (J – количество механизмов)
- мощность j-го механизма MPj – максимально возможное количество однородных единиц информационно-материального обмена, обрабатываемое данным j-ым механизмом за период времени Т;
мощность i-ого процесса UPi
– количество единиц информационно-материального обмена, которое может быть получено на выходе i-го процесса за период времени Т при условии использования всей мощности всех механизмов, используемых в этом процессе.

Если для выполнения i - ого процесса используется один j - ый механизм, то мощность
i – ого процесса равняется
При использовании в процессе нескольких механизмов, мощность процесса будет определяться наименее мощным из них:

где j = 1...Ij (Ij - количество процессов, использующих механизм j )
Для возможности сравнительной оценки, введем коэффициент использования механизма в процессе g и обобщенный коэффициент использования механизма Г.

Коэффициент использования j-го механизма i-м процессом равен отношению производи- тельности i-го процесса и мощности j-го механизма процесса. Коэффициент gij показывает, какая часть мощности j-го механизма приходится на выполнение i-го процесса.

j = 1….J      (J – количество механизмов),
i = 1....I (I - количество процессов).
         Обобщенный коэффициент использования j-го механизма Gj есть сумма коэффициентов использования j-го механизма всеми процессами.
          Гj = ? (g ij •? ij)                                                                                                (5.)
          i

i = 1…I (I – количество процессов)
 Чем меньше коэффициент G, тем меньше загружен соответствующий механизм.

Обычно принимают:
- неполная загрузка механизма (G
< 0.4),
- удовлетворительная загрузка механизма (0.4 £ G £ 0.8),
- полная загрузка механизма (0.8 < G £ 1),
- перегрузка механизма (G > 1).
 Для процессов второго вида
также можно ввести коэффициент использования механизма в процессе ? и обобщенный коэффициент использования механизма В.
 Коэффициент использования j-го механизма в i-м процессе равен отношению затраченного на выполнение i-го процесса количества времени к величине нормативного времени работы j-го механизма за период T.
 Обобщенный коэффициент загрузки j-го механизма В определяется как сумма всех коэффициентов использования j-го механизма всеми анализируемыми процессами.

 В = ? (? ij • ?
ij) (6.)

i = 1…I (I – количество процессов)

Рис.П2.1. Применение количественных характеристик бизнес-процессов
для анализа их эффективности
 По аналогии с коэффициентом Г классифицируется неполная, удовлетворительная, полная загрузка механизма и перегрузка механизма.
 Введенный набор характеристик { Ex, MF, UF, MP, UP, ?, Г, ?, B } позволяет анализировать модель бизнес-процессов предприятия, искать «узкие» места, выявлять источники необоснованных затрат, вносить изменения в модель в соответствии с выбранной целью реинжиниринга (сокращение затрат, уменьшение длительности производственного цикла, сокращение объемов незавершенного производства и т. п.) (см. рис.П2.1).
 Один из возможных алгоритмов оптимизации на основе рассчитываемых характеристик, включает в себя следующую последовательность шагов:
1) определяем отчетный период времени Т отч., за который будут оцениваться характеристики (затраты, производительность, мощность, коэффициенты загрузки);
2) определяем затраты на выполнение каждой функции за Т отч.;
3) функции классифицируем по типам;

4) для функций первого типа определяем все введенные характеристики;
5) если обнаружены функции, для которых входной и выходной потоки не равны, то это означает возможное «узкое» место.
 Ликвидировать его можно тремя способами:
а) увеличением мощности механизма выполнения функции MP; ;
б) уменьшением производительности механизма выполнения функции MF для данной функции за счет уменьшения его использования другими функциями;
в) вводом нового механизма выполнения функции взамен или в дополнение к старому;
 Если обнаружены функции, использующие слабо загруженные механизмы (G < 0.4), то в этом случае оптимизация достигается:
а) путем высвобождения не полностью загруженных механизмов и перераспределения их нагрузки между другими механизмами (при условии не возрастания затрат на выполнение функций);
б) путем повышения обобщенного коэффициента использования механизма выполнения функции G и, по возможности, стремление его к единице.
Для всех функций определяют коэффициенты ? и В.
Если обнаружены функции, использующие мало загруженные механизмы (В < 0.4), то в этом случае оптимизация достигается:
а) путем высвобождения не полностью загруженных механизмов выполнения функций и перераспределения их нагрузки между другими механизмами (при условии не возрастания затрат на выполнение функций);
б) путем повышения обобщенного коэффициента использования механизма выполнения функции В и, по возможности, стремление его к единице;
 Проверка полученных результатов.

         Для проведения однозначной проверки и выбора оптимального решения предложен коэффициент эффективности использования j - го механизма в i - м процессе K i j,
равный отношению коэффициента использования j-го механизма в i-м процессе к величине затрат на выполнение i-го процесса Ex (i). При этом в качестве коэффициента использования механизма может применяться как коэффициент ?, так и коэффициент ?.
         Путем сравнения коэффициентов эффективности использования всех механизмов до изменения производительности процессов и после, можно установить, настолько ли эффективны вносимые изменения.

Если сумма коэффициентов эффективности на i-й процесс, рассчитанная по всем механизмам, не изменилась или увеличилась, то внесенные изменения оправданы. Иначе, следует изменить другие механизмы.
         Процесс реинжиниринга бизнес-процессов предприятия заключается не только в формализованном перераспределении нагрузки механизмов функциональной модели, но и в творческом подходе к перепроектированию связей между ними. Вычисляемые характеристики служат в качестве указателей на «болевые точки» предприятия. Выбор же оптимального решения осуществляется исходя из опыта специалистов по реинжинирингу, заданных критериев оптимизации и особенностей конкретной ситуации.
         Анализ и реинжиниринг бизнес-процессов является серьезным инструментом повышения эффективности работы предприятия, т.к.:
- представление о работе предприятия как о выполнении совокупности бизнес-процессов позволяет руководителю предприятия по-новому взглянуть на процесс функционирования подчиненной ему структуры, а рядовым сотрудникам – осознать свое место и обязанности в системе;
- введенная система определений (процесс функционирования предприятия, бизнес-процесс, операцию и переход) позволяет осуществлять конечную декомпозицию при создании функциональной модели, наглядно иллюстрирующей структуру и взаимосвязи бизнес-процессов и их составляющих;
- модель бизнес-процессов предприятия служит источником информации о функциях и связях между ними (т.е. о бизнес-процессах и их взаимосвязях), причем эта информация может быть извлечена из модели и представлена в виде отдельной базы данных, которая может в дальнейшем использоваться для решения разнообразных задач.
         Использование количественных характеристик (затрат на выполнение функции, производительности функции и механизма выполнения функций, мощности функции и механизма выполнения функции, коэффициентов загрузки) позволяет:
- оценить оптимальность организации бизнес-процессов и их составляющих,
- определить источники потерь,
- проконтролировать целенаправленно вносимые в систему изменения, которые ведут к организации оптимальной работы предприятия и взаимодействия работников предприятия при решении различных задач в рамках процесса функционирования предприятия,

- сократить объем и предотвратить образование незавершенного производства.
         Построенная по результатам внесенных изменений обновленная модель бизнес-процессов может становиться предметом анализа и оптимизации любое количество раз до достижения наилучших результатов.
         Методика анализа и реинжиниринга бизнес-процессов может быть использована не только на отдельном предприятии, но и в более сложных организационных структурах, деятельность которых связана с поддержкой жизненного цикла сложного изделия (изделий).
ПРИЛОЖЕНИЕ 3
ТЕРМИНОЛОГИЯ, ОТНОСЯЩАЯСЯ К СТАДИЯМ
ЖИЗНЕННОГО ЦИКЛА ПРОДУКЦИИ
          Материал данного приложения базируется на рекомендациях по стандартизации [17]. Этот руководящий документ устанавливает термины и определения понятий в области CALS-технологий, относящиеся к стадиям жизненного цикла продукции. Термины, установленные данным документом, обязательны для применения во всех видах документации и литературы по технологиям непрерывной информационной поддержки жизненного цикла продукции.
         При его разработке учтены следующие нормативные документы:
ГОСТ 1 3699-91 Запись и воспроизведение информации. Термины и определения
ГОСТ Р 51141-98 Делопроизводство и архивное дело. Термины и определения
ГОСТ 1 5971-90 Системы обработки информации. Термины и определения
ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения
ИСО 8402 Управление качеством и обеспечение качества – Словарь.
Р 50-605-80-93 Рекомендации по стандартизации. СРПП. Термины и определения

1. ОБЩИЕ ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
1.1. CALS (Continuous Acquisition and Life-Cycle Support)
Концепция и идеология информационной поддержки жизненного цикла продукции на всех его стадиях, основанная на использовании единого информационного пространства (интегрированной информационной среды), обеспечивающая единообразные способы информационного взаимодействия всех участников этого цикла: заказчиков продукции (включая государственные учреждения и ведомства), поставщиков (производителей) продукции, эксплуатационного и ремонтного персонала, реализованная в форме международных стандартов, регламентирующих правила указанного взаимодействия преимущественно посредством электронного обмена данными.
1.2. CALS-технологии
Информационные технологии описания изделий, производственной среды и процессов, протекающих в этой среде. Данные, порождаемые и преобразуемые этими информационными технологиями, представляются в виде, оговоренном CALS-стандартами, и служат для обмена или совместного использования различными участниками жизненного цикла продукции.
1.3. CALS-стандарты
Набор стандартов, описывающих правила электронного представления данных об изделиях, среде и процессах и правила обмена этими данными. Часть стандартов к настоящему времени имеет статус международных. Условно могут быть разделены на три основные группы:
-   стандарты, описывающие общие принципы электронного обмена данными, определяющие организационно-технические аспекты электронного взаимодействия (MIL-STD-1840);
-    стандарты, регламентирующие технологии обеспечения безопасности данных, в частности, их шифрование в процессе обмена, применение электронной цифровой подписи для подтверждения их достоверности и т.д.
-    технические стандарты, определяющие форматы и модели данных, технологии представ- ления данных, способы доступа и использования данных, описывающих изделия, процессы и среду, в которой протекает жизненный цикл изделия (ISO 10303).
1.4. Логистика (Logistic)

1) Наука о методах и способах управления материальными и информационными потоками в производстве и бизнесе.
2) Планирование, контроль и управление транспортированием, складированием, переработкой и др. операциями в процессе доставки готовой продукции потребителю.
1.5. Система (System)
Множество (совокупность) материальных объектов (элементов) любой, в том числе различной, физической природы и информационных объектов, взаимодействующих между собой для достижения общей цели, обладающее системным свойством (свойствами), т.е. свойством, которого не имеет ни один из элементов и ни одно из подмножеств элементов при любом способе членения. Системное свойство не выводимо непосредственно из свойств элементов и частей.
1.6. Подсистема(Sub-System)
Часть системы, обладающая собстственным системным свойством.
1.7. Элемент (Element, Entity)
Неделимая ( конкретном контексте) часть системы, обладающая известными свойствами, определяемым набором характеристик или параметров.
1.8. Атрибут (Attribute)
Именованная характеристика (параметр) элемента, системы, подсистемы, которая может приобретать конкретное значение на заданном множестве (числа, векторы, символы, выражения, логические значения и т.д.)
1.9 Жизненный цикл изделия (ЖЦИ) (Life Cycle)
Совокупность этапов, через которые проходит изделие за время своего существования: маркетинговые исследования, составление технического задания, проектирование, технологическая подготовка производства, изготовление, поставка, эксплуатация, утилизация.
1.10 Общее моделирование изделия (Интегрированная информационная модель изделия) (Total Product Modelling)
Полное, всестороннее описание как самого изделия (состав и структура, геометрические твердотельные модели САПР, конечноэлементные и другие модели для расчетов), так и
технологических приемов его производства, особенностей его функционирования, режимов эксплуатациии .
2. ИНТЕГРИРОВАННАЯ ИНФОРМАЦИОННАЯ СРЕДА
И ИНФОРМАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ

2.1. Интегрированная информационная среда (ИИС) (IIE - Integrated Information Environment).
Совокупность распределенных баз данных, содержащих сведения об изделиях, производственной среде, ресурсах и процессах предприятия, обеспечивающая корректность, актуальность, сохранность и доступность данных тем субъектам производственно-хозяйственной деятельности (ПХД), участвующим в осуществлении ЖЦИ (в дальнейшем
- субъекты ПХД), кому это необходимо и разрешено. Все сведения (данные) в ИИС хранятся в виде информационных объектов
2.2. Информационный объект (ИО) (Information Object)
Совокупность данных и программного кода, обладающая свойствами (атрибутами) и методами, позволяющими определенным образом обрабатывать данные. Самостоятельная
единица применения и хранения в ИИС
2.3. Класс информационных объектов (КИО) (Class of Information Objects, Entity).
Информационный объект, свойства которого объявлены, но им не присвоены конкретные значения. Класс может порождать множество экземпляров, наследующих его свойства и методы.
2.3. Экземпляр класса (Instance)
Информационный объект, полученный из КИО присвоением свойствам конкретных значений.
2.4. Коллекция объектов (КО) (Information Objects Collection).
Совокупность экземпляров ИО, относящихся к одному или нескольким классам. КО позволяет добавлять и удалять ИО и обращаться к любому из них. КО может использоваться
для создания нового ИО.
2.5. Информационное взаимодействие (Information interaction).
Совместное использование данных, находящихся в ИИС, и обмен данными, осуществляемые субъектами ПХД, в соответствии с установленными правилами
2.6. Совместное использование данных
Независимое обращение субъектов ПХД к ИО, находящимся в ИИС, с целью их использования в приложениях или модификации в соответствии с установленными правилами.
2.7. Обмен данными (Data Exchange).
Передача ИО от одного субъекта ПХД к другому через ИИС
2.8. Правила информационного взаимодействия и обмена данными.

Правила, регламентирующие для субъектов ПХД :
- доступ к ИО;
- право модификации ИО;
- право на помещение нового ИО в ИИС;
- протоколы передачи данных по каналам связи;
- условия защиты информации в ИИС;
- структуру и форму обменного файла .
2.9. Общая база данных об изделиях (ОБДИ) (Common ProductData Base, CPDB).
Часть ИИС - хранилище ИО, содержащих в произвольном формате информацию, требуемую для выпуска и поддержки технической документации, необходимой на всех стадиях ЖЦИ, для всех изделий, выпускаемых предприятием. Каждый ИО в ОБДИ идентифицируется уникальным кодом и может быть извлечен из ОБДИ для выполнения действий с ним. ОБДИ обеспечивает информационное обслуживание и поддержку деятельности:
- заказчиков (владельцев) изделия;
- разработчиков (конструкторов), технологов, управленческого и производственного персонала предприятия – изготовителя;
- эксплуатационного и ремонтного персонала заказчика.
         ОБДИ может состоять из нескольких разделов:
- нормативно-справочного;
- долговременного;
- актуального.
         Нормативно-справочный раздел ОБДИ хранит данные:
- о конструкционных материалах;
- о нормализованных деталях;
- о стандартных деталях и изделиях;
- о стандартных расчетных методах;
- о государственных, международных и внутренних стандартах;
- о прочих нормативных документах.
Содержание нормативно – справочного раздела ОБДИ обновляется по мере обновления нормативных документов.
         Долговременный раздел ОБДИ хранит ИО, содержащие данные, аккумулирующие
собственный опыт предприятия, в том числе данные:
- о ранее выполненных готовых проектах (архив);
- о типовых деталях, узлах и агрегатах собственного производства;
- о типовых конструктивно – технологических элементах (КТЭ) деталей;
- о типовых и групповых технологических процессах;
- о типовой технологической оснастке и инструменте;
- о готовых и типовых расчетных методиках и математических моделях изделий собственной разработки;
- о прочих готовых и типовых решениях.

Долговременный раздел ОБДИ обновляется по мере создания новых технических решений, признанных типовыми и пригодными для дальнейшего использования.
         Актуальный раздел ОБДИ хранит ИО, содержащие данные об изделиях, находящихся на различных стадиях ЖЦИ:
- о конструкции и технологии изготовления изделий;
- о конкретных экземплярах изделий в производстве;
- о конкретных экземплярах изделий, находящихся на постпроизводственных стадиях ЖЦИ.
2.10. Общая база данных о предприятии (ОБДП).
Часть ИИС - хранилище ИО, содержащих в произвольном формате информацию о финансово - экономическом состоянии предприятия, о его внешних связях, о производственно – технологической среде, о действующей на предприятии системе качества и т.д.
2.11. Электронное хранилище (Vault)
Область хранения ИИС. В хранилище находятся либо ИО, либо информация о путях доступа к ним. Информация в электронных хранилищах контролируется на основе специальных правил и порождаемых ими процессов.
2.12. Документ электронный (ДЭ).
Информационный объект, состоящий из двух частей:
- реквизитной, содержащей идентифицирующие атрибуты (имя, время и место создания, данные об авторе и т.д.) и электронную цифровую подпись;
- содержательной, включающей текстовую, числовую и/или графическую информацию, которая обрабатывается в качестве единого целого.
При необходимости документ электронный может приобретать различные формы визуального отображения: на экране или на бумаге.
2.13. Электронная цифровая подпись (ЭЦП) (Digital signature)
Специальное криптографическое средство обеспечения подлинности, целостности и авторства ДЭ или ДТЭ. ЭЦП связывает содержание документа и идентификатор подписывающего лица и делает невозможным изменение документа без нарушения подлинности подписи. Формирование ЭЦП электронного документа или пакета документов (или файлов) при их подготовке и передаче, а также проверка наличия и неискаженности подписи
обеспечиваются специальными программными средствами.

3.ФУНКЦИОНИРОВАНИЕ И ВЗАИМОЛЕЙСТВИЕ
ПРЕДПРИЯТИЙ И ОРГАНИЗАЦИЙ
3.1. Предприятие (Enterprise)
Самостоятельная организация, обладающая материальными (производственными), энергетическими, кадровыми, финансовыми и другими ресурсами, осуществляющее деятельность по производству продукции или/и оказанию услуг с целью их реализации потребителям и извлечения прибыли. Обычно имеет статус юридического лица. Организационно
состоит из основных и вспомогательных подразделений.
3.2. Бизнес-процесс (БП) (Business-process)
Совокупность последовательно или/и параллельно выполняемых операций, преобразующая материальный или/и информационный потоки в соответствующие потоки с другими свойствами. БП протекает в соответствии с управляющими директивами, вырабатываемыми на основе целей деятельности. В ходе БП потребляются финансовые, энергетические, трудовые и материальные ресурсы и выполняются ограничения со стороны других БП и внешней среды. Частными случаями БП являются организационно-деловые, технологические и др. процессы.
3.3. Анализ бизнес – процессов (Business-process analysis)
Исследование БП, проводимое с целью оценки их эффективности, выявления «узких мест» и резервов, определения качества организации материальных и информационных
потоков, соответствия организационной структуры характеру деятельности предприятия, оценки достаточности или избыточности ресурсов и т.д. Обычно выполняется с помощью функционального моделирования.
3.4. Функциональное моделирование бизнес-процессов
Методология и программный инструментарий анализа БП, позволяющий представить все множество БП предприятия в виде набора диаграмм, отображающих все функции, выполняемые в ходе БП, а также связывающие их материальные и информационные потоки и потребные ресурсы. Наиболее распространенная методология функционального моделирования – SADT и ее реализация (в США) – IDEF0.
(SADT – Structural Analysis and Design Technology, IDEF – Integrated DEFinition)
3.5.

Реинжиниринг бизнес-процессов (Business-process reengineering, BPR)
Комплекс мероприятий, направленных на совершенствование и повышение эффективности БП. Обычно включает в себя такие меры, как уточнение, объединение и/или разбиение функций, делегирование полномочий персонала «сверху вниз», устранение параллельных
потоков и дублирования, выравнивание загруженности персонала.
3.6. Расчет затрат, связанных с бизнес-процессами (Activity Based Costing, ABC)
Определение с помощью специального программного средства суммарных издержек, связанных с БП. Проводится посредством последовательного суммирования издержек, связанных с отдельными функциями по всем диаграммам функциональной модели. Иначе он именуется как функционально-стоимостной анализ (ФСА).
3.7. Предприятие виртуальное (Virtual enterprise)
Группа предприятий, объединившихся для достижения общей цели и взаимодействующих посредством распределенной информационной среды (например, посредством Internet).
4. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ, ОТНОСЯЩИЕСЯ К СТАДИЯМ ЖЦИ
4.1Маркетинг (Marketing)
Систематическая работа по изучению: рынков сбыта и требований потребителей к продукции предприятия; условий эксплуатации продукции предприятия; поставщков материальных ресурсов, их возможностей в отношении качества и дисциплины поставок.
4.2. Затраты на ЖЦИ (Life Cycle Cost, LCC)
Суммарные затраты на приобретение, модернизацию, эксплуатацию и обслуживание изделия в течение всего ЖЦИ. Точное математическое определение СЖЦИ изменяется в зависимости от используемой модели ЖЦИ. Эта модель должна быть согласовано всеми сторонами, участвующими в проекте.
4.3. Полномасштабное проектирование (Full Scale Development)
Реализация согласованной детальной программы проектирования, включающей создание моделей или опытных образцов, проведение необходимых испытаний, целью которых является постановка изделия на производство и ввод его в эксплуатацию с выпуском всей необходимой документации и обеспечением информационной поддержки ЖЦИ.

4.4. Концептуальное (эскизное) проектирование (Engineering)
Стадия конструкторской подготовки   производства    (ПП),   выполняемая при помощи
САЕ/CAD-системы, в ходе которой разрабатывается облик изделия (форме геометрической 3D модели) и создаются ИО, содержащие компоновочные, структурные, принципиальные схемы изделия, выполняются предварительные проектировочные расчеты и моделирование.
4.5. Разработка (техническое проектирование) (Development)
Стадия конструкторской ПП, выполняемая при помощи CAD-системы, в ходе которой разрабатывается подробная 3D-модель изделия, а также 3D-модели узлов, агрегатов и основных (базовых) деталей, на базе которых формируются 2D-проекции (чертежи), выполняются уточненные проектировочные расчеты и моделирование. Результаты работ оформляются в виде ИО помещаемых в ИИС.
4.6. Конструирование (изготовление рабочей конструкторской документации) (Design)
Стадия конструкторской ПП, выполняемая при помощи CAD-системы, в ходе которой создаются 3D-модели всех оригинальных деталей и их 2D-проекции (чертежи), оформляются спецификации и ведомости материалов, комплектующих и нормализованных изде -
лий, выполняются проверочные расчеты и моделирование. Результаты работ оформляются в виде ИО, помещаемых в ИИС.
4.7.Обеспечение качества при проектировании
Комплекс специальных мер, принимаемых на всех стадиях проектирования с целью получения проекта, в максимально возможной степени соответствующего требованиям технического задания, ожиданиям потребителя и нормам российских и международных стандартов. Как правило, этот комплекс мер включает:
- сопоставление результатов расчетов и моделирования характеристик изделия на всех стадиях проектирования с характеристиками, предусмотренными техническим заданием, и минимизацию их различий;
- выполнение контрольной сборки для обеспечения уверенности в правильности геометрических размеров, сопряжений и взаимного расположения деталей и узлов;
- проведение процедуры нормоконтроля с целью выявления отклонений в оформлении ДТЭ от требований стандартов и правильности использования стандартных и нормализованных компонентов конструкции.

4.8. Пакет технических данных (Technical data package)
Техническое описание, обеспечивающее инженерную, производственную и логистическую поддержку ЖЦИ, определяющее конфигурацию изделия и процедуры проверки работоспособности изделия. Пакет технических данных включает: чертежи, списки запчастей, спецификации материалов и процессов, стандарты, технические требования к изделию, сертификаты качества, описания упаковки и т.п.
4.9. Планирование производства (Production Process Planning,PPP)
Совокупность программных средств и данных, обеспечивающая выполнение следующих функций:
- объемное планирование и формирование графиков производства (Master Production Scheduling, MPS);
- планирование по группам продукции для основных подразделений;
- расчет производственных мощностей основных подразделений и определение мер, обеспечивающих соответствие мощностей объемам выпуска;
- расчет и планирование потребностей в материалах и комплектующих с учетом графиков производства (Materials Requirement Planning, MRP);
- расчет сменно-суточных плановых заданий для подразделений и технологического оборудования (оперативное производстственное планирование) (Finite Scheduling, FS)
4.10. Всеобщее управление качеством (Total Quality Management, TQM)
Совокупность программных средств и данных, обеспечивающая выполнение функций, предписываемых международным стандартом ISO 9000, в том числе:
- сбор, хранение и статистическая обработка данных о входном контроле материалов и комплектующих;
- сбор, хранение и статистическая обработка данных о результатах операционного контроля деталей и сборочных единиц (узлов, подузлов ) в процессе производства;
- сбор, хранение и статистическая обработка данных о результатах выходного контроля (приемосдаточных испытаний) готовых изделий;
- формирование комплекта документов о качестве для конкретного экземпляра изделия (формуляра качества);
- планирование, документирование и учет мероприятий по обеспечению качества в соответствии с ISO 9000 и т.д.

4.11.Производство (Production)
Совокупность БП, имеющая целью преобразование материальных обътов(материалов, заготовок , полуфабрикатов, комплектующих изделий) в новый материальный объект - готовое (конечное) изделие надлежащего качества, т.е. удовлетворяющее требованиям потребителей, зафиксированным в техническом задании и иных конструкторских документах. Все БП, протекающие в ходе производства, отображаются в ИИС посредством создания и/или преобразования соответствующих ИО.
4.12. Интегрированная логистическая поддержка (ИЛП) (Integrated Logistic Support, ILS)
Методика управления, нацеленная на оптимизацию затрат в течение ЖЦИ. Она включает элементы влияния на процесс проектирования изделия с целью определения условий протекания постпроизводственных стадий ЖЦИ, выполнение которых обеспечит максимальную поддержку изделия в период эксплуатации.
4.13. Интерактивное электронное техническое руководство (ИЭТР) (Interactive ElectronicTechnical Manual, IETM)
Комплекс взаимосвязанных ИО, содержащих сведения, необходимые обслуживающему персоналу при эксплуатации и ремонте изделия. Предназначено для отображения необходимых данных (справочной и описательной информации) в интерактивном режиме на электронном дисплее.
4.14. Электронная система отображения (ЭСО)
Комплекс программно – технических средств для воспроизведения данных, содержащихся в ИЭТР, в виде, доступном для восприятия человеком.
4.14. Язык разметки данных (Standard GeneralizedMarkupLanguage, SGML)
Специальный язык, позволяющий представить данные в виде совокупности ИО. Регламентирован стандартом ISO 8879.
8. ПРИМЕНЕНИЕ CALS-ТЕХНОЛОГИЙ В РАЗЛИЧНЫХ ОБЛАСТЯХ

8.1. Применение CALS-технологий в области электроники
Конкурентоспособность вновь создаваемой продукции в определяющей степени зависит от оперативности и качества ее разработки. Особенно остро стоят эти проблемы при проектировании наиболее сложных технических объектов, к числу которых относятся, прежде всего, ответственные радиоэлектронные системы и средства (РЭС) народнохозяйственного и оборонного назначения.

На многих отечественных аппаратостроительных предприятиях- разработчиках РЭС на проектирование таких систем затрачивается до 5 - 7 лет. При этом, несмотря на столь значительные сроки создания опытных образцов РЭС, освоение их серийного выпуска и первые годы эксплуатации сопровождаются многочисленными доработками, целями которых является устранение различного рода недостатков, дефектов и предпосылок к отказам. Причины такого положения коренятся в недостатках процессов проектирования и отработки создаваемых образцов РЭС, связанных со слабым применением автоматизированных методов проектирования и современных информационных технологий, базирующихся на математическом моделировании разрабатываемых объектов и их составных частей.
Объективные трудности в использовании моделирования как основного инструментария для целенаправленного выбора и анализа проектных решений, оптимизации параметров проектируемых схем и конструкций систем, прогнозирования работоспособности РЭС в заданных условиях эксплуатации состоят в том, что до выполнения настоящей работы отсутствовали возможности комплексного, т.е. совместного математического моделирования одновременно протекающих в РЭС и их элементах процессов (электрических, тепловых, механических, аэродинамических, электромагнитных и других), обусловленных как процессами функционирования РЭС и воздействием внешних факторов, так и процессами их износа и старения. Разные по своей природе физические процессы, протекающие в РЭС, описываются различными математическими законами. Например, электрические процессы в цепях с сосредоточенными параметрами описываются обыкновенными дифференциальными уравнениями, а в цепях с распределенными параметрами - волновыми уравнениями, тепловые процессы в элементах конструкций - уравнениями теплопроводности в частных производных второго порядка, а механические процессы колебаний печатных узлов - бигармоническими уравнениями в частных производных четвертого порядка.
С учетом граничных условий процедуры согласования таких разных моделей с целью их объединения в единую математическую модель РЭС требовало неприемлемо больших, с точки зрения практики, затрат вычислительных ресурсов ЭВМ.

Проблема осложняется тем, что современные РЭС включают в себя большое количество комплектующих электрорадиоизделий (до десятков и сотен тысяч электрорадиоизделий в одном образце РЭС), каждое из которых представляет сложный объект, характер протекания физических процессов, в которых в конечном итоге и определяет функциональные и эксплуатационные свойства проектируемого образца РЭС.
Выход из создавшегося положения лежит в унификации математических моделей разнородных физических процессов на основе существующей аналогии протекания. Это позволяет значительно снизить трудоемкость интеграции их в единую комплексную модель, обеспечить полноту и достоверность результатов моделирования, разработать соответствующую методологию и реализующую ее принципиально новую многофункциональную автоматизированную систему анализа схемотехнических и конструктивно-технологических решений и надежности проектируемых РЭС. Данная система получила первоначальное название «АСОНИКА», что расшифровывается как автоматизированная система обеспечения надёжности и качества аппаратуры.
Система «АСОНИКА» по основным характеристикам (перечню решаемых задач, глубине выполняемого анализа, достоверности получаемых результатов, удобству пользования), существенно превосходит отечественные аналоги и не уступает известным зарубежным системам аналогичного назначения. Она получила широкое распространение на предприятиях России и стран СНГ, используется как разработчиками сложных и ответственных РЭС народнохозяйственного и оборонного назначения, так и при проведении экспертных исследований, выполняемых заказчиками РЭС на ранних стадиях выполнения ОКР по их разработке.
Опыт создания и внедрения системы «АСОНИКА» нашел отражение в требованиях Генерального заказчика РЭС военного назначения к процессам их разработки, в межотраслевых программах и координационных планах развития автоматизированных систем проектирования, в разработке концепции создания интегрированных автоматизированных систем разрабатывающих предприятий, в развитии информационных технологий поддержки изделий в сквозных циклах «проектирование - производство - эксплуатация».

Создание наукоемких технологических объектов в настоящее время ориентируется на CALS – технологии (Continuous Acquisition and Life-cycle Support), которые позволяют интегрировать процессы, протекающие в ходе жизненного цикла продукции на основе специально организованной единой информационной среды, охватывающей все стадии жизненного цикла создаваемой продукции.
Применение CALS – технологий требует определенной реорганизации процесса создания наукоемкой продукции, к которой относятся как автономные изделия электроники, так и электронные изделия, входящие в состав сложных приборных комплексов.
Создание РЭС, обладающих высокими показателями технического уровня (высокие удельные массогабаритные показатели, а также показатели надежности, качества, помехозащищенности и т.п.), требует применения специальной методологии, базирующейся на системных принципах разработки сложных систем и комплексном математическом моделировании физических процессов. Такую комплексность моделирования обеспечивает система «АСОНИКА».
Однако, современная методология проектирования, производства и эксплуатации РЭС должна быть согласована с основными принципами CALS – технологий. Тем более, что заказчики и покупатели РЭС в настоящее время все чаще требуют документацию в электронном виде. Система «АСОНИКА» обеспечивает дополнение обычного перечня конструкторской документации результатами расчетов и моделями, по которым эти расчеты проведены. Таким образом формируется электронный виртуальный макет создаваемого РЭС, который может быть передан на этапы изготовления и эксплуатации.
Электронный виртуальный макет используется для поиска оптимальных режимов изготовления и эксплуатации РЭС и позволяет удостовериться в возможности замены материалов и режимов их обработки и применения.
С учетом вышеизложенного в данной работе рассматривается методологический подход, позволяющий применить автоматизированную систему обеспечения надежности и качества аппаратуры «АСОНИКА» в рамках технологии проектирования радиоэлектронной аппаратуры (РЭА), основанной на CALS– идеологии.

Методика применения системы «АСОНИКА» основывается на технологии хранения и управления данными о РЭА (Product Data Management/PDM – технология), являющейся составной частью CALS – технологий.
В рамках системы «АСОНИКА» реализуется специальный программный комплекс, который создает структуру электронного (виртуального) макета разрабатываемой РЭА, наполняет данную структуру результатами работы проблемных подсистем системы «АСОНИКА» (подсистемы позволяют моделировать электрические, тепловые, аэродинамические, гидравлические, механические и деградационные процессы в РЭА, осуществляют диагностическое моделирование, анализ показателей надежности, а также позволяют интегрироваться с системами топологического проектирования РЭА /OrCAD-9.1, PCAD, Accel и т.п.). Программный комплекс управляет процессом отображения результатов модельных экспериментов на геометрической модели, входящей в состав электронного макета, а также преобразует, электронный макет, после его обработки, в формат стандарта ISO 10303 STEP. Данные, входящие в электронный макет используются на последующих стадиях жизненного цикла РЭА.

8.1.1. ПОРЯДОК ПРОЕКТИРОВАНИЯ РЭС С ПЕЧАТНЫМИ УЗЛАМИ
Перед рассмотрением методики проектирования печатных узлов (ПУ), покажем ее место в общем цикле разработки РЭС. Процесс разработки РЭС в целом строится, как правило, на основе типовых проектных процедур. Количество процедур и их последовательность определяются как спецификой РЭС, так и методологией проектирования, которая основывается в настоящее время на системных принципах проектирования РЭС с применением САПР.
Исходя из вышеизложенного, рассмотрим   маршрут автоматизированного проектирования (АП) РЭС нестационарного исполнения для самых ранних стадий их разработки. Предполагается, что РЭС выполняется в виде блока, который, в свою очередь, имеет в своём составе ряд конструктивных узлов. На приведенном маршруте (рис.20) показаны проектные процедуры, связи между которыми отображаются в виде различных информационных потоков. Нумерация автоматизированных проектных процедур на схеме маршрута отражает генеральную последовательность их выполнения.

Рассматриваемый маршрут ориентирован на исследование в РЭС различных физических процессов - электрических, тепловых, электромагнитных, механических, деградационных и т. п. На рис.26 условно изображены информационные потоки (Дтз1 – Дтз7), которые отражают как требования ТЗ к определенным характеристикам и показателям РЭС (например, электрическим, надежностным, массо-габаритным и т. д.), так и уровень дестабилизирующих факторов (например, температурные и механические воздействия и т. д.).
Блок 1. На начальном этапе маршрута проектирования выполняется процедура предварительного моделирования электрических процессов,     протекающих в схеме РЭС. Результаты моделирования (вектор электрических характеристик (ЭХ)) сравниваются с требованиями технического задания (ТЗ) к ЭХ, которые содержатся в информационном потоке Дтз1. Неопределенность некоторых данных на рассматриваемом этапе (отсутствие информации о локальных температурах ЭРЭ, о значениях паразитных параметров печатного монтажа и т. п.), снимается их заданием в первом приближении на основе личного опыта инженера-проектировщика. Позднее, когда эта информация будет получена по результатам соответствующего моделирования, осуществляется итеративная обратная связь (повторение расчётов с новыми данными, например, температурами

).
Блок 2. Исходя из результатов моделирования ЭХ разрабатываемого РЭС, требований к параметрам конструкции (если задаются в ТЗ), а также уровня тепловых и механических воздействий, включая мощности

тепловыделений на электрорадиоэлементах (ЭРЭ), осуществляется предварительная автоматизированная разработка конструкции проектируемого устройства. В процессе разработки конструкции решаются, например, следующие задачи: компоновка электрической схемы в типовые конструктивные узлы (разрезание схемы на части); размещение конструктивных узлов, например в блоке, с учетом тепловых, электромагнитных и механических характеристик; определение параметров корпуса блока, исходя из действующих на него дестабилизирующих факторов, а также требований к массо-габаритным и удельным характеристикам (обычно задаются в ТЗ или ЧТЗ (информационный поток Дтз2) и т.

п.
Блок 3. Для разработанного первоначального варианта конструкции РЭС моделируется ее тепловой режим (ТР) при помощи соответствующих программных средств. Для анализа теплового режима используется макромодель всей конструкции, т. е. осуществляется контроль теплового режима конструкции самого верхнего уровня иерархии (стойки, блока или микроблока). В потоке исходной информации для моделирования ТР могут быть использованы данные ТЗ (информационный поток Дтз3), в качестве которых могут выступать: воздействующие температуры окружающей среды и их временные диаграммы; допустимые перегревы или интегральные температуры отдельных конструктивных узлов или ЭРЭ; вид охлаждения и его параметры и т.п.
Блок 4. Основываясь на результатах предыдущих процедур, решается в первом приближении задача размещения ЭРЭ на монтажных полях конструктивных узлов (КУ), на которых реализуются соответствующие фрагменты электрической схемы. На данном этапе выполняется также предварительная трассировка печатного или пленочного монтажа.
Используемые в процессе решения перечисленных задач топологического проектирования, алгоритмы и критерии определяются дестабилизирующими факторами и технологическими требованиями (классом точности изготовления печатной платы, количеством слоев печатной платы), уровнем помехозащищенности и т. п.

Рис.26. Маршрут сквозного АП РЭС
Блок 5. Используя результаты размещения ЭРЭ на несущих конструктивах (подложках, печатных платах, основаниях функциональных ячеек и т. п.), а также вектор мощностей ЭРЭ (

), граничные или краевые условия (

), полученные в блоке 3 маршрута проектирования, осуществляется детальное моделирование тепловых режимов конструктивных узлов (печатных узлов (ПУ), функциональных ячеек (ФЯ), узлов радиаторов (УР), микросборок (МСБ) и т.п.) с помощью соответствующих программных средств.
Блок 6. Выполняется процесс моделирования механических режимов работы (МР) проектируемой конструкции.

При этом в качестве исходной информации используют данные ТЗ или ЧТЗ (поток Дтз4), которые определяют требования к резонансным частотам конструктивных узлов и элементов РЭС, а также вид механических воздействий и их параметры, включая информацию об уровнях механических воздействий в местах установки конструктивных узлов. Кроме этого, в качестве исходных данных выступают координаты установки ЭРЭ (

), полученные в результате размещения (см. блок 4) и скорректированные в процессе анализа и обеспечения тепловых характеристик в блоке 5, а также тепловые поля конструкции (

) для возможного учета температурных зависимостей физико-механических параметров материалов и т. д.
Блок 7. Осуществляется анализ электромагнитной совместимости (ЭМС) разрабатываемого устройства. В первом приближении оценивается, например, необходимость введения экранов и их эффективность. Исходной информацией для анализа ЭМС являются конструктивные параметры устройства и его электрические характеристики (частотные характеристики, токи и напряжения в узлах схемы и т. д.).
Для оценки основных характеристик внутриаппаратурной ЭМС используется специальная программа.
Блок 8. На основе результатов предыдущих этапов маршрута АП (блоки 1, 3, 5, 6) осуществляется оценка безотказности устройства по постепенным отказам, допусковый анализ и т. п. Исходной информацией для данного вида анализа служат электрические характеристики (токи (

), функции чувствительности выходных характеристик устройства к изменению параметров элементов схемы (

) и т. д., параметры дестабилизирующих факторов, например температуры элементов (

) и виброперегрузки на ЭРЭ (

) и т. д., а также требования ТЗ к анализируемым показателям безотказности (информационный поток Дтз5).
Блоки 9–10. Выполняется анализ показателей надежности проектируемого устройства по внезапным отказам. В качестве исходной информации для моделирования выступают коэффициенты электрической нагрузки ЭРЭ (

), интенсивности отказов ЭРЭ (

), температуры и виброускорения ЭРЭ (

), механические напряжения

в материалах.

Кроме этого, в ТЗ или в ЧТЗ регламентируют данные на показатели безотказности устройства в целом (информационный поток Дтз7), а также на отдельные конструктивные узлы (информационный поток Дтз6).
Блок 11. С учетом внесенных на предыдущих этапах маршрута АП изменений в координатах размещения ЭРЭ с позиций обеспечения тепловых

и механических

режимов работы, анализа ЭМС

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

в блоке 1; учет вектора

в блоках 4 и 6; учет вектора

в блоках 3 и 5 и т.п.).
Блок 12. На заключительном этапе маршрута после итеративных расчетов осуществляется автоматизированный выпуск комплекта конструкторской документации (КД), например, средствами системы AutoCAD на проектируемое устройство. В данном блоке также выполняются операции по разработке комплекта технологической документации (ТД).
Как следует из маршрута сквозного автоматизированного проектирования РЭС (рис.26, блоки 2, 4, 11), разработка топологии печатных плат состоит из двух взаимосвязанных основных этапов: размещение компонентов и трассировка печатных   проводников. Их взаимосвязь обусловлена не только внешними факторами: механическими и тепловыми воздействиями, условиями распространения электрического сигнала, расположением и закреплением платы в блоке и т.

д., но и технологией изготовления ПП и ПУ, а также конструкторско-технологическими нормами на проектирование.
Относительно РЭС в целом можно выделить следующие хорошо отработанные процедуры автоматизированного топологического проектирования:
1.             Компоновка (упаковка частей схемы в типовые конструктивные единицы).
2.             Размещение (размещение конструктивных узлов или ЭРЭ на монтажном пространстве несущей конструкции (блока, печатной платы, подложки, кристалла) по определённым критериям).
3.             Трассировка (определение конкретных геометрических параметров печатного, плёночного или проводного монтажа, реализующего соединения между элементами схемы).
В общем случае, можно выделить следующую последовательность автоматизированных процедур проектирования печатных узлов:
1. Анализ частного технического задания (ЧТЗ) на разработку платы.
2. Выбор класса точности и шага координатной сетки.
3. Выбор типа ПП, ее габаритов и   материала основания.
4. Выбор и расчёт элементов печатного рисунка.
5. Размещение электрорадиоэлементов.
6. Исследование путем математического моделирования различных физических процессов (тепловых, механических, электромагнитных).
7.Трассировка печатных элементов, уточнение типа ПП, класса точности и габаритов.
8. Выбор конструкционных покрытий.
9. Анализ показателей надежности.

8.1.2. ОРГАНИЗАЦИЯ СТРУКТУРНОГО ПОСТРОЕНИЯ САПР ПЕЧАТНЫХ УЗЛОВ
Рассмотренный в предыдущем разделе маршрут сквозного автоматизированного проектирования РЭС, а также различные модели и методические аспекты разработки печатных узлов служат основой для рассмотрения основных положений методологии проектирования печатных узлов в рамках CALS-технологий Описанный маршрут - это непрерывная информационная поддержка жизненного цикла РЭС, которая базируется на стандартизации методов представления данных на каждой стадии жизненного цикла и на безбумажном электронном обмене данными.

Данный маршрут определяет набор правил, регламентов и стандартов, в соответствии с которыми строится информационное («электронное») взаимодействие участников процессов проектирования, производства, испытаний и эксплуатации. Он служит основой виртуальных предприятий.
Конструкторские данные об изделии, получаемые средствами CAD-систем позволяют решать ряд задач производственной сферы, материально-технического снабжения, сбыта, технического обслуживания и т.д. В настоящее время, несмотря на широкое применение компьютерных технологий в процессе проектирования радиоэлектронных средств, преимущества электронного представления информации в полной мере не используются. Получаемые CAD-системами данные до сих пор, как правило, переводятся на бумажный носитель. Одной из основных причин такой ситуации является сложность интеграции информационных потоков, поступающих от различных процессов разработки РЭС, их испытаний и т.п.
Одной из основополагающих частей CALS – идеологии является технология хранения и управления данными о продукте (Product Data Management / PDM – технология /), которая позволяет решить указанные выше проблемы путем использования стандартизованного интегрированного описания изделия, которое, в свою очередь, базируется на стандарте ISO 10303 STEP (ГОСТ Р ИСО 10303 – 1 – 99 ). Стандарт STEP регламентирует логическую структуру базы данных, номенклатуру информационных объектов, хранимых в базе данных, их связь и атрибуты. В конечном итоге интегрированное электронное описание изделия – это набор данных различного типа, получаемых в ходе проектирования известными способами, а затем преобразованных в стандартизированный вид для решения задач последующих этапов жизненного цикла изделий. Например, конструкторское электронное описание изделия в соответствии с концепцией стандарта STEP должно содержать структуру и вариант конфигурации изделия (изделие может иметь различные версии), геометрические модели и чертежи, свойства и характеристики составных частей и др.

Процесс проектирования, производства и сборки многослойных печатных плат регламентируется 220-й частью стандарта ISO 10303 STEP (ISO 1033 STEP / Part 220: process planning, manufacture and assembly of layered electronic products ), которая называется в CALS – технологиях «протоколом применения».
Части стандарта STEP, как отмечалось выше, регламентируют логическую структуру электронной базы, но не определяют вопросы взаимодействия различных CAD – систем, осуществляющих функции наполнения, распространения и физического хранения данных в процессе проектных исследований, выполняемых, например, на ранних этапах разработки изделия (эскизный проект). На указанных этапах, в соответствии с рассмотренным в первой главе маршрутом сквозного автоматизированного проектирования РЭС, с использованием известной методики моделирования физических процессов с помощью системы «АСОНИКА» необходимо выполнить набор проектных процедур средствами CAD-систем. При этом методология таких исследований должна интегрироваться с принципами CALS-технологий.
На рис.21 приведена возможная схема структурного построения интегрированной САПР для проектирования печатных узлов. При изображении схемы использовались следующие обозначения:

-наработка ПУ на отказ;

-мощности ЭРЭ;

-вероятности безотказной работы ЭРЭ;

-температурное поле НК;

-температуры ЭРЭ;

-термограммы ПУ, полученные тепловизором;

-погрешности измерительных приборов;

-виброускорение ЭРЭ на определенных частотах f. Рассмотрим приведенную схему подробней.
Основную часть САПР составляют традиционные элементы – управляющая оболочка, набор программных средств, используемых в процессе разработки печатных узлов. Отдельные программные средства взаимодействуют между собой посредством двухсторонних конверторов (К1 – Кn). При этом в составе САПР предусматривается наличие интегрированных баз данных по электрорадиоэлементам и материалам для формирования и объединения, в которых также используются конверторы (программные интерфейсы).
В процессе реализации сквозных автоматизированных маршрутов проектирования печатных узлов перед их разработчиками встают проблемы по реализации эвристических процедур, требующих разрешения противоречивых проектных ситуаций, связанных: с задачами топологического проектирования ПУ; с задачами, по обеспечению электрических, тепловых, электромагнитных, механических и надежносных характеристик ПУ; с задачами требующих совместного решения в области, как топологического проектирования, так и моделирования разнородных физических процессов, протекающих в ПУ.

Для решения указанных проблем в состав интегрированной САПР

включена экспертная система. Экспертная система, используя известные решения и/или их комбинации, а также результаты проектирования, формализованные в обменной структуре, позволяет посредством набора баз знаний выполнять ряд эвристических процедур.
В состав интегрированной САПР также входит электронный (виртуальный) макет печатного узла, на основе которого выполняется топологическое проектирование и весь комплекс модельных экспериментов средствами имитационного математического моделирования. Как показано на рис.27, электронный макет представляет собой совокупность геометрической модели, накопителей результатов моделирования, обменной структуры, а также модели обработки и средств визуализации для геометрического моделирования, результатов топологического проектирования, результатов исследований физических процессов, показателей надежности, диагностического моделирования и т.д.
После «отработки» электронного макета печатного узла, его структура и параметры конвертируются (прямая и обратная схемы) в базу данных, имеющих логическую структуру в соответствии со стандартом ISO 10303 STEP. Затем, описание ПУ может быть передано с использованием языка EXPRESS на любые этапы жизненного цикла РЭС, для которого разрабатывался ПУ.
При этом, управляющая оболочка, средствами специального программного комплекса загружает из базы данных «методики проектирования» типовую методику, ориентированную на сквозное автоматизированное проектирование разрабатываемого печатного узла.
Рассмотренная структура интегрированной САПР печатных узлов базируется на широко известных САПР для проектирования печатных плат (OrCAD-9.1, Accel и т.п.), а также на проблемных подсистемах системы “АСОНИКА”, которые позволяют исследовать различные физические процессы в РЭС на основе системных принципов.
На рис.28 представлена созданная с помощью специального комплекса планирования и управления автоматизированным проектированием «Сириус» функциональная модель фрагмента сквозного маршрута проектирования ПУ источника вторичного электропитания (ИВЭП), а на рис.29 раскрыта работа АЗЧ «Обеспечение механических характеристик печатного узла» из представленного выше фрагмента функциональной модели.

Рис.29. Пример функциональной модели спланированного с помощью программного комплекса «Сириус» фрагмента сквозного маршрута проектирования печатного узла

Рис.30. Функциональная модель: детальная модель работы А34 из рис.29
8.1.3. АВТОМАТИЗИРОВАННАЯ СИСТЕМА ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ И КАЧЕСТВА АППАРАТУРЫ «АСОНИКА»
8.1.3.1. Подсистема моделирования электрических процессов РЭС
«АСОНИКА-Э»
Подсистема «АСОНИКА-Э» разработана в соответствии с принципами объектно-ориентированного проектирования программного обеспечения и представляет собой объединение двух программных комплексов, показанных на рис.31.
Компьютерная радиолаборатория (КРЛ) "VITUS" – главный программный комплекс, функционирующий на ЭВМ IBM PC/AT, он предназначен для проектирования аналоговых радиоэлектронных схем с помощью компьютерного моделирования и наглядной визуализации его исходных данных и результатов. Большая часть процесса проектирования происходит во взаимодействии проектировщика с диалоговым интерфейсом КРЛ. В основу интерфейса положен принцип виртуальной реальности, согласно которому участвующие в диалоге объекты имитируют свои реальные прототипы, как по внешнему виду, так и по способу работы с ними. Так создаваемая с помощью встроенного графического редактора принципиальная схема проектируемого устройства уже является достаточной информацией для ее моделирования. Визуализация результатов моделирования производится посредством размещения на экране набора виртуальных измерительных приборов (осциллограф, анализатор спектра и т.д.), достаточно точно воспроизводящих свои реальные прототипы.
В результате моделирование как таковое скрыто от пользователя КРЛ, а процесс проектирования сводится к имитации макетной отработки, но не на физических, а на виртуальных объектах на экране компьютера.
База данных КРЛ "VITUS" содержит информацию о параметрах моделей биполярных и полевых транзисторов, диодов, стабилитронов, операционных усилителей, ферромагнитных сердечников и макромоделей функциональных узлов РЭС.

Благодаря наличию такой базы данных при описании элемента достаточно указать его тип, а информация о параметрах будет считана КРЛ из базы данных автоматически.
Для идентификации параметров электрических моделей в подсистеме «АСОНИКА-Э» разработан специальный виртуальный прибор, позволяющий решать эту задачу. Исходными данными для решения задачи идентификации параметров моделей являются данные, приводимые в технических условиях на элементы.

8.1.3.2. Подсистема моделирования теплоаэродинамических процессов «АСОНИКА-Т»
Подсистема «АСОНИКА-Т», структура которой показана на рис.26, состоит из следующих основных компонентов: интегрированной среды проектирования (ИСП), набора графических препроцессоров - программ графического ввода (ПГВв), математического ядра, набора графических постпроцессоров – программ графического вывода (ПГВыв), а также набора программных интерфейсов (И). Интегрированная среда позволяет: осуществлять настройку подсистемы; производить запуск проблемных программ подсистемы (ПГВв, ядра по анализу аэродинамических процессов, ядра по анализу стационарных и нестационарных тепловых процессов, ПГВыв); выполнять при помощи интерфейсов процедуры по обмену информацией с другими проблемными подсистемами системы «АСОНИКА» и другими САПРами (PCAD, ACCEL, MicroSim). Основным назначением ИСП является создание среды проектирования для конструктора РЭС.
Для взаимодействия с проблемными подсистемами системы «АСОНИКА» и другими САПРами в состав подсистемы входят программные интерфейсы (И1, И2,..., Иi), которые осуществляют обмен данными подсистемы с САПРами через файловые структуры, и головной интерфейс (ГИ). ГИ предназначен для реализации итерационных вычислительных процедур (в случае учёта взаимного влияния физических процессов) или для осуществления односторонней передачи информации из подсистемы в другие САПРы.

ПГВв подсистемы предназначены для формирования файлов формализованного описания конструкций (ФФОК) РЭС (микросборок, печатных узлов, функциональных ячеек, параметров каналов различной конфигурации, конфигураций различных систем воздушного охлаждения, узлов радиаторов, блоков и микроблоков различной конструкции). Работа ПГВв предусмотрена в двух режимах: “создание ФФОК” и “редактирование ФФОК”.

Оба режима позволяют проводить сеансы подготовки исходной информации в графическом режиме с использованием справочных файлов по геометрическим и аэро-теплофизическим параметрам (ГТФП) материалов конструкций РЭС и ЭРИ.
Математическое ядро подсистемы включает в свой состав следующие программные блоки (крейты):
·   набор блоков, позволяющих в автоматическом режиме формировать модели тепловых и аэродинамических процессов различных конструкций РЭС на основе информации, содержащейся в ФФОК и получаемой;
·   блок формирования математических моделей для анализа стационарного режима
(описывается системой нелинейных алгебраических уравнений (СНАУ)) и для анализа во временной области (описывается системой обыкновенных дифференциальных уравнений (СОДУ));
·   крейт, содержащий библиотеку аналитических моделей (набор критериальных уравнений по теплообмену и аналитических зависимостей для расчета различных гидравлических сопротивлений) для анализа различных видов теплообмена и их модификаций (в настоящее время в библиотеке около 70 разделов);
·   блок решения СОДУ и СНАУ, включающий в свой состав набор алгоритмов, в том числе алгоритмы получения функций параметрической чувствительности (ФПЧ);
·   блок анализа систем линейных алгебраических уравнений (СЛАУ), к которым сводятся на каждом шаге итерационного расчета СОДУ и СНАУ;
·   блок, реализующий вычисление ФПЧ на основе различных моделей;
·   блок формирования результатов анализа математических моделей теплоаэродинамических процессов для последующего просмотра результатов при помощи набора ПГВыв и для функционирования интерфейсов.
Кроме описанного выше автоматического формирования математической модели в подсистеме предусмотрено ручное составление пользователем топологической МТП (в виде графа теплоаэродинамической цепи) и ее вводе при помощи встроенного редактора «Редактор подсистемы «Пилот»). Это необходимо для исследования плохоформализуемых конструкций с точки зрения построения объектов. Данная ветвь в подсистеме позволяет строить МТП разной степени детализации, а также исследовать новые типы конструкций РЭС с целью дальнейшего перехода к разработке модулей автоматического формирования моделей таких конструкций.

В подсистеме «Пилот» предусмотрена возможность описывать мощности тепловыделений, теплоемкости элементов конструкции и ЭРИ, воздействующие температуры в виде различных функциональных зависимостей. Это позволяет, используя иерархический подход, моделировать тепловые режимы конструкций РЭС со сложными (с точки зрения электрической циклограммы) условиями функционирования, а также учитывать различные особенности охлаждения как отдельных узлов, так и всей конструкции в целом (имеется ввиду, например, учет траектории полета аэрокосмического объекта).
Результатом моделирования в подсистеме является информация о температурных полях и распределении воздушных потоков конструкции. Для блоков - это распределение скоростей и температур воздушных потоков внутри конструкции, а также интегральные температуры конструктивных узлов и ЭРИ, установленных внутри конструкции. Для плоских конструкций - это температурные поля несущих конструкций (печатной платы, подложек, оснований функциональных ячеек и т.д.), температуры корпусов и активных зон (p-n переходов) ЭРИ, коэффициенты тепловой нагрузки и т.д. Как отмечалось выше, пользователем могут быть также получены функции (коэффициенты) параметрической чувствительности (ФПЧ) температур к изменению параметров конструкции, что позволяет конструктору вести процесс синтеза конструкции не интуитивно, а целенаправленно. Программа вывода позволяет просмотреть температуры ЭРИ (и воздушные потоки) на плоскости платы или внутри блока в виде цветовой палитры, а также выявить перегревшиеся ЭРИ, включив режим фильтрации элементов.

В нестационарном режиме пользователь также может получить тепловые поля конструкции в каждый интересующий его момент времени в виде цветовой палитры или серии цветных графиков, отражающих зависимость температур ЭРИ или различных точек конструкции от времени. Дополнительно, в качестве выходной информации, подсистема выводит интегральные тепловые и геометрические характеристики (ИТГХ), на основе которых могут строиться иерархические расчеты. Это позволяет конструктору проводить математическое моделирование конструктивно сложных объектов РЭС, предварительно проводя их конструктивную декомпозицию на основе разработанных методик иерархического моделирования РЭС, которые входят в методическое обеспечение подсистемы.

8.1.3.3. Подсистема совместного моделирования тепловых и механических процессов «АСОНИКА–ТМ»
Автоматизированная подсистема комплексного анализа конструкций РЭС на тепловые и сложные механические воздействия «АСОНИКА-ТМ» в отличие от всех существующих программных средств по анализу механических характеристик предназначена для использования на ранних этапах проектирования конструкций радиоэлектронных средств и ориентирована на конструктора РЭС, не владеющего специальными знаниями в области математического моделирования. Она позволяет в кратчайшие сроки, используя специализированные графические интерфейсы и банк данных, осуществить ввод в ЭВМ конструкцию РЭС, содержащую тысячи ЭРИ и десятки разнообразных конструкционных материалов, что в целом позволяет повысить эффективность и качество автоматизированного проектирования, объединив опыт разработчика и вычислительные ресурсы ЭВМ.
Структура подсистемы «АСОНИКА-ТМ» представлена на рис.33. Подсистема имеет в своем составе монитор (управляющую программу), обеспечивающий связь между сервисной оболочкой и программными модулями, входящими в подсистему. Монитор дает возможность пользователю осуществить выбор задач, обеспечить программу входной информацией, организовать процесс управления программным обеспечением подсистемы.
Информационная согласованность подсистемы «АСОНИКА-ТМ» с подсистемами «Асоника-Э» и «АСОНИКА-К» достигается с помощью интерфейсов связи, задачей которых является преобразование структуры и выходных форматов одной подсистемы во входные форматы и структуру, приемлемые для другой подсистемы.
Через интерфейс связи с подсистемой «Асоника-Э» в подсистему «АСОНИКА-ТМ» передается информация о токах через элементы и узловых потенциалах для каждого функционального узла аппаратуры; затем по полученным значениям производится расчет мощностей тепловыделений на ЭРИ. Этот же интерфейс получает из подсистемы «АСОНИКА-ТМ» значения температур на РЭ и формирует входной файл для подсистемы «Асоника-Э».

Интерфейс связи тепловых и   механических   расчетов внутри подсистемы АСОНИКА-ТМ» «ИНТЕРФЕЙС-ТМ» получает значения температур участков конструкции по результатам работы программного комплекса для расчета тепловых характеристик «ТЕПЛО» и формирует входной файл для программного комплекса для расчета механических характеристик типовых конструкций РЭС при сложных воздействиях «МЕХАНИКА».
Вся информация по результатам работ подсистем «АСОНИКА-Э и «АСОНИКА-ТМ» передается в подсистему «АСОНИКА-К» с использованием соответствующих интерфейсов связи. Расчет показателей надежности РЭС проводится, таким образом, на основе моделирования физических процессов в аппаратуре. Полученные в результате моделирования электрических и тепловых процессов в РЭС токи через p-n переходы полупроводниковых приборов, функции чувствительности   выходных характеристик РЭС к изменению параметров ЭРИ и температур на ЭРИ используются в модели надежности РЭС для исследования стабильности выходных характеристик аппаратуры, а   значения коэффициентов электрической нагрузки ЭРИ, температур на ЭРИ и ускорений ЭРИ - для исследования показателей безотказности РЭС.
Реализовать последовательность проектных   процедур   при разработке устройства на печатной   плате,   включающую   этапы размещения ЭРИ на печатной плате и ее трассировку, позволяет интерфейс с САПР P-Cad и ACCEL. Данный интерфейс позволяет обработать выходные файлы указанных САПР и получить информацию о размерах печатной платы и ее топологии. Далее, полученные данные (размеры печатной платы, координаты установки ЭРИ и их
ориентация) поступают в подсистему «АСОНИКА-ТМ». Таким образом, конструктору не требуется заново описывать конструкцию печатной платы, спроектированной в системе PCad, при расчете   тепловых и механических характеристик.
Подсистема «АСОНИКА-ТМ» имеет в своем составе комплекс программ подготовки   исходных   данных   (КППД),    предназначенных    для графического ввода информации, а также комплекс по отображению результатов расчета (КПОР) тепловых и механических характеристик конструкции РЭС.

Сценарии диалога и систем меню, реализованные в этих программных средствах, используют терминологию той предметной области, в которой проводятся исследования с помощью подсистемы. Результаты расчетов оформляются в виде таблиц   и   графиков. Предусмотрена также печать карт рабочих режимов ЭРИ исследуемой аппаратуры.
В состав подсистемы входят также программа исследования разбросов выходных характеристик РЭС при заданных   разбросах параметров «РАЗБРОС», программа оптимизации параметров конструкции РЭС с целью снижения массы «ОПТИМУМ» (реализует метод Нелдера-Мида и метод золотого сечения), программа идентификации теплофизических и физико-механических параметров макромоделей типовых конструкций РЭС «ИДЕНТИФИКАЦИЯ».
Для подсистемы «АСОНИКА-ТМ» реализована локальная база данных (БД), содержащая геометрические, теплофизические и физико-механические параметры ЭРИ и конструкционных материалов, необходимые для расчета тепловых и механических характеристик, которая, в свою очередь является общей с подсистемой «АСОНИКА–Т».
В состав подсистемы «АСОНИКА-ТМ» входят как программы-препроцессоры для автоматического синтеза моделей механических процессов шкафов, стоек, блоков, печатных узлов (ПУ), ЭРИ, так и программы расчета типовых конструкций РЭС при сложных механических воздействиях с учетом температуры. При этом предусмотрен расчет шкафов, стоек и блоков, установленных на виброизоляторах. Для расчета ПУ в подсистеме предусмотрены две программы - программа на основе метода конечных разностей и программа на основе аналитических методов. Последняя позволяет значительно сократить машинное время для расчета ПУ с равномерным расположением ЭРИ по печатной плате.
Выходные данные по анализу механических характеристик представлены в виде графиков и таблиц и имеют следующую структуру:
1. При гармонической вибрации: зависимость виброускорения от частоты в контрольной точке конструкции шкафа, стойки, блока, ПУ; амплитуды виброускорений, виброперемещений и механических напряжений участков конструкции шкафа, стойки, блока, ПУ на резонансных частотах; амплитуды виброускорений и коэффициенты   механической нагрузки ЭРИ; резонансные частоты ЭРИ; максимальные амплитуды механических напряжений в выводах ЭРИ; минимальное время до усталостного разрушения выводов ЭРИ.

2. При случайной вибрации: зависимость спектральной плотности виброускорения от частоты в контрольной точке конструкции шкафа, стойки, блока, ПУ; среднеквадратические значения виброускорений, виброперемещений и механических напряжений участков конструкции шкафа, стойки, блока, ПУ; среднеквадратические значения виброускорений и коэффициенты механической нагрузки ЭРИ; резонансные частоты ЭРИ; среднеквадратические значения механических напряжений в выводах ЭРИ; время до усталостного разрушения выводов ЭРИ.
3. При ударном воздействии: зависимость ударного ускорения от времени в контрольной точке конструкции шкафа, стойки, блока, ПУ; максимальные ускорения, перемещения и механические напряжения участков конструкции шкафа, стойки, блока, ПУ; максимальные ускорения и коэффициенты механической нагрузки ЭРИ.
4. При линейном ускорении: зависимость ускорения от времени в контрольной точке конструкции шкафа, стойки, блока, ПУ; максимальные ускорения, перемещения и механические напряжения участков конструкции шкафа, стойки, блока, ПУ; максимальные ускорения и коэффициенты механической нагрузки ЭРИ.
5. При воздействии акустического шума: зависимость спектральной плотности ускорения от частоты в контрольной точке конструкции шкафа, стойки, блока, ПУ; среднеквадратические значения ускорений, перемещений и механических напряжений участков конструкции шкафа, стойки, блока, ПУ; среднеквадратические значения ускорений и коэффициенты механической

нагрузки ЭРИ; резонансные частоты ЭРИ; среднеквадратические значения механических напряжений в выводах ЭРИ; время до усталостного разрушения выводов ЭРИ.
6. При сложном механическом воздействии всех факторов:
- для детерминированного сложного воздействия:
1)     зависимость ускорения от времени в контрольной точке конструкции шкафа, стойки, блока, ПУ;
2)     максимальные ускорения, перемещения и механические напряжения участков конструкции шкафа, стойки, блока, ПУ;

3)     максимальные ускорения и коэффициенты механической нагрузки РЭ; резонансные частоты ЭРИ;
4)     максимальные амплитуды механических напряжений в выводах ЭРИ; минимальное время до усталостного разрушения выводов ЭРИ;
- для случайного сложного воздействия:
1)среднеквадратические значения ускорений, перемещений и механических напряжений участков конструкции шкафа, стойки, блока, ПУ;
2)среднеквадратические значения ускорений и коэффициенты механической нагрузки ЭРИ;
3)резонансные частоты ЭРИ;
4)среднеквадратические значения механических напряжений в выводах ЭРИ;
5)время до усталостного разрушения выводов ЭРИ.
Большинство физико-механических параметров макромоделей конструкций РЭС могут быть получены только путем идентификации. В подсистеме может быть проведена идентификация параметров макромоделей типовых конструкций РЭС, позволяющая в определенной последовательности получить упругие и демпфирующие характеристики материалов конструкций в зависимости от температуры, а также коэффициенты жесткости креплений ПУ и дополнительные цилиндрические жесткости, вносимые ЭРИ в плоские конструкции, в зависимости от варианта установки ЭРИ, материала клея, площади корпуса ЭРИ, высоты и соотношения размеров корпуса. По результатам идентификации и обработки результатов в базу данных заносятся коэффициенты соответствующих полиномиальных зависимостей для определения перечисленных выше параметров.
В связи с необходимостью исследования усталостных процессов в подсистеме имеется возможность определения параметров кривой усталости для выводов ЭРИ, позволяющая получить зависимости напряжений в выводах ЭРИ от числа циклов до разрушения при различных вариантах установки ЭРИ, материалах выводов, геометрических размерах. Полученные значения параметров кривых усталости записываются в базу данных.
8.1.3.4. Подсистема комплексного анализа и обеспечения показателей надежности и качества «АСОНИКА-К»
Монитор подсистемы «АСОНИКА-К», состав которой показан на рис.34, предназначен для координированного взаимодействия ее основных частей: модуля ввода, расчетного модуля, модуля сопровождения базы данных, модуля вывода и сервисного модуля.

Модуль ввода предназначен для ввода исходной информации для расчетов показателей надежности и качества РЭС. Для ввода информации из технического задания (условия эксплуатации, требования по надежности, стабильности и др.) и описания структуры РЭС используется интерфейс пользователя. Необходимые для расчетов параметры вероятностных моделей ЭРИ вводятся из справочной части базы данных (СЧБД) с помощью интерфейса СЧБД, а результаты расчетов электрических, тепловых и механических характеристик вводятся из проектной части базы данных (ПЧБД) с помощью интерфейса ПЧБД. В случае необходимости проведения повторных расчетов ранее исследованных РЭС, исходная информация для расчетов может быть введена из архивной части базы данных (АЧБД) с помощью интерфейса АЧБД.
Расчетный модуль является основной частью подсистемы «АСОНИКА-К», в которой непосредственно осуществляется расчет показателей надежности и качества РЭС по математическим моделям. Для расчета показателей безотказности РЭС по постепенным отказам и показателей точности и стабильности служат модуль моделирования случайных процессов, в состав которого входят модули, реализующие метод моментов и метод статистических испытаний. В библиотеке моделей ЭРИ содержатся квазидетерминированные функции, описывающие зависимости параметров ЭРИ от возмущающих факторов. Для расчета показателей безотказности РЭС по внезапным отказам, служит модуль моделирования случайных величин, в состав которого входит библиотека математических моделей

, в которой содержатся аналитические выражения для расчета эксплуатационной интенсивности отказов ЭРИ, библиотека моделей резервирования, в которой содержатся аналитические выражения для расчета различных структур резервирования РЭС и их составных частей (нагруженный резерв, ненагруженный резерв и т.д.) и библиотека моделей надежности, в которые содержатся функции распределения, используемые при расчетах (экспоненциальное распределение, распределение Вейбулла-Гнеденко, DN-распределение и др.).
Модуль сопровождения базы данных - вторая по важности часть, которая реализует информационную поддержку подсистемы.

Модуль ориентирован на администратора базы данных подсистемы. База данных подсистемы была реализована в среде Borland Paradox 5.0 и представляет собой систему таблиц, связь между которыми осуществляется при помощи SQL-операторов и состоит из трех составных частей. СЧБД содержит информацию о вероятностных моделях ЭРИ (значения составляющих математических моделей эксплуатационной интенсивности отказов ЭРИ, параметров кусочно-линейных квазидетерминированных функций и др.) для различных классов ЭРИ.
ПЧБД содержит информацию об электрических, тепловых и механических режимах работы ЭРИ, значения функций чувствительности выходных характеристик РЭС к изменению внутренних параметров элементов и расчетные значения выходных характеристик РЭС, а АЧБД содержит исходные данные и результаты расчетов показателей надежности и качества ранее исследованных РЭС. Модуль позволяет осуществлять редактирование данных, просмотр данных и тестирование данных. Кроме того, в состав модуля входит интерфейс связи с проблемными подсистемами системы АСОНИКА, с помощью которого в ПЧБД заносится информация о результатах тепловых, механических и электрических расчетов схем и конструкций РЭС, необходимая для комплексного моделирования случайных процессов. Модули идентификации параметров вероятностных моделей и идентификация параметров моделей надежности необходимы для расчета параметров моделей ЭРИ по их справочным данным. Модуль вывода предназначен для вывода и интерпретации результатов расчетов показателей надежности и качества РЭС, а именно вероятности безотказной работы, среднего времени наработки до отказа, допусков на выходные характеристики и их составляющих, характеризующих степень влияния возмущающих факторов элементов и их параметров на общий уровень этих показателей. Для вывода этой информации используется интерфейс ПЧБД. В случае необходимости просмотра результатов расчетов ранее исследованных РЭС, необходимая информация для расчетов может быть выведена из АЧБД с помощью интерфейса АЧБД.

Модуль анализа результатов позволяет выбрать из библиотеки типовых рекомендаций те, которые являются наиболее эффективными с точки зрения повышения надежности в данном конкретном случае.
Сервисный модуль содержит в своем составе развитую систему подсказок и файлов помощи. Кроме того, к сервису относится презентация подсистемы, представляющая собой демонстрацию применения подсистемы на примере исследования показателей надежности и качества источника вторичного электропитания. Модуль обучения содержит программную документацию на подсистему и описание математических моделей и методов их решения.
Методическое обеспечение подсистемы «АСОНИКА-К» (см. рис.35) позволяет решать задачи широкий круг задач по обеспечению показателей надежности и качества РЭС.

8.1.3.5. Подсистема диагностического моделирования «АСОНИКА-Д»
Подсистема разработана в соответствии с принципами системного подхода и с учетом принципов вложенности, заменяемости и открытости. В основе программного обеспечения подсистемы лежат методы, модели и алгоритмы диагностического моделирования, которые образуют целостную методологию диагностического обеспечения РЭС на всем протяжении их жизненного цикла.
Это позволяет снизить информационные напряжения, возрастающие к завершающим этапам стадии производства и особенно усиливающиеся во время эксплуатации при вынужденных ремонтно-восстановительных работах, что в целом способствует снижению временных и материальных затрат и повышению надежности, качества и эффективности использования РЭС на протяжении жизненного цикла от исследований и формирования ТЗ и вплоть до утилизации.
Таким образом, подсистема направлена на реализацию главных принципов организации жизненного цикла: 1) принципа непрерывности информационной среды, куда погружается РЭС на протяжении жизненного цикла и 2) принципа регулярности информационной среды для исключения информационных выбросов, связанных с необходимостью переформатирования информации от этапа к этапу.

Схема организации подсистемы «АСОНИКА-Д» представлена на рис.36, а её полная структурная схема – на рис.37.
На основе анализа требований к программному обеспечению и в соответствии с правилами структурного программирования подсистема организована в виде отдельных комплексов, которые работают как совместно, реализуя свойства эмерджентности системы, так и независимо, решая частные задачи диагностирования технического состояния РЭС.
Сами программные комплексы построены по модульно-крейтовому принципу. Структурное разбиение комплексов на ряд функциональных крейтов выполнено в соответствие с основными задачами, которые решаются программными комплексами и подсистемой в процессе ее функционирования с целью обеспечения диагностируемости РЭС на стадии проектирования или оперативного диагностиирования РЭС в процессе их производства и эксплуатации.
Приведенное разбиение подсистемы «АСОНИКА-Д» на программные комплексы, а комплексов на крейты и модули выполнено также с учетом принципов взаимозаменяемости, вложенности и перекрытия отдельных крейтов и модулей.
Каждый крейт представляет собой набор программных модулей, объединенных с точки зрения функционального назначения. Программные модули решают частные задачи по реализации отдельных методов и вычислительных процедур.
Модульно-крейтовая структура комплексов и подсистемы позволяет дополнять подсистему другими модулями и крейтами, расширяющими ее функциональные возможности, а также достичь эффекта экономии ресурсов ЭВМ за счет перекрытия крейтов и модулей внутри крейтов.
При разработке подсистемы реализована возможность ее функционирования как в автономном режиме (при решении задач оперативного диагностирования), так и в составе интегрированных САПР (при обеспечении диагностируемости РЭС) совместно с программами анализа схем PSpice и топологического проектирования P-CAD, ACCEL и прежде всего совместно с подсистемами системы «АСОНИКА», для чего предусмотрены соответствующие программы-интерфейсы.
Программы-интерфейсы осуществляют обмен данными подсистемы «АСОНИКА-Д» с управляющей программой системы «АСОНИКА» и с другими САПРами через файловые структуры.

Математическое ядро подсистемы рассредоточено по программным модулям комплексов. А такие блоки, как блок решения систем интегродифференциальных систем нелинейных уравнений, по мере необходимости привлекаются из подсистем электрического и тепломеханического моделирования.
В основе программного комплекса диагностирования РЭС по электрическим характеристикам положены методы решения систем линейных уравнений и анализа их совместности, градиентный метод Давидона-Флетчера-Пауэла многопараметрической оптимизации, метод квадратической интерполяции.
Экспертный диагностический комплекс реализован на основе аппарата теории нечетких множеств и качественных описаний.
Математическим ядром комплекса диагностирования по тепловым характеристикам является теория распознавания образцов, теория оптимальной фильтрации, теория инфракрасного тепловидения и метод статистических испытаний Монте-Карло для формирования отбраковочных допусков на тепловые режимы элементов.
Для выбора значимых параметров диагностирования РЭС в соответствующем программном комплексе подсистемы рассчитываются коэффициенты значимости внутренних параметров элементов. Исходными данными для расчетов являются функции чувствительности и технологические допуски, импортируемые через интерфейс из подсистемы АСОНИКА и коэффициенты отказов элементов. Последние определяются на основе вероятностей отказов элементов, экспортируемых подсистемой «АСОНИКА-К».
В основе комплекса программ формирования отбраковочных допусков лежит метод композиции первых и вторых моментов распределений отклонений внутренних электрических параметров, обусловленных случайным процессом старения элементов и случайным дрейфом параметров, вследствие влияния температурного фактора.
Подсистема «АСОНИКА-Д» имеет связь с тепловизионной системой для контроля и диагностирования РЭС по его температурному полю. Рассчитанная с помощью подсистемы «АСОНИКА–Д» тепловая модель РЭС, включающая в себя результаты расчета температуры по элементам, а также пределы изменения температуры бездефектных образцов РЭС, составляет его тепловую модель-норму, отклонения относительно которой рассматривают как дефекты разного рода.

Затем проводится анализ температурного поля исследуемой группы РЭС. Тепловое излучение от контролируемого образца РЭС регистрируется тепловизионной камерой и через интерфейс связи с компьютером происходит формирование измеренной термограммы. Термограммы могут быть подвергнуты обширной обработке с целью подчеркивания контраста, выделения деталей или изотермических зон, увеличения масштаба деталей, удаления температурного фона, получения разностных отклонений в симметричных точках объекта, построения термопрофиля и выполнения других операций, улучшающих качество и информативность термограммы. Измеренное температурное поле РЭС сравнивается с температурным полем модели-нормы с учетом температурных допусков, и по результатам сравнения принимается решение о наличии или отсутствии дефекта.
Взаимодействие программных комплексов в рамках подсистемы «АСОНИКА-Д» позволяет решать следующие задачи:обоснованно выбрать множество значимых диагностируемых параметров; обеспечить безусловную диагностируемость РЭС относительно выбранных параметров на стадии проектирования, начиная с самых ранних этапов; обоснованно назначить множество информативных контрольных точек, достаточное для обеспечения наблюдаемости схемы РЭС относительно выбранных параметров; выбрать необходимое для обеспечения управляемости схемы РЭС множество тестовых воздействий, инжектируемых на входы РЭС; автоматически формировать границы отбраковочных допусков на параметры элементов, адаптивных к изменениям температур элементов и к сроку службы РЭС; программно и аппаратно сопрягаться с контрольно-измерительной аппаратурой и ИК-тепловизионной камерой; провести оперативное диагностирование технического состояния РЭС на предмет выявления причин данного состояния до уровня заменяемого элемента как при производстве, так и при эксплуатации.
Результаты решений всех перечисленных задач подсистема загружает в базу данных, и, посредством программного крейта интерпретации, результаты обеспечения диагностируемости и результаты диагностирования выводятся через соответствующий графический постпроцессор на экран ЭВМ, а создаваемый протокол выводится на печать.

8.1.3.6. Подсистема макромоделирования разнородных
физических процессов «Пилот»
Подсистема «Пилот» предназначена для поискового проектирования РЭС с использованием принципов макромоделирования электрических, тепловых, аэродинамических и механических процессов в РЭС, а также для изучения вопросов комплексного математического моделирования физических процессов в РЭС. Последняя функция необходима для подготовки специалистов и инженерно-технических работников системным принципам проектирования РЭС и вопросам математического моделирования разнородных физических процессов в РЭС.
Структурная схема подсистемы «Пилот» приведена на рис.38. Важное место в структуре подсистемы занимает графический редактор. Он выполняет две функции. Во-первых, редактор представляет собой управляющую оболочку для работы различных программных крейтов, реализующих такие функции как расчет, обработка запросов к специализированной базе данных и базе данных системы «АОНИКА», вывод на экран или на печать различной информации, связанной с проведением сеансов моделирования. Во-вторых, редактор предназначен для создания графических топологических моделей различных физических процессов: электрических, тепловых, механических и аэродинамических. В процессе функционирования графический редактор формирует действующую расчётную структуру в топологическом виде, которая в дальнейшем анализируется при помощи единого расчетного модуля в различных режимах (статический анализ, анализ во временной и частотной областях, анализ чувствительности). В процессе моделирования возможно применение принципа динамического изменения параметров элемента схемы или параметра конструкции (тюнинг в реальном масштабе времени).

При таком подходе параметр маркируется и изменяется при помощи виртуального тюнера. Процесс изменения параметра сопровождается одновременным отображением результатов анализа в виде графиков и диаграмм. При таком подходе процесс анализа математической модели выполняется в фоновом (скрытом) режиме.
Информационное обеспечение подсистемы «Пилот» включает в свой состав: собственную базу данных с моделями различных схемотехнических и конструктивных решений, применяемых при проектировании РЭС, интерфейсные модули работы с базой данных системы “АСОНИКА”, различные файлы помощи, электронный учебник; системы «жесткого» и «мягкого» контроля знаний; а также рекламное обеспечение подсистемы «Пилот», состоящее из презентации и WEB–страницы.
Процесс комплексного моделирования физических процессов в РЭС при помощи подсистемы «Пилот» осуществляется средствами системного планировщика системы «АСОНИКА». Планировщик формирует план сеанса моделирования, устанавливая в графическом режиме моделей, виды связей между моделями (передаваемые потоки данных) и последовательность анализа моделей, включая итеративные проектные циклы.
8.1.3.7. Управляющий комплекс системы «АСОНИКА»

Описанные в предыдущих параграфах проблемные подсистемы системы «АСОНИКА» объединены в систему средствами специального управляющего программного комплекса. Комплекс представляет собой электронную предметную область, ориентированную на проектирование РЭС средствами математического моделирования. Комплекс включает в свой состав следующие основные компоненты:
1. «Системный планировщик». Данная программная единица выполняет функции структурирования процесса автоматизированного проектирования РЭС на основе математического моделирования. Планировщик также формирует различные схемы комплексного исследования характеристик РЭС с использованием различных математических моделей. Кроме этого он позволяет с использованием IDЕF-идеологии поддерживаемой международными стандартами CALS-технологий строить маршруты и программы управления качеством проектных предприятий радиотехнического профиля.

Пример работы системного планировщика приведен на рис.39.

Рис.38. Структурная схема подсистемы «Пилот»

2. «Информационная модель РЭС». Данный крейт позволяет создавать и редактировать информационную модель РЭС. Программа использует набор маркируемых списков (требования ТЗ, словарь проектирования, параметры дестабилизирующих факторов /ДФ/, диаграмма сочетаний ДФ, морфологические матрицы, результаты моделирования, множество допустимых проектных решений /ДПР/); графическое отображение информации (например, при описании: множества допустимых схемотехнических и конструктивно-технологических решений, диаграммы сочетаний ДФ, архива проектов, обобщенной схемы иерархического описание РЭС); операторную форму записи алгоритмов (множество методик АП РЭС). При этом все основные информационные структуры модели автоматически записываются в базу данных системы “АСОНИКА”.
3. «Проблемные подсистемы и другие САПР». Набор программных средств данного раздела выполняет запуск проблемных подсистем системы «АСОНИКА», а также других САПР (MicroSim) в соответствии с план-графиком, сформированным в системном планировщике в рамках реализации той или иной методики проектирования. Методики хранятся и редактируются, програмным блоком «База маршрутов и методик проектирования».
4. «Экспертная система». Данная система выполняет определенное множество эвристических функций присутствующих в алгоритмах методик автоматизированного проектирования РЭС. К таким функциям, например, относятся операции по обработке матриц чувствительности при выборе управляющих параметров; операции по принятию решений, основанных на анализе результатов моделирования; операция «внесение изменений в проект» и др.
5. «Графический компоновщик». Данная программная компонента осуществляет: формирование функциональной схемы РЭС; формирование структурного построения РЭС (графическое формирование конструкции на всех уровнях конструктивной иерархии, описание параметров конструкции для дальнейшего моделирования различных физических процессов в ней, автоматическое (под управлением экспертной системы или интерактивное формирование схемы отображения (упаковки) множества функциональных элементов на множестве типовых конструктивных узлов и элементов).

Применение редактора- компоновщика ориентировано на особенности структурного построения современных РЭС, которые, как правило, строятся по функционально узловому и модульному принципам.
6. «Среда проектирования «Печатный узел». Данная среда по иерархическому признаку является подсистемой, описываемого управляющего комплекса и ориентируется на автоматизированное проектирование составляющих узлов РЭС низших уровней иерархии, но при этом обладает собственным технологическим циклом проектирования, который позволяет в автономном режиме, используя принципы восходящего проектирования, выполнять взаимосвязанные проектные процедуры по разработке отдельных узлов, а в ряде случаев, и РЭС в целом (например, одноканальные с простой функциональной и конструктивной иерархиями источник вторичного электропитания).
7. “Блок сопряжения данных со стандартными CALS-технологиями». Данный крейт представляе6т собой набор конверторов по преобразованию результатов моделирования в линейку стандартов ISO поддерживаемых CALS-технологиями, а именно разделы стандарта ISO-1033.
Данное структурное построение системы «АСОНИКА» позволяет говорить о предпосылках реализации на ее базе определенных циклов проектирования CALS-технологий по разработке радиоэлектронных средств. Примеры функционирования управляющего комплекса приведены на рис.40 - 44.

Рис.39. Внешний вид программы «Планировщик» системы «АСОНИКА»

Рис.40. Общий вид интерфейса управляющего комплекса системы «АСОНИКА»

Рис.41. Работа с информационной моделью объекта в управляющем комплексе системы «АСОНИКА» (описаны диаграммы сочетаний дестабилизирующих факторов аэрокосмических РЭС)

Рис.42. Процесс формирования электронного образца РЭС (функция искажения функциональной системы на множестве конструктивов)

Рис.43. Процесс виртуальной компоновки конструкции РЭС (функция иерархического описания)

8.1.4. Распечатка электронного описания АСУ

Электронное описание блока АСУ/4 выполнено с помощью программы R-House. Структура данных приведена на рис.45.

Электронное описание представляет собой древовидную структуру. Вершины дерева связаны с различными приложениями, с помощью которых выполнялось электронное описание устройства (обычно это тексты, таблицы, растровые и векторные изображения). Далее описаны данные, связанные с вершинами древовидной структуры, представленной на рис.45.
Рис.46. Чертёж конструкции блока АСУ/4 выполненный в программе AutoCAD

Рис.47. Чертёж ПУ МРК-4 выполненный в программе AutoCAD
Вершина «Блок АСУ/4» связана с чертежом конструкции блока АСУ/4 выполненном в программе AutoCAD. Этот чертёж приведён на рис.40.

Подчинёнными этой вершине являются описания печатных узлов (ПУ), входящих в состав блока АСУ/4.
Вершине «Печатный узел МРК-4» соответствует чертёж ПУ МРК-4 выполненный в программе AutoCAD. Он приведён на рис.41.
Печатный узел в свою очередь включает в себя вершины «Схема» и «Характеристики, полученные в результате проектирования». Принципиальная электрическая схема реализуется с помощью системы OrCAD (рис.42).

Подчинёнными вершинами по отношению к вершине «Схема» являются «Сборочный чертёж», оформляемый в системе P-CAD (рис.49) и «Спецификация», выполненная в редакторе Microsoft Word (рис.50). Для каждого электрорадиоэлемента из спецификации есть возможность просмотра параметров и изображения (рис.51)
«Характеристики, полученные в результате проектирования» делятся на «Трассировку», выполняемую в системе P-CAD (рис.52), «Результаты расчёта тепловых характеристик», «Результаты расчёта механических характеристик» и «Результаты расчёта электрических характеристик».

а)
б) в)
Рис.49. Сборочный чертёж ПУ МРК-4 выполненный в системе РСАD а) Общий вид ПУ МРК-4, б) фрагмент сборочного чертежа ПУ МРК-4, в) схема размещения электрорадиоэлементов на плоскости ПУ МРК-4

«Результаты расчёта тепловых характеристик» делятся на «Изотермы» (рис.53), «Температуры ЭРЭ» (рис.54) и «Карта тепловых режимов работы» (рис.55) получаемые в результате расчёта с помощью системы АСОНИКА.

« Результаты расчёта механических характеристик» делится на «Карту механических режимов» (рис.56) и «Распределение виброускорений» (рис.57) так же получаемые в системе АСОНИКА.

«Результаты расчёта электрических характеристик» содержат выходные характеристики полученные с помощью моделирования в системе OrCAD (рис.58).

Содержание раздела