ГОСТ Р 57321.2-2018. Национальный стандарт Российской Федерации. Менеджмент знаний. Менеджмент знаний в области инжиниринга. Часть 2. Проектирование на основе баз знаний

(утв. и введен в действие Приказом Росстандарта от 23.08.2018 № 518-ст)

от 23 августа 2018 г. № 518-ст

ГОСТ Р 57321.2-2018

ОКС 03.100.99

1 июня 2019 года

Предисловие

1 РАЗРАБОТАН ООО «НИИ экономики связи и информатики „Интерэкомс“ (ООО „НИИ „Интерэкомс“)»

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 23 августа 2018 г. № 518-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений руководства VDI 5610-2:2017 «Менеджмент знаний в области инжиниринга. Проектирование на основе баз знаний» [VDI 5610-2:2017 «Knowledge management for engineering. Knowledge-based engineering (KBE)», NEQ]

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

Понятие «проектирование на основе баз знаний» [KBE-проектирование] (knowledge-based engineering, KBE) связано с эффективными методами и программными средствами, предназначенными для их использования инженерами-конструкторами. При этом термин «KBE-проектирование» также относится к использованию систем обработки знаний при разработке продукции.

Несмотря на то что начиная с 80-х годов прошлого века в области KBE-проектирования проводилось множество исследований и выработаны различные подходы, до настоящего момента отсутствует единое и универсальное описание промышленной среды, с помощью которой можно реализовывать и использовать KBE-приложения. В том виде, как они публикуются в настоящее время, конкретные решения, реализованные отдельными компаниями, могут применяться для других прикладных задач только со значительными изменениями и финансовыми затратами.

1 Область применения

Настоящий стандарт определяет универсальную процедуру реализации KBE-приложений и предназначен для руководителей и сотрудников отделов проектирования и/или разработки, специалистов по проектированию и сбыту производственного оборудования, а также для студентов, обучающихся инженерным специальностям. Также он будет полезен тем, кто интересуется должностными обязанностями инженеров по знаниям (инженеров по технике представления и использования знаний).

Во избежание совершения базовых ошибок при использовании KBE-приложения пользователи должны иметь возможность получать применимые к конкретному приложению рекомендации, примеры и принципы, основанные на достоверных знаниях. Реализацию KBE-приложений рассматривают как комбинацию теории и практики проектного управления в соответствии с общими принципами KBE-проектирования. В частности, для KBE-контента настоящий стандарт обеспечивает базовую основу, которую следует рассматривать как расширение ГОСТ Р 57321.1.

Настоящий стандарт также содержит положения, устанавливающие:

• что такое KBE-проектирование, в каких областях его можно применять (или не применять) и в чем его цель?
• какие группы сотрудников компании должны участвовать в KBE-проектах и их роли?
• какие существуют типы KBE-приложений, как правильно выбрать соответствующее KBE-приложение для решения соответствующей проблемы и каким будет вводный сценарий для этого решения?
• какие IT-средства необходимы, какие условия должны быть созданы в компании и какие ресурсы должны быть предоставлены?
• каким образом можно оценивать преимущества использования KBE-приложений и эффективность затрат на их разработку [оценка по принципу соответствия затрат полученным результатам (выгодам)]?

Таким образом, настоящий стандарт содержит краткий обзор по тематике KBE-проектирования с пояснениями основных этапов работ и элементов, необходимых для разработки и эксплуатации KBE-приложений.

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

ГОСТ Р 57321.1-2016 Менеджмент знаний. Менеджмент знаний в области инжиниринга. Часть 1. Общие положения, принципы и понятия

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

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

Примечание 1 — В соответствующей литературе приведены подробные определения таких терминов, как «данные», «информация» и «знания».

Примечание 2 — Для облегчения понимания терминов и определений они пояснены с помощью приведенного ниже примера (CAD-компонента или сборочного узла). Базы данных помечаются знаками, содержащими цифры, буквы и символы («3», «0», «m», «m», «w», «d»).

3.1 данные (data): Объективные факты, которые не могут интерпретироваться вне контекста и без дальнейших пояснений.

Пример - «30» — это значение, «mm» — это размерность, «wd» — это геометрический параметр.

3.2 информация (information): Структурированные данные, обладающие актуальностью и целями, которые могут быть вписаны в контекст (семантически контекстуализированы), классифицированы, оценены и откорректированы.

Пример - Диаметр вала составляет 30 мм.

3.3 знание (knowledge): Связанная информация, которая позволяет проводить сравнение, определять степень взаимодействия и принимать решения.

Пример - Объединение в сети различной информации, например значений характеристик материала (в частности, материалов вала, ступицы, призматической шпонки), ограничивающих условий (например, передаваемого крутящего момента, типа и максимального числа призматических шпонок) и геометрических размеров (таких как диаметр вала, длина его заплечика), позволяет получать достоверные знания и, как правило, давать заключение относительно совместимого с нагрузкой исполнения соединения вала с призматической шпонкой:

I_{tr} = \frac{2M_{t} \cdot K_{A}}{D_{W} \cdot (h - t_{1}) \cdot p} .

Примечание — В настоящем стандарте идет речь о формализованных и неформализованных знаниях. Формализованные знания можно обрабатывать непосредственно в информационной системе, что невозможно при обработке неформализованных знаний. Переход от неформализованных знаний к формализованным частично описан в 6.3.2.

4 Возможности и риски KBE-проектирования

Внедрение в компаниях KBE-приложений позволяет решать задачи различной сложности и направленности. Разработчики, успешно внедрившие KBE-приложения в своих компаниях, как правило, выделяют следующие цели и приоритетные направления:

• стандартизация;
• автоматизация;
• обеспечение и повышение качества;
• обеспечение «прозрачности» (информационной открытости);
• повышение степени удовлетворенности заказчиков;
• повышение степени удовлетворенности сотрудников компании.

Указанные выше аспекты представляют собой лишь часть задач, которые следует рассматривать как причинно-следственные, а не частично изолированные друг от друга.

4.1 Стандартизация

Помимо других факторов внедрение KBE-приложений требует предварительного анализа номенклатуры продукции и процессов с точки зрения их пригодности, что позволяет на ранней стадии определять потенциал стандартизации. Для ускорения процессов разработки, производства и сборки стандартизация обеспечивает возможность повторного использования уже существующих подузлов/подсборок и отдельных деталей. Внутреннюю систему и структуру данных компании (с точки зрения аппаратного и программного обеспечения) необходимо стандартизировать с целью дальнейшего снижения производственных затрат, что может быть осуществлено путем слияния различных систем и баз данных в единую систему управления данными об изделии (PDM-систему), стандартизации разнородного программного обеспечения или применения локальной сети компании с центральными серверами.

4.2 Автоматизация

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

4.3 Обеспечение и повышение качества

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

4.4 Обеспечение «прозрачности» (информационной открытости)

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

4.5 Повышение степени удовлетворенности заказчиков

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

4.6 Повышение степени удовлетворенности сотрудников компании

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

5 Принципы KBE-проектирования

В последующих разделах настоящего стандарта следует четко различать два термина, а именно — термины «проектирование» и «конфигурирование».

Термин «проектирование» предназначен для четкого описания всех этапов работы и представления технических объектов (например, отдельных компонентов, подсборок, систем), которые существуют в сознании проектировщика.

Термин «конфигурирование», который часто также эквивалентен термину «конфигурирование изделия», в первую очередь предназначен для описания составных частей этого изделия с использованием стандартизованных компонентов и проверенных правил конфигурирования.

5.1 Структурирование знаний

В литературе можно встретить множество разнообразных терминов, определений и представлений терминов, относящихся к знаниям, таких как «структурные типы», «классификация» и т.п.

В настоящем стандарте использован принцип дифференциации знаний. Знания необходимо описывать с помощью следующих пяти структурных параметров:

• тип знаний (knowledge type). Данный параметр характеризует техническую/тематическую область знаний, т.е. область технических знаний, знания о продукции (изделии), методологию использования знаний и т.п.;
• характер знаний (knowledge characteristic). Данный параметр описывает характерные свойства знаний (неявные, явные, индивидуальные, коллективные, внутренние, внешние и т.п.), которые отнесены к определенному типу знаний;
• форма знаний (knowledge form). Данный параметр характеризует форму представления знаний, т.е. в виде текста, формулы, рисунка, правила и т.п.;
• локализация знаний (knowledge location). Данный параметр характеризует место получения (источник) знаний — отдельный специалист, база данных, подразделение компании и т.п.;
• качество знаний (knowledge quality). Данный параметр служит для оценки наличия в компании доступных знаний с качеством, необходимым и достаточным для реализации соответствующих бизнес-процессов. При этом предполагается, что повышение качества знаний будет способствовать успешному выпуску продукции.

Качество знаний можно оценивать с помощью следующих критериев:

• точность;
• прослеживаемость (возможность оперативного контроля);
• полнота;
• полезность;
• достоверность.

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

5.2 Сбор и представление знаний

Процедура сбора и представления знаний предназначена для процесса формализации знаний (определения области применения и решения проблем), получаемых из различных источников, т.е. для перевода знаний в явную форму. Этот процесс разбивают на этапы «сбор знаний» и «интерпретация знаний», первый из которых включает их анализ и структурирование. За общим процессом сбора и представления знаний следует процесс их реализации и внедрения (см. 6.3.3):

• этап «сбор знаний» (см. 5.2.1) служит для извлечения и сбора знаний из различных источников знаний, например от специалистов-экспертов, из литературных источников и электронной документации;
• этап «интерпретация знаний» служит для анализа и структурирования собранных знаний, а также для их перевода в универсальную формальную модель процесса решения конкретных проблем в соответствующих KBE-приложениях. Знания могут быть выражены в различных представлениях (см. 5.2.2).

5.2.1 Типы процедуры сбора и представления знаний

В общем случае можно выделить три основных типа процедуры сбора и представления знаний:

• непрямой сбор/представление знаний;
• прямой сбор/представление знаний;
• автоматический сбор/представление знаний.

5.2.1.1 Непрямой сбор/представление знаний

Процесс непрямого сбора/представления знаний основан на диалоге между экспертом и специалистом по методам представления/использования знаний (инженером по знаниям), который предназначен для идентификации, сбора, анализа и структурирования знаний интервьюируемого эксперта. Предпосылкой для получения такого рода знаний является знакомство специалиста с областью знаний эксперта, так как он должен выявить особенности мыслительного процесса эксперта. Непрямой сбор/представление знаний — самая распространенная форма получения знаний. Наиболее важные методы непрямого сбора знаний приведены в 6.3.1.

5.2.1.2 Прямой сбор/представление знаний

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

5.2.1.3 Автоматический сбор/представление знаний

Процесс автоматического сбора/представления знаний направлен на преобразование текстовых знаний в знания, которые могут подвергаться компьютерной обработке, а также на извлечение знаний из существующих примеров. При этом в данный процесс не должны вмешиваться ни эксперты, ни инженеры по знаниям. Методы автоматического сбора/представления знаний можно обобщить с помощью термина «обнаружение знаний в базах данных» (KDD) или термина «интеллектуальный анализ данных» (data mining).

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

5.2.2 Типы представления знаний

Термин «представление знаний» относится к множеству синтаксических (правила компоновки/организации) и семантических (смысловые правила) характеристик, предназначенных для описания объектов и конкретных фактов. Ниже приведен перечень типов представления знаний, имеющих отношение к проектированию на основе баз знаний и автоматизированному проектированию:

• правила или продукционные правила частично состоят из условий и действий. Преимущества использования правил заключаются в их аналогии с человеческим мышлением и алгоритмами решения проблем, что позволяет экспертам четче выражать свои знания в виде правил. Сети правил (см. левую часть рисунка 1) иногда могут быть достаточно сложными, что может отрицательно влиять на возможности поддержания знаний;
• ограничения практически аналогичны математическим соотношениям между различными параметрами (например, U = R·I или F = m·a). Рекомендуется различать геометрические и инженерные ограничения. Геометрические ограничения, как правило, присутствуют на чертежах (схемах) для однозначного определения уникальным образом расположенных (совпадающих в пространстве, параллельных, тангенциальных и т.п.) элементов (точек, прямых, окружностей и т.п.). Инженерные ограничения позволяют иллюстрировать формулы и сохранять конструкторские данные, например при проектировании деталей машин (см. правую часть рисунка 1);
• прогностические модели (модели с предсказанием), получаемые по результатам интеллектуального анализа данных, регрессионных расчетов или моделирования нейронных сетей, также следует считать ограничениями;
• фреймы (в значении классов или моделей классов) можно формально считать аналогом «давно оправдавшей себя» системы картотечного (архивного) хранения, подходящей для представления аналогичных повторяющихся объектов, например компонентов или подсборок. Фреймы содержат групповые символы описательных атрибутов, которые могут принимать различные значения. В обработчике фреймов для описания впоследствии можно использовать такие атрибуты, как «составлено...», «форма установки», «число цилиндров», «кубатура» и т.д.

справа — пример для представления ограничений)

6 Процедура общей реализации KBE-проектов

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

Процедуру реализации KBE-проекта подразделяют на четыре этапа (см. рисунок 2). В 6.1 описаны роли, которым в той или иной степени необходимо следовать на этапах осуществления проекта, в 6.2 рассмотрен первый этап — этап планирования. Основное внимание на этапе планирования уделено организации KBE-проектов, в частности выявлению (идентификации) необходимых знаний. В 6.3 на этапе разработки главным образом представлены стратегии и методы сбора, анализа и структурирования знаний, а также различные варианты реализации (применения) знаний. В 6.4 на этапе тестирования перечислены процедуры валидации и релиза. В 6.5 описаны работы по администрированию, поддержанию и обновлению знаний. Обеспечение безопасности и защиты знаний не является отдельным этапом KBE-проекта, однако эту процедуру следует рассматривать как проходящую через все этапы. В 6.6 приведены положения, указывающие на особую важность обеспечения безопасности и защиты знаний в KBE-приложениях, и установлены соответствующие меры ее обеспечения.

KBE-проекта

6.1 Роли

На рисунке 3 приведены роли участников, связанные с реализацией KBE-проекта. «Мышление в ролях» (в отличие от «мышления в людях») позволяет каждому сотруднику компании выполнять одновременно несколько ролей. В то же время действующие роли конкретного сотрудника (например, CAD-проектировщик, инженер-расчетчик, IT-архитектор) не должны заменяться ролью, связанной с KBE-проектом, вместо этого в данный проект могут быть введены дополнительные специфические KBE-задачи. Наиболее существенные роли KBE-проекта приведены на рисунке 3.

Рисунок 3 — Основные роли участников KBE-проекта

6.1.1 Заказчик

Заказчик (например, менеджер проекта) должен инициировать KBE-проект и участвовать в нем с самого начала — с этапа планирования, так как именно он должен определить основные показатели проекта (например, тип и область применения KBE-приложения) и закрепить сотрудников за проектом. В процессе выполнения проекта заказчик должен выполнять функции более низкого уровня, ввиду того что управление проектом должен брать на себя инженер по знаниям (см. 6.1.4). На этапе тестирования заказчик должен участвовать в валидации KBE-приложения и проверять достижение целевых показателей. В случае выполнения KBE-проекта небольшого объема роли заказчика и инженера по знаниям может выполнять один специалист.

6.1.2 Эксперт

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

6.1.3 Пользователь

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

6.1.4 Инженер по знаниям

Центральная роль в рамках KBE-проекта принадлежит инженеру по знаниям или менеджеру проекта. Роль инженера по знаниям должна сохраняться и предпочтительно принадлежать одному и тому же специалисту на протяжении всего жизненного цикла KBE-приложения. Он должен выполнять роль посредника, прежде всего создавая «мост» между стратегическими целями, поставленными руководством компании или администраторами базы знаний, с одной стороны, и пользователями, осуществляющими бизнес-процессы, с другой. По этой причине еще одной задачей, стоящей перед инженером по знаниям, является контроль комплексного планирования, разработки и процессов эксплуатации KBE-системы, включая проведение предварительных исследований (например, разработку технико-экономического обоснования), выбор подходящих инструментальных средств (см. 6.3.1), получение знаний, интеграцию в IT-среду компании и последующую доработку KBE-приложения. Важнейшая задача инженера по знаниям — сбор экспертных знаний отдельных специалистов и ввод явных и неявных знаний экспертов и пользователей в KBE-приложение. С этой целью инженеры по знаниям, работающие над конкретной проблемой и контекстом, объединяют знания в общую сеть, формализуют, чтобы сделать знания доступными для KBE-приложений. Задача данных специалистов заключается также в мотивации сотрудников компании, выполнении функции посредника между различными группами сотрудников по интересам и устранении барьеров на пути управления знаниями (например, страхов, связанных с рационализацией производства).

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

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

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

6.2 Планирование KBE-проекта

6.2.1 Организация KBE-проекта

Целью выполнения KBE-проекта является разработка KBE-приложения. Во многих случаях конечная техническая реализация KBE-приложения — наиболее узкое место, зависящее от сложности KBE-проекта.

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

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

Согласно краткому описанию указанной методологии KBE-проект на первом этапе должен быть встроен в структуру компании. В первую очередь следует определить все необходимые для проекта знания.

Данные два этапа описаны в 6.2.2.

6.2.2 Идентификация необходимых знаний

Идентификация необходимых знаний основана, в частности, на анализе структуры компании, так как именно в ней сосредоточены основные бизнес-процессы и носители знаний. В общем случае существуют несколько процедур, которые могут быть отнесены к наиболее важным основным элементам. Во-первых, компания должна проводить анализ, направленный на выявление реальных проблем и имеющихся возможностей. На этом этапе анализ структуры компании и лежащих в ее основе бизнес-процессов (в данном случае — процесса разработки продукции) будет отражать особенности организации рабочих процессов. Помимо структуры компании и процессов необходимо определять состав сотрудников и привлекаемые ресурсы. Во-вторых, следует проводить целевой анализ, в котором необходимо определить задачи KBE-системы, в том числе описание интенсивности применения знаний и важность каждой задачи. Далее следует анализ затрат/выгод, а также экономической целесообразности (осуществимости) проекта.

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

• идентификации проблем и решений, которые следует включать в организационный контекст;
• принятия решения на основе экономической и технической реализуемости KBE-проекта.

Основной точкой сосредоточения внимания для проведения анализа в компании (в данном контексте) является ориентация на KBE-систему, а также на знания, которые необходимо вводить в KBE-систему. Таким образом, именно с этой точки зрения всегда следует начинать анализ организационной модели (ОМ). Вначале следует выявить проблемы и рассмотреть варианты их решения (этап ОМ-1). После изложения соответствующих бизнес-процессов (этап ОМ-2) следует их подробно описать (этап ОМ-3) и разъяснить необходимость использования в базе знаний (этап ОМ-4). Далее, на этапе ОМ-5, следует обобщить результаты технико-экономического анализа. Ниже приведено краткое описание всех указанных этапов.

6.2.2.1 Этап ОМ-1. Описание проблемы

Этап ОМ-1 разбивают на три части. Первоначально необходимо определить совокупность всех ролей, а затем выявить существующие в компании проблемы. Далее следует очертить круг возможных решений, однако перед этим в компании должны установить возможные роли (см. 6.1). Наконец, необходимо найти специалистов, т.е. менеджеров, которые способны принимать решения, касающиеся KBE-приложений.

6.2.2.2 Этап ОМ-2. Описание используемых бизнес-процессов

Проблемы, выявленные на этапе ОМ-1, как правило, связаны с определенным процессом проектирования, который благодаря внедрению KBE-системы будет последовательно совершенствоваться. Данный этап первоначально связан с описанием бизнес-процессов в общих терминах. Помимо этого, целесообразно проводить визуализацию получаемых результатов, тогда как результаты, полученные на предыдущих этапах (на этапе ОМ-1 и первой части этапа ОМ-2), должны вносить в предварительно составленный документ для принятия решения. Данный документ далее должен представляться руководству компании, после чего руководство должно принимать обоснованное решение относительно поддержки/отклонения проведения дальнейших работ по проекту.

6.2.2.3 Этап ОМ-3. Подробное описание бизнес-процессов

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

6.2.2.4 Этап ОМ-4. Описание базы знаний

Анализ базы знаний в рамках процесса (или в рамках отдельных задач) является центральным этапом при планировании и подготовке KBE-системы и представляет собой исходные описания баз знаний, которые должны быть уточнены на последующих этапах. Необходимо вначале идентифицировать базы знаний и за ними закрепить определенного сотрудника компании (или IT-систему и задачу). Базы знаний также ассоциируются с «носителями знаний». При разработке продукции в первую очередь принимают во внимание PDM-, ERP- и другие системы. Кроме того, отдельные элементы знаний (или базу знаний) также должны проверять на предмет их достоверности. Если знания, необходимые для выполнения KBE-системой той или иной задачи, не принимают надлежащую форму (или оказываются недоступными в нужном месте, в нужное время и с нужным качеством), то эти знания следует адаптировать (см. 5.1).

6.2.2.5 Этап ОМ-5. Разработка технико-экономического обоснования

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

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

6.3 Разработка KBE-проекта

6.3.1 Сбор знаний

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

В рамках KBE-проектов необходимо использовать следующие методы сбора знаний.

6.3.1.1 Интервьюирование

Возможность вербального выражения знаний их носителем является необходимым условием использования методов интервьюирования. Методы интервьюирования могут быть следующих трех категорий:

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

6.3.1.2 Анализ текстов

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

6.3.1.3 Методы наблюдения

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

а) Метод «размышление вслух»

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

• типовые, рутинные задачи эксперта;
• задачи с ограниченной исходной информацией;
• задачи, на которые распространяются определенные ограничения, например по времени.

б) Диалог с заказчиками

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

6.3.1.4 Методы обзора (анализа)

Методы обзора (анализа) служат для постоянного контроля и объединения уже собранных знаний и включают процессы свободного рецензирования, критического (пошагового) анализа и проверку/наблюдение.

6.3.2 Анализ и структурирование знаний

По окончании этапа сбора знаний их должен проанализировать и структурировать инженер по знаниям. На этапе анализа и структурирования знаний необходимо интерпретировать знания, определять структуру и принципы установления механизмов получения выводов. Для этого существуют различные методы, наиболее известные из которых — процедуры (методологии) MOKA и CommonKADS. Для создания основы онтологии следует осуществить поиск по записям интервью всех терминов и определений, наиболее важных для конкретного проекта. В данном контексте онтология может быть отнесена к семантически более ценной структуре и содержать термины и определения (для шатуна, карданного вала и т.п.), а также взаимосвязи типа is_a (является экземпляром), belongs_to (принадлежит) и т.п., которые, как правило, установлены между двумя терминами (или сущностями).

Для присвоения категорий только что собранным (на этапе исследования) знаниям используют ручные карточки в соответствии с процедурами (методологией) MOKA и ICARE-формы. При выполнении этого этапа необходимо проводить анализ содержания знаний в массиве знаний. После закрепления содержания знаний за категориями следует производить перевод знаний с неформального уровня (знания, которые невозможно обрабатывать в электронном виде) на формальный уровень (знания, которые можно обрабатывать на компьютере). В данном контексте часто упоминается полуформальный уровень, так как он определяет характеристики между неформальным и формальным уровнями. Соответственно этому знания необходимо обрабатывать для их последующей формальной интеграции в базу знаний (см. 6.3.3). Для анализа и структурирования конструкторских (проектировочных) знаний допускается классификация знаний по следующим категориям:

• иллюстрации — рисунки способны представлять сложный фактический контент и могут выражаться, например, в виде технических чертежей. Данный тип анализа знаний позволяет специалисту по программному обеспечению, который, возможно, не знаком с предметом и который несет ответственность за интеграцию знаний в базу знаний, понять фактическое содержание контента;
• ограничения — как указывалось в 5.2.2, ограничения (т.е. принудительно задаваемые условия) служат для представления математических соотношений между различными параметрами. Например, площадь поверхности круга зависит от его диаметра. Таким образом, формальные отображения можно представлять с помощью набора ограничений;
• операции (виды деятельности), которые позволяют описывать последовательность/процессы использования KBE-приложения и которые в основном могут быть сохранены в виде процедурных правил (регламентов) и описаны в форме операторных логических взаимосвязей. Специалист по методам представления/использования знаний, как правило, формулирует фактический контент с помощью условного оператора (if-then-else). Так, например, при достижении максимальной температуры (If) станок должен выключаться (then); в противном случае этот станок будет оставаться во включенном состоянии (else). Эти операции соответствуют правилам, приведенным в 5.2.2;
• правила — это правила и условия, используемые для описания целевого и фактического состояний (см. 5.2.2), которые соответствуют декларативным (описательным) правилам. Состояния описывают так же, как и ограничения, например с помощью упоминавшегося выше условного оператора if-then-else. Например, если идеальное состояние двигателя определяется по тому, что в нем функционирует определенный объем масла (IF Oil_Volume > 2 л, THEN Engine = функционирует, ELSE Engine = не функционирует);
• логические объекты (сущности), которые в основном используют для описания структуры изделий (сборок, подсборок, деталей) или структуры функции, поэтому данная категория представляет собой вариант более подробного описания терминов и определений, использованных в остальных категориях (например, максимальная температура, станок, диаметр, объем двигателя, объем масла). Целью этого описания является задание терминов и их определений, а также введение в отношение, для которого, например, можно использовать онтологию.

«Неформальную модель» используют для установления отношений индивидуальных ручных карточек, например для прозрачного представления связей между ограничениями и рисунками (для всех участвующих в анализе знаний). В качестве примера на рисунке 4 приведено правило, используемое в системе ICARE согласно процедуре (методологии) MOKA. Для применения представленной схемы в других проектах рекомендуется вносить в нее соответствующие изменения.

в системе ICARE по методологии MOKA

6.3.3 Реализация знаний

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

Реализация знаний тесно связана с процессом их сбора (см. 6.3.1), так как шаблоны для CAD-проектирования, расчетные таблицы или другие правила и нормы уже существуют. В отличие от общего представления знаний (см. раздел 3), которое соответствует синтаксическому и семантическому описанию фактических аспектов, конструкторские знания в процессе их реализации должны храниться на «носителях знаний».

6.3.3.1 Материальные носители знаний — основы знаний

Носители знаний в компаниях могут быть отнесены к двум категориям: к носителям персональных данных (например, к данным об эксперте) или к носителям неперсональных (материальных) данных (например, к документам, базам данных и т.д.). При этом носители материальных знаний обеспечивают возможность их сохранения в цифровой форме, делая эти знания доступными, например, для KBE-приложения. Совокупность этих знаний, актуальных для KBE-приложения, также называют «базой знаний». В данном контексте потенциальные носители материальных знаний могут обозначаться как:

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

Таким образом, CAD-геометрия является одним из наиболее эффективных носителей конструкторских знаний:

• номенклатурные перечни деталей и управление деталями [как правило, с помощью системы управления данными об изделии (PDM-системы)]. Перечни деталей, в частности перечни вариантов исполнения, составленные согласно выбранному правилу, часто служат носителями знаний для вариантов исполнения конструкции и деталей. При этом правило относится к объектному соотношению между деталью и соответствующей сборкой (узлом) более высокого уровня. Кроме того, таблицами вариантов исполнения можно управлять с помощью характеристик изделия, что делает эти таблицы весьма ценным носителем знаний;
• специализированные базы знаний в форме набора правил и ограничений;
• базовые технологии (специализированные программные системы), которые часто используют для реализации KBE-приложений. Эти технологии содержат, помимо прочего, компоненты решения проблемы, которые позволяют оценивать правила для определенного случая (проблемы) и делать соответствующие выводы. Эти правила или ограничения сохраняются в базе знаний с определенной структурой и синтаксисом;
• программное обеспечение в виде соответствующих макросов для алгоритмов расчета. Данную форму носителя знаний достаточно широко применяют в методах автоматизации задач при CAD-проектировании. Знания при этом содержатся в программном коде и, соответственно, остаются доступными только для программиста.

6.3.3.2 Принципы реализации KBE-приложения и интеграция в рабочую среду разработчика

Современные 3D CAD-системы являются одними из наиболее предпочтительных компьютерных программных средств для разработчиков, поэтому KBE-приложение должно быть тесно связано с CAD-системой или интегрировано в нее. Принцип функционирования при этом можно рассматривать как тип дистанционного управления CAD-системой, в которой KBE-приложение можно активировать, например путем отображения/скрытия таких элементов, как стандартные детали или как режим параметрического проектирования, с функциями и ограничениями для новых деталей (см. рисунок 5).

Рисунок 5 — Принцип функционирования KBE-приложения

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

• комплексный (интегрированный) подход (см. рисунок 6а). При этом KBE-приложение полностью интегрируют в CAD-систему, что упрощает ее взаимодействие с CAD-моделью. Соответствующие знания (базу знаний) поддерживают непосредственно в CAD-системе. Широко распространенным представителем подобного подхода являются KBE-модули различных поставщиков CAD-систем, которые непосредственно включают в геометрические модели. Пользовательский интерфейс интегрируют в диалоговую систему управления CAD-системы. Другой вариант реализации KBE-приложения в CAD-системе связан с традиционными методами, использующими скрипты/макросы, шаблоны или программы, которые разработаны с помощью программного интерфейса CAD-системы (интерфейса прикладных программ — API);
• комбинированный (связанный) подход (см. рисунок 6б). KBE-приложение является автономной системой, связанной с CAD-системой, приведение в действие которой или обмен данными которой должен осуществляться с помощью API-интерфейса. Существенное отличие данного подхода от комплексного (интегрированного) подхода заключается в наличии отдельного хранилища данных (собственной базы знаний) и автономного пользовательского управления/интерфейса.

и комбинированный (б) подходы

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

6.4 Тестирование и валидация KBE-проекта

Следует отметить, что в процессе тестирования выявляются только ошибки, однако отсутствие ошибок не может заменять процесс тестирования. Тем не менее процедура тестирования имеет большое значение, так как она является существенной частью всего проекта, а также позволяет дополнять или проверять соответствие требованиям. Если не принимать в расчет ошибки, то проект, разработанный с помощью KBE-приложения, может потерпеть неудачу и тем самым нанести впоследствии серьезные убытки. Если KBE-приложение использовать для разработки отдельных изделий, то его отказ может привести к приостановке выполнения отдельных операций.

При первом появлении ошибок следует принимать во внимание необходимость разработки программного обеспечения для их исправления.

6.4.1 Затраты на тестирование

Затраты на тестирование программ могут составлять не более 50% от общих затрат на проект. Эти затраты соответственно могут влиять на сроки выполнения задания и общие затраты на KBE-проект. Этап тестирования, как и другие этапы, необходимо планировать с такой подробностью, которая будет соответствовать области применения KBE-проекта.

Затраты на тестирование должны напрямую соответствовать возможному риску, поэтому существует мнение, что из-за задержки внедрения KBE-проекта слишком тщательный подход к устранению ошибок может снижать выгоду от применения программного обеспечения.

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

6.4.2 Определение границ тестирования

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

6.4.3 Подготовка к тестированию для компиляции требований

В начале проекта перечень требований всегда является неполным, но он может быть основой для проведения тестирования. Если приемочное испытание не было предусмотрено заранее (или предусмотрено слишком поздно) для более полного проекта (поздней стадии проекта), то может возникнуть риск того, что новые требования (которые при существующем состоянии разработки не были предусмотрены) будут установлены в процессе самого тестирования. Следовательно, соответствующие примеры/сценарии тестирования следует определять в самом начале выполнения проекта [в сотрудничестве с более поздними пользователями всех поддерживаемых задач (вариантов использования)]. Сторонники разработки, основанной на тестировании, рекомендуют определять полную процедуру тестирования перед началом проведения работ и выполнять тестирование параллельно с выполнением работ по программированию. Если тестовые (контрольные) примеры невозможно определить одновременно для всех требований, то необходимо принимать в расчет пошаговую процедуру, с помощью которой следует проводить приемочные испытания на каждом этапе разработки с продолжительностью примерно в 2 нед.

6.4.4 Модульное тестирование (юнит-тестирование)

Даже небольшое KBE-приложение всегда содержит подпрограммы, состоящие из нескольких компонентов (например, CAD-систему, стандартную библиотеку деталей, базу данных, программу), которые первоначально необходимо тестировать по отдельности. Это может относиться, в частности, к компонентам, сформированным различными специалистами.

6.4.4.1 Тестирование CAD-моделей

Процесс тестирования CAD-моделей, созданных с помощью KBE-приложения, не отличается от KBE-приложения для параметрических «автономных» CAD-моделей.

6.4.4.2 Тестирование базы знаний

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

6.4.4.3 Результаты тестирования, представляемые в явном виде

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

6.4.4.4 Результаты тестирования, представляемые в неявном виде

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

6.4.4.5 Тестирование кода

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

6.4.4.6 Тестирование пользовательского интерфейса

Контрольные примеры также должны учитывать проверку правильности данных, что может потребоваться в тех случаях, когда вводимые данные определены для другого компонента (или изменены другими компонентами). При этом при вводе данных пользователем следует предотвращать программные сбои.

6.4.5 Комплексное тестирование

Взаимодействие модулей, позволяющее их объединять для получения KBE-приложения, проверяют в процессе комплексного тестирования. При этом следует учитывать, что продуктивная среда (CAD-система) может отличаться от среды разработки (по своей версии или параметрам конфигурации).

Комплексное тестирование, как правило, выполняют при отсутствии информации или результатов анализа внутренней структуры компонентов, другими словами — при использовании методов «черного ящика». По этой причине сценарии тестирования следует выбирать либо исходя из конкретных требований, либо из ожидаемого стиля работы пользователя. Благодаря реализации отдельных компонентов (например, с использованием SQL, C++, MS - Excel^{®} , VBA, CAD, CAD-макросов) важно обеспечивать возможность выполнения комплексного тестирования как минимум одним из участвующих в KBE-проекте программистов или проектировщиков.

6.4.6 Приемочные испытания

Необходимо отметить, что в процессе приемочных испытаний необходимо корректировать не только 3D-объемную модель, но и чертежи, данные в перечне элементов, а также дополнительные показатели производственного процесса, полученные по результатам испытаний.

6.4.7 Пилотное тестирование

Для проектов с сокращенным объемом тестирования дополнительные ошибки также могут быть обнаружены на этапе пилотного тестирования. Для устранения этих ошибок необходимо принимать дополнительные меры, связанные, например, с персоналом, бюджетом и т.п.

6.4.8 Регрессионное тестирование

KBE-приложения необходимо уточнять на соответствие реальному изделию и соответственно повторно тестировать. Кроме того, функции KBE-приложения могут меняться при изменении базового программного обеспечения компонента (CAD-системы, Excel^{®} , базы данных, операционной системы). Если вероятность и последствия неправильного функционирования KBE-приложения существенны, то тестирование, предназначенное для определения функциональных возможностей данного компонента, должно быть проведено повторно. По этой причине все регрессионные тесты следует соответствующим образом идентифицировать, классифицировать и при необходимости автоматизировать.

6.4.9 Привлекаемый персонал и его роли

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

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

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

В случае выполнения крупных проектов к ним также могут быть привлечены сотрудники, которые будут выполнять роль тестировщика.

6.5 Эксплуатация KBE-приложения

Для этапов внедрения и эксплуатации KBE-приложения сложилась наилучшая практика, которую необходимо изучить.

6.5.1 Аспекты, связанные с персоналом при внедрении KBE-приложений

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

• для чего необходимо KBE-приложение?
• кто является инициатором его разработки?
• кто определял исходные данные (технические требования) к данному KBE-приложению?

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

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

6.5.2 Администрирование, поддержание и обновление знаний

В процессе эксплуатации системы необходимо постоянно обеспечивать актуальность данных, на которых она основана (например, на стандартные детали и изделия). На многих промышленных предприятиях KBE-результаты (новые проектируемые детали, конфигурации сборок и т.д.) следует контролировать в соответствующих системах (например, в PDM-системах). Результаты следует периодически пересматривать при последующих обращениях к базе знаний, для чего требуется установить соответствующие правила и распределить обязанности.

Кроме того, в содержащиеся в KBE-приложении объекты (например, структуры, компоненты, атрибуты, правила, геометрические элементы) должны регулярно вносить изменения с целью устранения ошибок, оптимизации/совершенствования KBE-приложения или его расширения в соответствии с новыми требованиями пользователя. Таким образом, большое внимание следует уделять управлению изменениями, регулярным проверкам на соответствие подключенным системам (например, PLM-системам), а также применяемым стандартам и руководящим документам.

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

6.6 Обеспечение безопасности и защиты знаний

В 6.3.3.1 в качестве базового носителя знаний о материалах описана CAD-геометрия/модель, которая является основополагающей как для получения знаний, так и для их реализации. Варианты сохранения знаний в CAD-модели достаточно разнообразны и открывают широкие возможности с точки зрения информационной открытости и многократного использования знаний. В то же время в компании может возникнуть реальная угроза, что вместе с CAD-моделью будут потеряны хранящиеся в ней знания. Например, предысторию моделирования и, следовательно, метода проектирования всегда можно проследить по древу CAD-модели. Современные CAD-системы также предлагают пользователям возможность непосредственного сохранения в CAD-модели знаний в виде правил или ограничений. Другим вариантом сохранения знаний в CAD-модели является использование PMI-элементов (элементов производственной информации об изделии). Хотя эти элементы не содержат геометрические данные, они тем не менее будут содержать профильные сведения, такие как:

• допуски на форму и расположение;
• 3D-аннотации (маркировку);
• информация о поверхности;
• спецификации на материалы.

Общий риск от несанкционированного приобретения/извлечения знаний третьей стороной или посторонними лицами возрастает из-за того, что знания в CAD-моделях всегда находятся в формализованном (т.е. в доступном для восприятия и оцифрованном виде). С другой стороны, возможные злоупотребления знаниями могут быть предотвращены из-за наличия в CAD-моделях четкой контекстной ссылки на знания. Текстовый или табличный расчетный документ не способен описывать взаимосвязь между требованиями и конструкцией изделия так же непосредственно, как параметрически-ассоциативная и основанная на знаниях CAD-модель. Для последовательного применения методов проектирования на основе баз знаний, описанных в настоящем стандарте, необходимо внедрять эффективные меры по защите знаний. Помимо фундаментальных мер защиты IT-инфраструктуры (прав доступа, межсетевых экранов и т.п.) применяют еще два важных принципа — концепции IT-безопасности «Управление цифровыми правами» (DRM-управление) и «Фильтрация данных» (DF-фильтрация).

6.6.1 Управление цифровыми правами

DRM-управление — это цифровое шифрование документов и управление правами доступа. Базы данных способны обмениваться данными только в закодированном формате, после чего DRM-управление будет контролировать, кто, каким образом и в какие сроки может пользоваться документами. Таким образом, например, CAD-модель может быть доступна конкретному получателю с целью создания чертежей, однако заблокированными для этого пользователя будут операции копирования и вставки. Для DRM-систем требуется специальная IT-инфраструктура, позволяющая отслеживать поставщиков IT-услуг. Центральный сервер поставщика решений регулирует назначение прав доступа к обмениваемым данным.

6.6.2 Фильтрация данных

Целью DF-фильтрации является удаление из CAD-модели определенных областей. Вместо подробных параметрически-ассоциативных моделей достаточно обмениваться форматами данных, которые способны отображать геометрию в мозаичной форме, например при решении задач «чистой» визуализации или DMU-исследованиях. К таким форматам данных относятся форматы STL, CGR, VRML (или его преемника — X3D). Если мозаичную геометрию нельзя использовать, то следует применять формат JT, STEP или IGES. К возможным вариантам также относится целевое «упрощение» модели путем удаления из нее элементов (например, высверленных отверстий, радиусов, головок винтов) из отдельных деталей или из компонентов подузлов, а также их замена огибающей геометрических элементов (геометрия оболочки). Рекомендуется изменять параметрически-ассоциативные CAD-модели только в случаях тесного сотрудничества с целью содействия развитию; при этом также необходимо выяснить, действительно ли партнер по обмену данными требует (например, для решения своих задач по CAD-расчету допусков) эмпирических знаний.

При выборе метода кодирования или фильтрации CAD-моделей необходимо помнить, что психологический эффект от использования закодированных данных не следует недооценивать: деловые партнеры, которые предоставляют закодированные CAD-модели, могут сигнализировать друг другу о том, что основное содержание этой модели скрыто с помощью ограниченного права доступа. Если, с другой стороны, партнеры обмениваются неявно фильтрованными наборами данных, то во многих случаях можно предотвращать упорную конкурентную борьбу за определенную область данных. На практике конкретные решения или защиту знаний также следует оценивать на предмет того, насколько они способны поддерживать вышеуказанные формы представления знаний в CAD-моделях. Независимо от способа защиты знаний — посредством шифрования (кодирования) или фильтрации, необходимо идентифицировать все наиболее важные элементы. Благодаря множеству шаблонов и рекомендаций для OEM-производителей и поставщиков компании способны полностью использовать возможности CAD-систем в соответствии с собственной схемой представления знаний для своего конкретного CAD-проекта.

7 Технические решения для KBE-проектирования

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

7.1 Принципы классификации автоматизированных систем

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

с принципом поддержки, основанной на базах знаний

Грубое определение характеристик программных средств призвано облегчить выбор подходящих методов и выявить возможные варианты проектирования.

7.1.1 Классические конфигураторы изделий

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

7.1.2 Системы управления данными об изделии (PDM-системы)

PDM-системы в настоящее время являются неотъемлемой частью рабочей среды проектировщика, которые обычно используют для формирования структуры продукции, перечня элементов или для их структурного сопоставления.

С помощью основанных на правилах вариантов перечней элементов можно разрабатывать модульные структуры для продукции, после чего эти перечни будут выполнять роль конфигуратора продукции, выполняя и соответствующие функции фильтра. Связь с CAD-системой в основном означает возможность создания KBE-приложения, что на практике происходит достаточно редко. Существенный вклад PDM-системы в интеллектуальное проектирование заключается в предоставлении технических характеристик продукции (например, свойств материалов, явно контролируемых параметров, например размеров, жесткости пружины, электрических параметров). Таким образом, PDM-системы могут выдавать важные дополнительные данные или базы знаний для KBE-приложений.

7.1.3 3D-конфигураторы изделия/продукции

3D-конфигураторы продукции предназначены для компенсации недостатков, связанных с отсутствием CAD-интеграции в классических конфигураторах продукции. При этом компоненты продукции, сконфигурированные, например, путем показа, скрытия или замены групповых символов, при формировании CAD-сборок являются позиционно-совместимыми. Как правило, основной целью создания KBE-приложения является CAD-поддержка расчетов коммерческих предложений, которые оцениваются автоматически на основе созданных CAD-чертежей. CAD-сборки, уже созданные на этапе разработки коммерческого предложения, также обеспечивают временные преимущества в цикле выполнения заказа после его размещения. Характеристики 3D-конфигураторов продукции часто выражают в виде веб-приложения, в котором CAD-сервис формирования геометрических элементов можно вызывать (связывать) в асинхронном режиме.

7.1.4 CAD-системы

Современные 3D CAD-системы в основном предлагают эффективные варианты проектирования на основе баз знаний, к которым, в частности, относятся метод параметрического проектирования на основе баз знаний, а также различные расширенные функции. При параметрическом проектировании на основе баз знаний прежде всего используют формулы, с помощью которых можно формировать целые группы условий (например, длина = ширина x 2 + 10). Расширенные функции позволяют, например, придавать дополнительные свойства геометрическим элементам (например, предоставлять производственную информацию). Часто также могут создаваться и программы сопряжения с расчетными таблицами (например, MS - Excel® ), которые в соответствии с определенными техническими требованиями к расчетам можно использовать для создания различных вариантов. Таким образом, существует возможность эффективно формировать модульные системы. Ранее специфические приложения, основанные на инженерии знаний, часто разрабатывались с помощью программных интерфейсов (API), предлагаемых CAD-системами (например, путем вариантного программирования).

7.1.5 KBE-системы

Использование расширенных методов работы со знаниями или методологической IT-компоновки/поддержки процессов проектирования является предметной областью KBE-систем. Данные методы основаны на методах, используемых в традиционных системах, базирующихся на знаниях, которые постепенно совершенствовались путем введения инженерных функций. KBE-системы, как правило, содержат мощные компоненты решения проблем (также называемые «решателями уравнений», «процессорами правил» или «логическими механизмами обработки информации»). В отличие от метода традиционного программирования, правила и ограничения вводят в базу знаний с помощью определенного, в основном легко воспринимаемого синтаксиса, что позволяет упростить поддержание базы знаний независимо от используемого KBE-приложения. Еще одной особенностью является тесная связь с CAD-системой или CAD-геометрией как в интегрированном, так и в сопряженном виде. Большинство ведущих производителей CAD-систем предлагают собственные дополнительные KBE-модули или системы, которые часто можно соединять со специализированными вычислительными системами (например, с FEM-системами). KBE-решения можно также использовать для проверки технических чертежей, CAD-моделей и т.п.

7.1.6 Системы автоматизированного проектирования

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

7.2 Примеры KBE-решений

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

• CAD-систем со встроенными программными функциями (см. 7.2.1);
• KBE-систем/модулей (см. 7.2.2);
• 3D-конфигураторов изделий и автоматизации проектирования (см. 7.2.3).

Решения, основанные на использовании CAD-систем со встроенными программными функциями, также можно относить к трем следующим подкатегориям решений с использованием:

• простых CAD-функций (типа «бортового оборудования») (см. 7.2.1.1);
• CAD-макросов и интеллектуальных функций/свойств (см. 7.2.1.2);
• собственных разработок на основе CAD-API (см. 7.2.1.3).

В соответствующих примерах:

• описаны исходные данные;
• определена мотивация к реализации проекта с учетом намеченных целей;
• описаны тип и способ реализации проекта;
• определено хранилище данных/знаний;
• перечислены используемые средства.

Кроме того, проведена оценка расходов, преимуществ и конкретных задач (см. таблицу 1).

Таблица 1

проведенная на основе примеров подраздела 6.2

KBE-решения, рассматриваемые в разделах настоящего стандарта		Требуемый персонал	Требуемые навыки и знания	Требуемые лицензии и программное обеспечение	Необходимые расходы	Потенциальные пользователи
CAD-системы и интегрированные программные функции (см. 7.2.1)	Приложение для расчета/проектирования конструкций передаточных механизмов (см. 7.2.1.1)	Проектировщик	Опыт программирования в целом	CAD-система, база данных SQL	Низкий уровень расходов на поддержку и тестирование	Студенты, участники тренингов
	Автоматическое проектирование кинематической схемы стеклоподъемника с помощью интеллектуальных средств (см. 7.2.1.2)	Разработчики приложений, специалисты по компонентам, проектировщики	Внутренний CAD-язык программирования	CAD-система и KWA-лицензия	Средний уровень расходов на поддержку и тестирование	Проектировщики по всему миру
	Разработка KBE-приложения с помощью CAD-интерфейса программирования (см. 7.2.1.3)	Разработчики продукции, проектировщики, плановики производства, инженеры по знаниям или программисты	Расширенные навыки в программировании и использовании методов интервьюирования	ERP-/PLM- и CAD-системы, UDF и программный интерфейс в качестве встроенного оборудования	Совокупность экспертных знаний, средний уровень расходов на поддержку	Проектировщики и персонал коммерческого отдела (конфигурация)
KBE-модули и системы (см. 7.2.2)	Проектирование ползуна на основе специфических для пользователя диаграмм (см. 7.2.2.1)	Проектировщики, персонал коммерческого отдела, инженеры по знаниям или программисты, сторонние консультанты	Расширенные навыки в использовании языков программирования, в особенности — коммерческих KBE-модулей	Коммерческие KBE-модули CAD-системы, возможно, лицензия на проектирование пользовательского интерфейса	Средний уровень расходов на поддержку, обучение и тестирование	Проектировщики и персонал коммерческого отдела
	Пример обучения по использованию основных KBE-функций в CAD-системе (см. 7.2.2.2)	Проектировщики, инженеры по знаниям или программисты, возможно, сторонние консультанты	Расширенные навыки в программировании	KBE-модули с оборудованием в составе CAD-системы, UDFs, расчетные таблицы и программное обеспечение для них	Средний уровень расходов на поддержку, обучение и тестирование	Проектировщики
Конфигураторы продукции и автоматизация проектирования (см. 7.2.3)	Конфигурация подъемных систем, основанная на знаниях (см. 7.2.3.1)	Проектировщики, инженеры по знаниям или программисты, менеджеры по продукции	Расширенные навыки в программировании (например, для XML-интерфейса)	ERP-/PLM-системы, CAD-системы со встроенным конфигуратором (с комплексной увязкой параметров)	Средний уровень расходов на поддержку, обучение и тестирование	Проектировщики и персонал коммерческого отдела
	Веб-портал с конфигуратором для лестниц, платформ и переходов (см. 7.2.3.2)	Проектировщики работ/производства, инженеры по знаниям или программисты, маркетологи	Расширенные навыки в программировании, знание правил, связей и бизнес-процессов	CAD-, PDM-, CRM- и ERP-системы, встроенные в сеть системы 3D-отображения, коммерческие авторские средства	Низкий уровень расходов на поддержку, обучение и тестирование	Персонал коммерческого отдела, заказчики, сотрудники технических отделов

7.2.1 Решения, основанные на использовании CAD-систем со встроенными программными функциями

7.2.1.1 KBE-приложение для вывода чертежей редуктора

а) Исходные данные

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

(справа) варианты планетарной передачи

б) Цели реализации KBE-приложения

Цель реализации данного KBE-приложения — оперативная разработка основной секции планетарной передачи вместе с проработкой необходимой информации (относительно местоположения неподвижного подшипника, сечения подшипников различных типов и т.п.). При этом вопросам оптимизации уделено не слишком большое внимание (например, в отношении расходов). Кроме того, KBE-приложение по своей структуре информационно открытое, поэтому допускается простая модификация отдельных элементов (подшипников, элементов крепления, зубчатых колес и т.п.).

в) Организация KBE-проекта

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

г) Рассматриваемые области

В данном разделе следует указывать необходимое программное обеспечение и стандартные детали. Электронная передача данных не проводится в виде импорта или экспорта данных. Входные данные для KBE-приложений введены самим пользователем.

д) Реализация KBE-приложения

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

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

е) Знания и базы данных

Данные о стандартных геометрических элементах (например, о пазе стопорного кольца) отображены в таблицах базы данных и данных о стандартных деталях, а также таблицах родственных элементов (см. рисунок 9). Знания для использования подобных таблиц, касающиеся проектирования и расположения геометрических элементов (их наличия и расстояний между ними), отображались в программе на языке BASIC (см. рисунок 10). Знания, относящиеся к расположению элементов (в части их порядка и ориентации), отображались в параметрической 3D CAD-модели, которая адаптировалась благодаря данным, рассчитанным в программе на языке BASIC и передаваемым из нее (см. рисунок 11).

с коэффициентами нагрузки и в таблице родственных элементов

приложения (BASIC)

в CAD-модели

ж) Средства реализации

В данном примере описана современная CAD-система с коммерческим параметрическим средством моделирования. Применение базы данных основано на использовании языка SQL и может быть реализовано, помимо прочего, с помощью существующих офисных приложений. Явное программирование выполнялось с помощью программы Visual Basic for Application (VBA), а также языка описания сценариев для управления последовательностями в семействе программ Microsoft^{®} Office.

и) Расходы, преимущества, проблемы

Временные затраты на реализацию данного примера составили 52 человеко-часа, что означало экономию времени порядка 10 человеко-часов на каждый проект.

7.2.1.2 Автоматизированная тяга кинематического механизма стеклоподъемника для дверей транспортных средств

а) Исходные данные

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

механизма стеклоподъемника в конструкции автомобиля

б) Цели реализации KBE-приложения

Цель реализации данного KBE-приложения — автоматическое создание геометрии интерфейса AGT для оперативного реагирования на запросы на внесение изменений. В силу того что компания работает по всему миру, использование существующих стандартов и норм на каждой рабочей станции проектирования должно быть обеспечено KBE-приложением. Знания для этого приложения необходимо предварительно проверять посредством тестирования и сохранять в центральной базе знаний в виде правил проектирования и ограничений. Таким образом, заказчик рассчитывает на сокращение цикла расчетов и повышение стабильности CAD-моделей при работе с конкретными методами проектирования.

в) Организация KBE-проекта

Разработчики приложения создают CAD-шаблоны в соответствии с действующими стандартами, правилами и нормами проектирования. Специалисты по материалам, инструментам и компонентам выпускают технические шаблоны. За каждым интерфейсом закреплен ответственный специалист по компонентам, задача которого состояла в своевременном информировании разработчиков приложений о внесенных изменениях. Шаблоны тестировались назначенными проектировщиками на предмет удобства и практичности применения данных шаблонов.

г) Рассматриваемые области

При составлении и обновлении шаблонов привлекают специалистов различных профилей. Приложение использовалось в проектно-конструкторских отделах по всему миру. Обучение и поддержку обеспечивают ключевые пользователи на сайте или разработчики приложений в центральном функциональном подразделении. Шаблоны встраивают в IT-инфраструктуру, поэтому предоставление новых или измененных шаблонов практически не приводит к дополнительным расходам.

д) Реализация KBE-приложения

Осуществимость и экономическую жизнеспособность KBE-приложения проверяют с начала проекта, после чего компилируют функцию PowerCopies (функция CATIA V5, предназначенная для использования шаблонов).

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

е) Знания и базы данных

В шаблонах отражены знания, представленные в стандартах, правилах и нормах проектирования, а также эмпирические знания сотрудников компании. Эти знания после использования шаблонов доступны в соответствующем файле проектных данных, так как некоторые параметры можно изменять.

ж) Используемые средства реализации

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

и) Затраты, выгоды, проблемы

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

7.2.1.3 Конфигуратор сверления отверстий в кассетах из нержавеющей стали

а) Исходные данные

В данном примере представлена конфигурация высококачественных кассет (см. рисунок 13), в которых отверстия для соединений частично реализованы на основе стандартных конфигураций и частично на основе конструктивных специфических требований заказчика. В конструкции кассеты следовало рассчитать утолщения и углубления для упорных кронштейнов в зависимости от геометрии приливов и отверстий, а также от прочности/жесткости материала кассеты и особенностей ее монтажа у заказчика. Помимо ручного открытия и адаптации существующих проектов к CAD-системе много времени затрачивалось главным образом на внесение изменений в перечень элементов и рабочих мест, а также на производственные консультации. Указанные мероприятия потребовали задействования десятков рабочих мест проектировщиков.

на заднем бортике (с маской ввода)

б) Цели реализации KBE-приложения

Для повышения качества выполняемых работ и сокращения затрат (т.е. общих затрат на обработку заказов, которые должны быть значительно сокращены на всех этапах работ) необходимо в сотрудничестве с департаментом управления, проектирования и производственного планирования сформулировать соответствующие целевые показатели, например фиксированный целевой параметр со значением — снижение затрат на 10%, что позволяет фиксировать выгоду в цифровом выражении после завершения KBE-проекта. В данном примере также предусмотрено требование амортизации в течение 24 мес. В качестве целевой группы или группы пользователей при реализации данного проекта рассматривались не только участники проекта, но и сотрудники отдела продаж. Пользователи в первую очередь должны получить возможность работы с приложением на интуитивно понятном уровне и снижение затрат на поддержку продукции.

Пользователи KBE-приложения должны полностью интегрироваться в существующие процессы (разработки продукции, планирования производства и т.п.) и системы (IT-инфраструктуру, CAD- и PDM-системы и т.п.); закупка новых аппаратных средств и программного обеспечения не предусмотрена.

в) Организация KBE-проекта

В состав проектной группы входили:

• разработчик продукции;
• проектировщик;
• программист;
• плановик производственного отдела;
• разработчик IT-архитектуры;
• инженер по знаниям.

В роли заказчика и пользователя выступает проектировщик, который вместе с плановиком производственного отдела и разработчиком IT-архитектуры также является экспертом. Экспертизой работы инженера по знаниям, который возглавлял проект, и программиста занимались внешние поставщики услуг.

г) Рассматриваемые области

В зависимости от этапа разработки KBE-проекта в работу включались различные отделы компании. В процессе определения и обработки исходных данных принимали участие следующие отделы:

• разработки;
• проектирования;
• планирования работ;
• разработки IT-архитектуры в компании;
• службы сбыта (коммерческий отдел).

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

д) Реализация KBE-приложения

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

Хотя указанные аспекты реализованы еще в исходном прототипе, одновременно сформулированы и критерии приемки технологического процесса, чтобы эти критерии позволяли проверять правильность интеграции KBE-приложения в существующие процессы. В данном примере для описания процесса используют унифицированный язык моделирования UML. Объекты знаний, содержащиеся в данной модели процесса, их взаимосвязи и методы получены методом экспертного опроса (неструктурированных интервью), а также с помощью CAD-модели и анализа перечня элементов, после чего они были адаптированы к базе знаний. Первую версию KBE-приложения проверяют на соответствие критериями приемлемости (оценки качества) и постоянно обновляют с помощью текущих экспертных обзоров, а также путем непрерывного ввода новых знаний.

е) Знания и базы данных

Знания закреплялись в KBE-приложении посредством сочетания комплексного (интегрированного) и связанного подходов. Основной предпосылкой для этого являлось использование параметризованных CAD-моделей, которые можно было динамически «адаптировать» к новым ограничивающим условиям с помощью правил и ограничений. Кроме того, структура, содержащая перечни элементов и рабочие планы, создавалась в ERP- или PLM-системе, а также управлялась с учетом установленных правил и ограничений. Кроме того, эти правила и ограничения (см. рисунок 14) представлялись в виде XML-файлов. Расширяемый язык разметки XML представляет собой форму текстового представления иерархически структурированных данных и характеризуется независимостью от используемой компьютерной платформы и простотой распространения (см. рисунок 15). Реализованы независимые от платформы программные модули, в которых использовались XML-файлы и действовали содержащиеся в них правила. Эти модули также обеспечивают доступ (автоматизированный) к источникам данных (поступающих, например, из PLM-системы) с целью ввода данных/значений в конкретные правила.

«лицом к лицу»]

из базы знаний приложения (ограничение и правило)

ж) Используемые средства

CAD-система основана на использовании современного коммерческого средства параметрического моделирования. В частности, при этом выполнено обращение к функциям, определяемым пользователем UDF, а также к внутреннему макропрограммированию в CAD-системе. При наличии расширенных функций программирования рекомендуется применять CAD-специфичный API-интерфейс. В этом случае явное программирование можно выполнять с использованием таких языков, как Java^{®} , C\#^{®} или PYTHON^{®} .

и) Расходы, преимущества, проблемы

Первоначальные временные расходы на реализацию KBE-проекта составляют примерно 20 человеко-дней (внешние) и примерно 30 человеко-дней (внутренние). Расходы на техническое обслуживание каждой кассеты-носителя — примерно 4 ч, а экономия на каждой конфигурации — приблизительно по 2 ч рабочего времени.

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

7.2.2 Решения на основе KBE-систем и модулей

7.2.2.1 Проектирование режущей головки станка с помощью пользовательских диаграмм

а) Исходные данные

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

Рисунок 16 — Конфигурируемая режущая головка

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

б) Цели реализации KBE-приложения

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

в) Организация KBE-проекта

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

г) Рассматриваемые области

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

д) Реализация KBE-приложения

Отдельные этапы проектирования/конфигурирования, функции и классы программируют с использованием коммерческого KBE-модуля. В этих классах сохраняют данные, информацию и знания (например, собранные из производственных правил). Связанная с ними коммерческая CAD-система для пользовательского интерфейса выполняет функции интерфейсного диалогового стайлера, использовавшегося в качестве экранного окна ввода (см. рисунок 17).

Рисунок 17 — Экранное окно ввода проектировщика

Для удобства пользователя и оперативного устранения ошибок в процессе программирования программа предлагает разработчикам различные варианты экранного окна.

После этого проводится компиляция данных, что необходимо для выполнения последующих процессов (например, задания атрибутов для отдела подготовки документации). После выпуска бета-версии средства тестирования создают в соответствии с проектом. Ошибки, выявленные при тестировании, устраняют в версии № 1. После этого проектировщики, еще не участвовавшие в разработке, проходят обучение, а приложение внедряют.

е) Знания и базы данных

Знания извлекают из производственных правил, существующих проектов, руководств по проектированию и с помощью интервьюирования персонала. Знания сохраняют и применяют в исходном коде на языке программирования KBE-модуля с использованием классов и функций (см. рисунок 18).

KBE-модуля, встроенного в CAD-систему

ж) Использованные средства реализации

Для программирования использован коммерческий KBE-модуль CAD-программного обеспечения. Пользовательские интерфейсы компилируют с помощью интерфейсного диалогового стайлера CAD-программного обеспечения. Преимущество использованного KBE-модуля и интерфейса диалогового стайлера — это их полная интеграция в CAD-систему. При этом разработчик не получает инструкций по программированию интерфейсов API, поэтому совместимость разработанного KBE-примера в случае изменения версии в CAD-системе не имеет ограничений.

и) Затраты, выгоды, проблемы

Для реализации данного KBE-проекта потребовался примерно один человеко-год. В процессе работ необходимо обеспечить возможность дополнительного расширения номенклатуры монтажных компонентов. Последующие задачи включают в себя интеграцию в язык программирования KBE-модуля, а также обеспечение защиты данных. Благодаря реализации данного проекта можно было сэкономить по крайней мере 60% от первоначально запланированного времени разработки.

7.2.2.2 Пример обучения для изучения базовых KBE-функций в CAD-системе

а) Исходные данные

Данный пример отличается от всех остальных примеров прежде всего тем, что он в первую очередь предназначен для ознакомления участников проекта с KBE-модулем существующей CAD-системы. Начиная с параметризации CAD-модели (например, модели дроссельной заслонки в бензиновом двигателе) выяснялось, каким образом в CAD-модель интегрированы ограничения (формулы), правила, расчетные таблицы, тесты и реакции, а также каким образом KBE-приложения можно разрабатывать в виде шаблонов для компонентов. В качестве шаблона в данном примере выступает интеллектуальная «нейтральная (не зависящая от заказа)» исходная CAD-модель, которая с учетом определенных требований заказчика принимает только геометрические данные (необходимые для решения соответствующей задачи). На первом месте в данном примере поставлена не столько цель сокращения затрат, сколько возможность разработки KBE-приложения с соответствующим модулем CAD-системы.

б) Цели реализации KBE-приложения

В данном примере описаны основные этапы, которые необходимы для реализации радикального (автодидактического) подхода к использованию в CAD-системе базовых KBE-функций. Указанная процедура при этом неспецифична для компании и не направлена на оптимизацию конкретного процесса разработки. Акцент при этом сделан на повышение удобства эксплуатации и использования KBE-демонстратора с прозрачной и интуитивно понятной структурой. Требования относительно амортизации (в экономическом смысле) не установлены.

в) Организация KBE-проекта

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

г) Реализация KBE-приложения

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

(с сохраненными знаниями)

На следующем этапе логические взаимозависимости определяют с помощью правил. Для данного примера правило состоит в необходимости равномерного распределения трех крепежных болтов по всему фланцу. Большее число болтов равномерно распределено по сегменту фланца, который ограничен корпусом. Соответствующее правило приведено на рисунке 19. Дополнительный вариант — использование пользовательской функции UDF, которую можно рассматривать как «древо частной CAD-модели» и использовать в любой точке древа модели более высокого уровня. Функция UDF содержит все внутренние диаграммы, объекты, соотношения, параметры или формулы и связана с компонентом более высокого уровня только посредством элементов типа ссылки («условий сборки»).

В зависимости от вида CAD-системы целевое назначение функции UDF и этапы ее создания (или задания параметров/конфигурации) различаются. В довершении всего проводилось встраивание расчетной таблицы КТ, которую можно использовать для оперативного создания стандартизированных вариантов.

Расчетную таблицу можно составлять либо в CAD-системе, либо извне — с помощью соответствующего программного обеспечения (например, MS - Excel^{®} ). Преимущество внешней компиляции расчетных таблиц заключается в возможности задания ограничений (формул) непосредственно в программном обеспечении, что позволяет исключать лицензионную оплату за KBE-модуль разработчика CAD-системы.

д) Знания и базы данных

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

е) Использованные средства реализации

CAD-система основана на современном коммерческом параметрическом моделировании и предоставляет инженерам по знаниям простые варианты ввода ограничений и правил (посредством графического интерфейса), что обеспечивает сохранение знаний непосредственно на CAD-древе.

ж) Затраты, выгоды, проблемы

Временные затраты на реализацию данного примера составляют примерно 2 — 4 ч (в зависимости от опыта пользователя CAD-системы). Так как этот промежуток времени включает в себя обучение примеру, то конкретный выигрыш в виде экономии времени или затрат указать точно невозможно. Особых проблем для обученных пользователей при работе с CAD-системой не возникало.

7.2.3 Решения, связанные с конфигураторами изделий и автоматизацией проектирования

7.2.3.1 KBE-конфигурирование подъемного оборудования

а) Исходные данные

Среднесерийный производитель специализированного подъемного оборудования использует расчетные таблицы и CAD-макросы для предложения котировок и адаптивного проектирования. Наличие подобной несоответствующей базы данных приводит к необходимости проектирования для каждого заказа, что увеличивает сроки выполнения заказа и нагрузку на лучших проектировщиков. При этом подъемное устройство содержит три основных узла, состоящих примерно из 350 деталей каждый, из которых можно изменять (например, по размерам, расположению и т.п.) приблизительно 250 деталей.

б) Цели реализации KBE-приложения

Целью разработки данного KBE-приложения для участника продаж должна стать полная и бесперебойная обработка заказов (бизнес-процессов). При этом определены три основных бизнес-процесса:

• сборка на заказ;
• проектирование на заказ;
• управление вариантами исполнения.

В первом бизнес-процессе предложение котировок можно выполнять несколькими щелчками мыши и без принудительной заявки на вход в систему. Кроме того, предполагалось представление коммерческого предложения и связанных с ним CAD-данных вместе с защитой специальных знаний компании.

Второй бизнес-процесс предусматривает предварительное конфигурирование CAD-данных в процессе самих продаж (эскизное проектирование) с последующим выполнением заказа (детальное проектирование), при котором необходимо составлять полную, отвечающую стандартам техническую документацию (перечни элементов, 2D-чертежи и т.п.) на продукцию (изделие).

В третьем бизнес-процессе управления вариантами исполнения определенная стандартная группа продукции должна определяться всеми основными данными и CAD-данными с помощью конфигуратора, который можно использовать на всех этапах продаж или проектирования и который предназначен для получения всех технических и коммерческих знаний в легко воспринимаемом виде, а также для взаимодействия с PDM- и ERP-системами. Одновременно должны достигаться и коммерческие цели, например окупаемость инвестиций в течение менее одного года, время обработки заказа не должно превышать 1 ч и т.п.

в) Организация и реализация KBE-проекта

На первом этапе типовую серию изделий моделируют на пилотной основе, а менеджеры по управлению проектами проходят подготовку. Для создания прототипов и пилотных моделей программного обеспечения требуются коммерческие предложения, перечни элементов/деталей, специфические для пользователя чертежи и т.п. После представления проекта руководству компании (заказчику) приступают к его реализации. Ключевое положение при реализации проекта занимают технические характеристики конфигуратора, основанного на ограничениях, простота обучения работе с ним, его оперативная реализация и эффективная интеграция в CAD- и PDM-системы. Основываясь на технических требованиях (целях проекта, плановых бизнес-процессах и сценариях интеграции), реализацию осуществляют методом оперативной («гибкой») разработки. При этом функциональную область разбивают на спринты, которые затем реализуют на временных интервалах продолжительностью от 2 до 4 нед. Преимущество использования подобного метода состоит в постоянной доступности операционного конфигуратора. Важные вопросы, которые необходимо решить, — это стандартизация обозначений, классификация данных, присвоение атрибутов компонентам и сборкам, разработка графического пользовательского интерфейса, отображение предметно-ориентированных знаний в виде правил и ограничений, разработка 3D CAD-моделей (включая шаблоны для повторяющихся функций и образцов), создание шаблонов чертежей и коммерческих предложений, а также их окончательная интеграция в PDM- и ERP-системы компании.

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

для задания ограничений

Получены 3D-модели и чертежи, специфические для пользователя, путем отображения параметров базы знаний на функции основной 3D-модели. Различным образом детализированные 3D-модели при этом могут быть загружены для предоставления пользователям «очищенных» CAD-данных.

Новым деталям и подсборкам, требующим проектирования на заказ, PDM-генератор чисел присваивает соответствующие номера позиций, причем при их регистрации дублирование не допускается.

Сотрудники отдела сбыта, не обладающие необходимыми предварительными знаниями, также могут воспользоваться конфигуратором, поэтому пристальное внимание уделяют эффективной группировке полей ввода/вывода, а также вводу дополнительной информации (например, в виде изображений, пояснительных текстов). На рисунке 21 изображена CAD-система со встроенным конфигуратором (слева), который также можно использовать с помощью веб-браузера.

Рисунок 21 — Готовая сконфигурированная подъемная система

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

В бизнес-процессе управления вариантами исполнения определен стандартный ассортимент продукции. Все данные доступны через IT-системы, для чего конфигуратору выделены дополнительные средства, необходимые для расчета пространства вариантов и формирования CAD-данных в пакетном режиме. Теоретически это пространство ограничено соответствующими диапазонами допустимых значений входных параметров.

Функции руководителей производства сведены к управлению конфигуратором проекта, а сотрудники отдела проектирования и сбыта отвечают за его реализацию. Сотрудники отдела стандартизации выдают свои рекомендации, коммерческий отдел несет ответственность за разработку шаблона коммерческих предложений, соответствующих корпоративным требованиям, а отдел информационных технологий привлекают к реализации IT-интерфейсов.

г) Знания и базы данных

Важными компонентами каждого проекта конфигуратора являются сбор и подготовка имеющихся в компании знаний. Существующий набор правил состоит из вариантов, формул, правил, а также из схем расчета затрат на производство и реализационных цен. Новая база знаний — с одной стороны, модульная, с другой, многоуровневая по своей структуре (клиентская, сбытовая, маркетинговая и технологическая), по существу, содержащая в себе структуру изделия и ограничения. Взаимозависимости (т.е. варианты, формулы и т.п.) реализованы с помощью ограничений, которые действуют по всем направлениям и не зависят от порядка их следования. Новая база знаний интегрирована в файл эталонной 3D-модели для защиты данных и упрощения PLM-процессов. Дополнительных баз данных, находящихся вне существующей IT-системы, не потребуется.

д) Использованные средства реализации

Конфигуратор продукции, основанный на ограничениях, в KBE-приложении рассматривают в качестве основы, что позволяет создавать модели CAD-системы с коммерческим параметрическим ядром моделирования. CAD-система и KBE-приложение связаны с PDM-системой с помощью интерфейсов, которые способны обмениваться данными в XML-формате.

е) Требования, выгоды, проблемы

Инженер по знаниям, который управляет KBE-проектом, на протяжении всего проекта освобождается от фактического ежедневного исполнения своих рутинных обязанностей при соответствующей компенсации (по крайней мере — в виде свободного времени, рабочей загрузки). Кроме того, следует решить вопрос о возможности управления перечнями элементов с помощью ERP- или PDM-системы. Особую проблему представляет создание чертежей, совместимых с производством, отвечающих стандартам и не требующих ручной доработки.

7.2.3.2 Веб-портал с конфигуратором для лестниц, платформ и переходов

а) Исходные данные

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

б) Цели реализации KBE-приложения

Решением для реализации данного KBE-приложения явилось использование веб-конфигуратора сбыта и технического проектирования, предназначенного для всей цепочки процессов, включая веб-портал, который должен надежно регистрировать запросы клиентов в Интернете и автоматизировать процессы поступления/обработки коммерческих предложений и заказов, включая компиляцию торговой, конструкторской и производственной документации.

KBE-приложение обеспечивает возможность его простого и оперативного конфигурирования в Интернете непосредственно заказчиком и сотрудником отдела сбыта в режиме интерактивного диалога, проверяемого на достоверность. Высокий уровень одобрения KBE-приложения пользователем обеспечен благодаря простому и оперативному управлению процессом оформления коммерческого предложения и заказа. Определяющими факторами при решении вопроса о покупке становятся оперативное определение цены, а также наличие удобного для заказчика загрузочного портала, например для загрузки 3D CAD-моделей. С технической точки зрения центральная задача заключается в автоматическом формировании перечней элементов, информации о заказах, подробных 3D CAD-моделей и 2D CAD-чертежей на все отдельные детали и сборочные узлы (с прямым интерфейсом к ERP-системе).

Аналогичным образом все относящиеся к сбыту продукции результаты конфигурирования также представляют на портале (например, предложение цены, точно разделенные или усеченные 3D CAD-модели продаж). Сотрудники отдела сбыта могут обрабатывать и отслеживать заказы посредством портала «Отслеживание заказов». Так как разработчики приложения конфигуратора, как правило, проектировщики и инженеры, их работа упрощена благодаря использованию единой графической интерактивной системы авторизации. В целях дальнейшего развития и поддержания работы конфигуратора средства «классического» программирования не применяют.

в) Организация KBE-проекта и рассматриваемые области

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

• менеджмент;
• управление производством;
• сбыт и маркетинг;
• разработка и проектирование;
• производство;
• планирование работ;
• информационные технологии.

г) Реализация KBE-проекта

После отбора и обучения сотрудников выполнение всего проекта разбивают на следующие частично перекрывающиеся этапы:

• разработка концепции;
• реализация/внедрение;
• тестирование;
• развертывание проекта;
• планирование последующих проектов.

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

• задание параметров разработки, тестирования продуктивной системы;
• стандартизация продукции и формирование модульной конфигурации;
• определение характеристик продукции и входных параметров;
• организация рабочего процесса конфигурирования;
• представление структуры продукции;
• формирование и интеграция системы классов;
• формирование наборов правил и знаний о связях;
• проведение расчетов и ценообразования;
• определение структурных и объектных операций для управления системой отображения;
• подготовка основных производственных CAD-данных, совместимых с используемой конфигурацией и модулем;
• подготовка основных сбытовых CAD-данных (т.е. упрощенной CAD-модели для загрузки), совместимых с используемой конфигурацией и модулем;
• разработка руководства пользователя;
• определение результатов конфигурирования и подготовка документации;
• определение интерфейсов для CAD-, PDM- и ERP-систем;
• создание веб-портала и процесса пакетной обработки.

д) Знания и базы данных

База знаний включает в себя структуру изделия и характеристики, необходимые для описания изделий, а также их взаимовлияние и взаимозависимость (пространство решений). Отображение также показывает, в какой форме функции регистрируют/оценивают или документируют результаты конфигурирования. Каждый документ имеет особый вид представления изделия (например, CAD-данные). Применяют минимальный с позиции CAD-систем подход, основанный на четком разделении CAD-данных и знаний о правилах/отношениях. Конечный CAD-модуль отображен с помощью основных отдельных частей и подсборок, независимых друг от друга, с фиксированным и параметрическим контролем, а также с минимальной основной сборкой объекта верхнего уровня, для которого не определено никаких правил. Знания правил и отношений отображены исключительно с помощью системы авторизации. Конфигуратор посредством структурных и объектных операций, основанных на правилах, извлекает из эталонных моделей различные варианты (например, с измененными размерами, с вновь введенными, удаленными или замененными компонентами). «Интеллект» системы сохранен в наборе правил конфигурирования, что позволяет создать простую и совместимую с модулем модельную структуру базовых CAD-данных, а также ее комбинированное использование. В процессе конфигурирования или после него в пакетном режиме конфигуратор использует компонентную модульную систему (библиотеку с фиксированными и конфигурируемыми моделями, чертежами и элементами проектирования), выводя все необходимые компоненты, при необходимости изменяя и группируя их в сборки, а затем распечатывая соответствующие чертежи и перечни элементов. Данный принцип применяют как для дистанционного управления 3D CAD-системой, так и для управления веб-интегрированной 3D-системой просмотра.

е) Использованные средства реализации

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

ж) Затраты, выгоды, проблемы

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

УДК 658:330.341.1:001:330.111.4:0:006.354	ОКС 03.100.99
Ключевые слова: менеджмент знаний, система менеджмента знаний, менеджмент знаний в области инжиниринга

---