Информационные технологии, используемые при моделировании в метрологии

Неоднозначность многомерного образа действительности с использованием векторных статистических моделей

ИТ, используемые при моделировании измерительных систем, относятся к классу CALS - технологий, расширивших границы применения от «автоматизированной поддержки логистических систем» (Computer-Aided Logistics Support) до «непрерывной информационной поддержки жизненного цикла продукта» (Continuous Acquisition and Life Cycle Support). В широком смысле CALS – идеология компьютерной автоматизации всех процессов и всех видов деятельности, включая разработку, производство, эксплуатацию и т.д., направленная на повышение их результативности и эффективности. Стандарты и методические материалы CALS – технологий, в основном, определяют общий подход, способ представления и интерфейсы доступа к данным различного типа.

Наиболее детально проработан раздел этих технологий, которые называется методологией структурного системного анализа и проектирования (Structured Analysis and Design Technique, SADT). Это название было дано части теоретических разработок, относящихся к методологии и языкам описания систем, их автором, Дугласом Т. Россом. Исходная работа над SADT началась в 1969 г. Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта. В 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими такие области, как телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных. SADT выделяется среди современных методологий описания систем своей универсальностью и широким применением.

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

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

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

Современный уровень информационных технологий предоставляет богатый выбор методов для создания автоматизированной поддержки SADT.

Наиболее программно обеспеченным на сегодняшний день SADT- средством является Design/IDEF, изначально построенный в рамках программы интегрированной компьютеризации производства, а сейчас широко используемый в различных областях. Автоматизированная поддержка SADT усложнилась от графического средства до программного обеспечения, опирающегося на общие понятия моделирования. Такие развитые средства обладают способностью понимать семантику взаимосвязанной сети диаграмм SADT и множества моделей, а также объединять это множество сведений и правил с другими технологиями. К таким средствам, например, относится методология графического структурного анализа, называемая

В измерительных системах для описания процесов передачи данных (результатов измерения, результатов расчета) можно использовать методологию построения диаграмм потоков данных (Data Flow Diagrams, DFD). Диаграммы потоков данных предназначены для описания информационной части систем, они описывают внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ.

В 1990-е г. часть методологии SADT была стандартизована и опубликована по названием методологии функционального моделирования (Integration Definition for Function Modeling, IDEF) [8-10]. Методология функционального моделирования хорошо согласуется с такими принципами, на которых основываются системы качества, как процессный и системный подходы и, по сути, является их графической интерпретацией.

В настоящее время система стандартов по функциональному моделированию включает несколько стандартов:

· IDEF 0, в этом стандарте приводится совокупность правил и приемов, которые используются для создания функциональной модели бизнес- процессов системы;

· IDEF 1, этот стандарт раскрывает методологию моделирования информационных потоков внутри системы;

· IDEF 2, называется методологией динамического моделирования систем;

· IDEF 3, в этом стандарте предлагаются методы документирования процессов, составляющих систему, с использованием диаграмм потоков событий (Work Flow Diagram, WFD), эти методы позволяют указывать взаимосвязи между процессами, отражать функции системы в их временной последовательности;

· IDEF 4, рассматриваемые в рамках этого стандарта средства позволяют наглядно отображать структуру анализируемых объектов и взаимосвязи между составляющими элементами; а также стандарты IDEF 5, IDEF 6, IDEF 8 – 14. Все перечисленные методики и стандарты были разработаны в США, но в настоящее время им пытаются придать статус международных стандартов.

Графический язык IDEF 0 прост и логичен. Основой является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и подразумевает конкретную функцию, процесс рассматриваемой системы, по требованиям стандарта название каждого функционального блока должно быть сформулировано глаголом. Каждая из четырех сторон функционального блока имеет своё определенное значение (рис. 5.1), при этом верхняя сторона имеет значение “управление” (Control), левая сторона имеет значение “вход” (Input), правая сторона имеет значение “выход” (Output), нижняя сторона имеет значение “механизм, ресурсы для преобразования” (Mechanism).

Рис. 5.1. Описание процесса системы с использованием методов стандарта IDEF 0

Вторым “китом” методологии IDEF 0 является понятие интерфейсной дуги, (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое наименование (Arrow Label). По требованию стандарта наименование должно быть оборотом существительного.С помощью интерфейсных дуг отображают различные материальные или информационные объекты, в той или иной степени определяющие процессы, происходящие в системе.

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

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

Обычно IDEF 0-модели несут объемную информацию, и для того, чтобы ограничить их перегруженность и сделать более удобными, в стандарте приняты ограничения сложности моделей процессов:

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

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

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

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

Теоретическими основами оценки стабильности выходных качественных характеристик продукции или услуг, т.е. стабильности функционирования системы качества на предприятии или в организации, могут быть методы статистического контроля процессов [11,12], теория параметрической надежности,

Для оценки погрешностей в измерительных системах также может быть использован метод анализа видов и последствий отказов (дефектов) (Failure mode and Effects Analyses, FMEA), являющийся разделом методологии вероятностной оценки риска (Probabilistic Risk Assesment,PRA) [13].

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

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

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

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

FMEA -анализ включает определенные этапы:

· построение компонентной, структурной, функциональной и потоковой моделей объекта анализа (процесса системы качества); возможно использование моделей, построенных другими методами;

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

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

· разработку корректирующих мероприятий и последующий анализ.