ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИ ЙСКОЙ ФЕДЕРАЦИИ

МЕНЕДЖМЕНТ ЗНАНИЙ

Менеджмент знаний в области инжиниринга

Часть 2

Проектирование на основе баз знаний

(VDI 5610-2:2017, NEQ)

Издание официальное

Москва

Стандартинформ

2018

Предисловие

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)

© Стандартинформ, оформление, 2018

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

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

6.1.2    Эксперт

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

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

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

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

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

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

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

ГОСТ P 57321.2—2018

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

6.2 Планирование КВЕ-проекта

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

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

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

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

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

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

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

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

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

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

-    принятия решения на основе экономической и технической реализуемости КВЕ-проекта.

Основной точкой сосредоточения внимания для проведения анализа в компании (в данном

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

9

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

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

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

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

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

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

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

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

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

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

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

6.3 Разработка КВЕ-проекта

6.3.1 Сбор знаний

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

ГОСТ P 57321.2—2018

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

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

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

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

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

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

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

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

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

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

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

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

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

-    типовые, рутинные задачи эксперта;

-    задачи с ограниченной исходной информацией;

-    задачи, на которые распространяются определенные ограничения, например по времени.

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

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

11

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

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

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

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

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

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

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

-    операции (виды деятельности), которые позволяют описывать последовательность/процессы использования КВЕ-приложения и которые в основном могут быть сохранены в виде процедурных правил (регламентов) и описаны в форме операторных логических взаимосвязей. Специалист по методам представления/использования знаний, как правило, формулирует фактический контент с помощью условного оператора (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 согласно процедуре (методологии) МОКА. Для применения представленной схемы в других проектах рекомендуется вносить в нее соответствующие изменения.

12

ГОСТ P 57321.2—2018

Процедура МОКА, система ICARE — ФОРМЫ: правило FORMS
Название		Смещение ступицы с вала при работе прессового соединения
Идентификатор		R34
Назначение		Предотвращение смещения при работе
Контекст		Фрикционное соединение с прессовой посадкой
Описание		Ступица будет сходить с вала, если отношение длины соединения If к его диаметру D/= будет менее или равно 1,5. Последнее применимо к прессовым соединениям, на которые действуют переменные или круговые крутящие изгибающие моменты
Связь с операциями		А04
Связь с правилами		—
Связь с ограничениями		С08
Связь с логическими объектами (сущно-		Е02, Ell, Е13
стями)
Связь с рисунками		109
Происхождение		—
Организация	Автор	Max Mustermann
	Дата	11.07.2014
	Версия	03.12
	Состояние	Законченное

Рисунок 4 — Пример представления правила, используемого в системе ICARE по методологии МОКА

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

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

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

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

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

- CAD-геометрия в виде:

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

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

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

-    состояния конструкции в подсборках (например, при различных вариантах сборки),

-    готовых шаблонов с контролем параметров (например, параметров сборки),

-    внутренних CAD-таблиц (например, расчетных таблиц, таблиц вариантов исполнения),

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

13

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

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

-    специализированные базы знаний в форме набора правил и ограничений;

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

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

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

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

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

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

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

ГОСТ P 57321.2—2018

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

CAD-система

КВЕ-приложение

	Геометрические характеристики		База знаний

а)

Рисунок 6 — Комплексный [интегрированный] (а) и комбинированный (б) подходы

б)

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

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

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

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

15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ P 57321.2—2018

Содержание

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

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

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

4    Возможности и риски КВЕ-проектирования...............................................2

5    Принципы КВЕ-проектирования........................................................4

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

7    Технические решения для КВЕ-проектирования..........................................20

ГОСТ P 57321.2—2018

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

МЕНЕДЖМЕНТ ЗНАНИЙ

Менеджмент знаний в области инжиниринга

Часть 2

Проектирование на основе баз знаний

Knowledge management. Knowledge management for engineering.

Part 2. Knowledge-based engineering

Дата введения — 2019—06—01

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

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

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

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

-    что такое КВЕ-проектирование, в каких областях его можно применять (или не применять) и в чем его цель?

-    какие группы сотрудников компании должны участвовать в КВЕ-проектах и их роли?

-    какие существуют типы КВЕ-приложений, как правильно выбрать соответствующее КВЕ-приложение для решения соответствующей проблемы и каким будет вводный сценарий для этого решения?

-    какие IT-средства необходимы, какие условия должны быть созданы в компании и какие ресурсы должны быть предоставлены?

-    каким образом можно оценивать преимущества использования КВЕ-приложений и эффективность затрат на их разработку [оценка по принципу соответствия затрат полученным результатам (выгодам)]?

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

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

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

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

Издание официальное

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

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

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

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

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

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

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

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

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

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

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

2 M_tK_A ^tr Dr(^ft-⁽i)p'

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

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

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

-    стандартизация;

-    автоматизация;

-    обеспечение и повышение качества;

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

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

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

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

ГОСТ P 57321.2—2018

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-    тип знаний (knowledge type). Данный параметр характеризует техническую/тематическую область знаний, т. е. область технических знаний, знания о продукции (изделии), методологию использования знаний и т. п.;

-    характер знаний (knowledge characteristic). Данный параметр описывает характерные свойства знаний (неявные, явные, индивидуальные, коллективные, внутренние, внешние и т. п.), которые отнесены к определенному типу знаний;

-    форма знаний (knowledge form). Данный параметр характеризует форму представления знаний, т. е. в виде текста, формулы, рисунка, правила и т. п.;

-    локализация знаний (knowledge location). Данный параметр характеризует место получения (источник) знаний — отдельный специалист, база данных, подразделение компании и т. п.;

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

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

-    точность;

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

-    полнота;

-    полезность;

-    достоверность.

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

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

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

4

ГОСТ P 57321.2—2018

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

-    этап «сбор знаний» (см. 5.2.1) служит для извлечения и сбора знаний из различных источников знаний, например от специалистов-экспертов, из литературных источников и электронной документации;

-    этап «интерпретация знаний» служит для анализа и структурирования собранных знаний, а также для их перевода в универсальную формальную модель процесса решения конкретных проблем в соответствующих КВЕ-приложениях. Знания могут быть выражены в различных представлениях (см. 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 = т-а). Рекомендуется различать геометрические и инженерные ограничения. Геометрические ограничения, как правило, присутствуют на чертежах (схемах) для однозначного определения уникальным образом расположенных (совпадающих в пространстве, параллельных, тангенциальных и т. п.) элементов (точек, прямых, окружностей и т. п.). Инженерные ограничения позволяют иллюстрировать формулы и сохранять конструкторские данные, например при проектировании деталей машин (см. правую часть рисунка 1);

-    прогностические модели (модели с предсказанием), получаемые по результатам интеллектуального анализа данных, регрессионных расчетов или моделирования нейронных сетей, также следует считать ограничениями;

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

Отклонение несущей балки, зажатой с одного конца

F-L³

^wmax ъ.р.т

M=F-L o = -j£. где w = — vv е

Рисунок 1 — Примеры различных форм представления знаний (слева — пример для представления правил, справа — пример для представления ограничений)

Действие крутящего момента и изгибающего усилия в точке зажатия балки

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

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

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