ЛОЦМАН:PLM Архитектурное проектирование
Программа для ЭВМ «ЛОЦМАН:PLM Архитектурное проектирование» для ЛОЦМАН:PLM (далее ЛОЦМАН:PLM АП, ПО) — это первая в своем роде отечественная интегрированная инженерная среда, обеспечивающая цифровую связь между процессами системной инженерии и классического проектирования (разработка РКД), которую инженеры могут использовать для реализации подходов моделе-ориентированной системной инженерии к процессам проектирования.
Приложение «ЛОЦМАН:PLM Архитектурное проектирование» — это мощный инструмент для проектирования систем, как аппаратных, так и программных, основанный на принципах модельно-ориентированной системной инженерии (MBSE). Оно помогает инженерам четко и формализовано описать принципы реализации системы, ее компонентов, а также их взаимодействие как между собой, так и с окружающей средой. Эти описания формируются в виде формальных моделей, которые строго соответствуют методу Arcadia.
Приложение «ЛОЦМАН:PLM Архитектурное проектирование» — это мощный инструмент для проектирования архитектуры технических систем, как аппаратных, так и программных, основанный на принципах моделе-ориентированной системной инженерии (MBSE). Оно помогает инженерам четко и формализовано описать принципы реализации системы, ее компонентов, а также их взаимодействие как между собой, так и с окружающей средой. Эти описания формируются в виде формальных моделей, которые строго соответствуют методу ARCADIA.
Цель применения «ЛОЦМАН:PLM Архитектурное проектирование» - помочь инженерам описать принципы реализации системы и ее компонентов, их взаимодействие как между собой, так и с окружающей средой. Эти описания формируются в виде формальных моделей, обеспечивающих однозначность их интерпретации всеми заинтересованными сторонами, а также возможность их машинной обработки.
Основные возможности ЛОЦМАН:PLM Архитектурное проектирование
«ЛОЦМАН:PLM Архитектурное проектирование» поддерживает практику описания области проблем. Инструмент позволяет определить и зафиксировать все заинтересованные стороны (в терминологии ARCADIA — «акторы»), которые будут взаимодействовать с будущей системой, а также их потребности, проблемы, мотивы, цели, задачи, намерения и т.д. в форме возможностей применения.
ЛОЦМАН:PLM Архитектурное проектирование позволяет зафиксировать окружение проектируемой системы, и в дальнейшем описать интерфейсы для взаимодействия между проектируемой системой и ее окружением. В качестве окружения проектируемой системы рассматриваются акторы (включающие, помимо заинтересованных сторон, еще и явления или предметы материального мира, например ветер или атмосферное давление), фиксируемые на диаграмме типа «Системные акторы».
ЛОЦМАН:PLM Архитектурное проектирование представляет несколько видов диаграмм последовательностей (UML/SysML) или в нотации ARCADIA - «Сценарий»: функциональные сценарии (линии жизни являются функциями), сценарии обмена (линии жизни являются компонентами/акторами, а сообщения последовательности являются межфункциональными или межкомпонентными обменами), сценарии интерфейсов (линии жизни являются компонентами/акторами, сообщения последовательности являются операциями интерфейсов). Режимы, состояния и функции также могут быть отображены на диаграммах данного типа.
ЛОЦМАН:PLM Архитектурное проектирование позволяет описать как взаимодействую и чем обмениваются между собой функции. Кроме того, каждая функция может быть декомпозирована на подфункции, с описанием их взаимодействия.
Пример описания межфункционального взаимодействия с декомпозицией функции "Обнаружение сбоев".
Описание функциональных цепей позволяет увидеть порядок взаимодействия и выполнения функций в рамках какого-либо сценария, в контексте распределения функций на системные компоненты. Например порядок выполнения функций для мониторинга состояния двигателя или порядок выполнения функций по управлению двигателем.
Для того чтобы продемонстрировать процесс распределения функций компонентам согласно методу ARCADIA в ЛОЦМАН:PLM Архитектурное проектирование используются диаграммы типа "Архитектура".
На уровне анализа применения на диаграммах данного типа фиксируют распределение действия по акторам, для того чтобы лучше понимать контекст будущей системы.
На уровне системного анализа эти диаграммы служат для отображения распределения функций между проектируемой системой и ее окружением (акторами).
На уровне логической архитектуры диаграммы данного типа показывают во первых из каких систем и компонентов (строительных блоков системы) будет состоять проектируемая система, так же распределение функций системы по ее подсистемам и компонентам.
На уровне физической архитектуры используя архитектурные диаграммы, можно отобразить распределение компонентов поведения (в неком роде логические компоненты) по компонентам реализации.
Компоненты системы, представленные в описании архитектуры на разных уровнях абстракции (функция, физический компонент поведения, физический компонент реализации), могут обмениваться друг с другом различными сущностями (энергия, информация, вещество). ЛОЦМАН:PLM Архитектурное проектирование позволяет описать варианты и способы межкомпонентных взаимодействий.
На рисунке показан пример, в котором зафиксировано, что между функцией "Хранить масло" и функцией "Перекачивать масло", на уровне межфункционального обмена осуществляется обмен веществом - масло, а на уровне физических компонентов поведения "Масляный бак" и "Масляный насос" определен обмен непрерывным потоком масла. На уровне физических компонентов реализации так же осуществляется обмен непрерывным потоком масла, который реализуется через физическую связь "Трубопровод".
Диаграммы "Режимы и состояния", реализуемые средствами ЛОЦМАН:PLM Архитектурное проектирование, похожи на аналогичные диаграммы в SysML. Дополнительно к SysML, в ЛОЦМАН:PLM Архитектурное проектирование, добавлена некоторая семантика (различие между режимами и состояниями, взаимосвязь с функциональным анализом и интерфейса.
Хотя это и не является официальной частью метода ARCADIA, но используя функционал диаграмм типа «Режимы и Состояния» можно зафиксировать в инструменте схему жизненного цикла проектируемой системы и связать с каждым из этапов ЖЦИ функции которые должна будет реализовывать проектируемая система.
Функционал ЛОЦМАН:PLM Архитектурное проектирование обеспечивает выделение (переход от системы к подсистеме), из проекта по разработке системы, ее подсистемы в отдельные MBSE-проекты для их последующей более детальной проработки.
Переходы от одной системы к ее подсистеме носит нисходящий и итеративный характер: любое изменение, внесенное в исходную систему, может быть в любой момент распространено на подсистему. Прослеживаемость между системой и подсистемой обеспечивается механизмом, основанным на общесистемных идентификаторах.
Существует два вида переходов от системы к подсистеме:
Цель этого перехода — выделить с уровня логической или физической архитектуры какую-либо подсистему в отдельный проект и возможно проработать там альтернативный вариант архитектуры, а затем используя функционал "слияния/различий" объединить их в один проект.
- Вертикальный переход СА
Целью данного перехода является повторное применение метода ARCADIA , начиная с одного или нескольких заданных элементов.
- Вертикальный переход СА-ЛА-ФА
Принцип перехода заключается в выборе одного или нескольких физических компонентов из исходной модели (проекта системы) и создании (или обновлении) целевой модели (подсистемы).
В ходе перехода будет автоматически создана целевая модель (проект подсистемы), и в её три архитектурных уровня (системный анализ, логическая архитектура и физическая архитектура) будут добавлены новые объекты ЛОЦМАН:PLM Архитектурное проектирование, связанные с объектами исходной модели (проект системы).
Пример вертикального перехода СА-ЛА-ФА в модели:
ЛОЦМАН:PLM Архитектурное проектирование является внешним приложением относительно ЛОЦМАН:PLM, однако благодаря интеграции, две эти системы обмениваются необходимыми данными и обеспечивают управляемый процесс определения архитектуры технических систем.
Функционирование «ЛОЦМАН:PLM Архитектурное проектирование» в режиме интеграции с ЛОЦМАН:PLM позволяет связать описание архитектуры изделия в виде модели с другой инженерной информацией, хранящейся в ЛОЦМАН:PLM (требования, характеристики, объекты электронной структуры и др.), использовать описание архитектуры как исходные данные для последующих процессов проектирования, управлять описанием архитектуры и сделать ее частью конфигурации изделия.
Наличие интеграции между двумя инструментами обеспечивает ЛОЦМАН:PLM новыми данными, ранее отсутствовавшими как объекты PDM-системы:
Функционал интеграции ЛОЦМАН:PLM и ЛОЦМАН:PLM Архитектурное проектирование обеспечивает:
ЛОЦМАН:PLM хранит и управляет доступом к файлу проекта ЛОЦМАН:PLM Архитектурное проектирование, на основании настроенной ролевой модели. Результат описания архитектуры сохраняется в ЛОЦМАН:PLM и при необходимости продолжить работу открывается из ЛОЦМАН:PLM.
ЛОЦМАН:PLM не просто хранит проект описания архитектуры но представляет содержимое проекта в виде объектной модели ЛОЦМАН:PLM. При сохранении проекта архитектуры в ЛОЦМАН:PLM происходит:
- публикация данных с выбранных уровней описания архитектуры;
- представление описания архитектуры в ЛОЦМАН:PLM в виде объектов, их атрибутов и информационных связей, в строгом соответствии с иерархией данных в проекте «ЛОЦМАН:PLM Архитектурное проектирование»;
- формирование перечня диаграмм и их вторичного представления в формате PDF.
Например, иерархическая структура функций из ЛОЦМАН:PLM Архитектурное проектирование, будет представлена в ЛОЦМАН:PLM как дерево специальных объектов (функция) с сохранением всей иерархии.
По мимо объектного представления данных, ЛОЦМАН:PLM визуализирует диаграммы, разработанные в ЛОЦМАН:PLM Архитектурное проектирование, в виде файлов формата PDF.
Используя функционал аннотирования и замечаний ЛОЦМАН:PLM, можно давать комментарии к диаграммам в процессе проверки и согласования.
Требования и характеристики, зафиксированные в ЛОЦМАН:PLM, могут быть перенесены в описание архитектуры в ЛОЦМАН:PLM Архитектурное проектирование, виде отдельных объектов и быть связаны с другими объектами описания архитектуры. Например, вы можете указать в какой функции реализуется конкретное требование, или указать какое требование предъявлено к конкретному физическому компоненту.
Для переноса требований могут использоваться:
- метод drag&drop
При создании трассировок доступен выбор направления трассировки
Входящее – означает, что элемент системной архитектуры был разработан на основе требования.
Порожденное – означает, что требование было порождено в результате работы над системной архитектурой.
- Окно выбора требований из ЛОЦМАН:PLM
В приложении ЛОЦМАН:PLM Архитектурное проектирование поддерживается двух сторонняя интеграция с ЛОЦМАН:PLM, тем самым при изменении атрибутов у объектов в одном из инструментов возможно их обновление в другом.
Например в ЛОЦМАН Архитектурное проектирование для этих целей используется команда "Обновить выделенные объекты из ЛОЦМАН:PLM".
Если объекты описания архитектуры в ЛОЦМАН:PLM, получают состояние запрещающее их редактирование, соответствующие объекты в ЛОЦМАН:PLM Архитектурное проектирование получат индикатор указывающий на их защиту от редактирования и пользователь не сможет их изменить.
Если системная архитектура уже экспортирована в ЛОЦМАН:PLM, то используя команду «Открыть в ЛОЦМАН:PLM» Вы можете отобразить любой элемент системной архитекторы в ЛОЦМАН:PLM
Одна из самых привлекательных особенностей ЛОЦМАН:PLM Архитектурное проектирование - это встроенный обозреватель действий, который предоставляет пользователям руководство по основным принципам метода ARCADIA. Обозреватель действий обеспечивает методический доступ ко всем ключевым действиям ЛОЦМАН:PLM Архитектурное проектирование. Это главная точка входа в модель, которая предназначена как для новичков, так и для опытных пользователей.
Поскольку графическое представление элементов играет решающую роль в коммуникации, ЛОЦМАН:PLM Архитектурное проектирование опирается на согласованную цветовую схему. В частности, все функциональные элементы выделены зеленым цветом, а элементы, относящиеся к компонентам - голубым. Это способствует повышению читаемости модели для всех заинтересованных сторон (архитекторов, специалистов по верификации и валидации, инженеров по специальностям, менеджеров и т.д.).
Более полезный, чем стандартное иерархическое представление модели, семантический браузер мгновенно предоставляет контекст элементов модели через запрос. Это предпочтительный способ навигации по моделям и диаграммам, а также для про-ведения быстрого анализа взаимосвязей между элементами модели.
Благодаря полной интеграции с методом ARCADIA, ЛОЦМАН:PLM Архитектурное проектирование предлагает функциональность недоступную в традиционных инструментах моделирования. Например, ЛОЦМАН:PLM Архитектурное проектирование может проверить, реализованы ли элементы модели на заданном уровне абстракции на следующем, более низком уровне. ЛОЦМАН:PLM Архитектурное проектирование классифицирует проверки модели по таким группам правил как:
- Качество
- Переход
- Проектирование
- Расширенные правила
- Целостность
Системные архитекторы могут самостоятельно определять необходимые в данный момент профили проверки, путем выбора определенных комбинаций правил.
После запуска заранее настроенного профиля проверки, пользователь получает отчет в виде таблицы с указание проблемного объекта и типа правила которому он не удовлетворяет.
Функционал ЛОЦМАН:PLM Архитектурное проектирование по проверки модели, для ряда правил может предложить пользователю решения по исправлению допущенных ошибок в ходе разработке модели.
ЛОЦМАН:PLM Архитектурное проектирование имеет в своем арсенале автоматизированные контекстно-зависимые диаграммы, содержимое которых автоматически обновляется в соответствии с предварительно выбранными элементами и предопределенными семантическими правилами.
К контекстно-зависимым диаграммам относятся диаграммы типа: "Иерархическая структура", "Системные акторы" и т.д.
Кроме того ЛОЦМАН:PLM Архитектурное проектирование обладает широкой функциональностью по работе с отображением элементов на диаграммах:
- Синхронизация/десинхронизация диаграмм: обеспечивает тонкий уровень контроля над элементами, которые семантически отображаются или нет (порты функций, межкомпонентные обмены, свойства классов и т.д.).
- Фильтры помогают улучшить читаемость диаграмм путем выбора параметров отображения и автоматического срытия/показа элементов.
- Слои – это средства настройки графического отображения элементов на диаграмме на основе различных интересов (например, специальных точек зрения).
Еще одна продвинутая функция ЛОЦМАН:PLM Архитектурное проектирование - это возможность создания многократно используемых элементов модели, которые могут представлять из себя как простые объекты типов или классов так и полноценные физические компоненты с портами и функциями.
Копируемая коллекция элементов (REC) - это определение элементов, которое можно повторно использовать в различных проектах, а копия (RPL) - это экземпляр REC. REC можно упаковывать в виде внешних библиотек и использовать совместно в нескольких проектах.
Библиотека — это MBSE-модель, предназначенный для совместного использования в нескольких проектах.
Проект может ссылаться на библиотеку в режиме ЧТЕНИЕ или ЧТЕНИЕ/ЗАПИСЬ. В последнем случае это означает, что содержимое библиотеки можно изменять в самом проекте, без необходимости открывать библиотеку.
Библиотека может содержать ссылки на другие библиотеки, но библиотека не может содержать ссылку на проект.
Назначение библиотек:
- Обеспечение повторного использования элементов модели в различных MBSE-проектах (например, нескольким проектам в одной области часто требуется одна и та же модель данных).
- Организация каталогов повторно используемых моделей.
Проблемы, решаемые с помощью ЛОЦМАН:PLM Архитектурное проектирование
Применение ЛОЦМАН:PLM Архитектурное проектирование позволяет решить следующие проблемы, возникающие в процессе проектирования сложных технических систем:
Ни электронный макет, ни электронная структура изделия не способны описать сценарии работы сложной мехатронной системы и ее компонентов, описать путь электрического сигнала от датчика к системе управления, логику его обработки и дальнейший путь к исполнительным органам оборудования.
Такие сведения фрагментированы по различным текстовым документам, например пояснительным запискам, или графическим документам, например схемам. Данные, содержащиеся в таких документах, не ассоциативны и ничего не знают про изменения, а значит, с высокой долей вероятности могут быть неактуальными.
Управление такими документами в PDM-системе не решает задачу актуальности данных. PDM-система может гарантировать, что вы работаете с актуальным документом, но не может гарантировать, что данные внутри документа актуальны.
Кроме того, информация о принципах работы и устройства изделия, заключенная в документах, не имеет единой формальной нотации описания, а значит, не обеспечивает однозначность интерпретации этих данных и их машиночитаемость — возможность быть распознанной программами в качестве входных данных.
В результате у инженеров нет единого, актуального и непротиворечивого источника истины, описывающего, каким изделие задумано и как оно устроено, со всеми вытекающими отсюда последствиями.
Описание архитектуры в ЛОЦМАН:PLM Архитектурное проектирование решает эту проблему. С помощью этого инструмента создается описание архитектуры в виде модели, которое содержит:
- Описание всех компонентов проектируемой системы вне зависимости от способов их реализации: механика, электрика, электроника, программное обеспечение.
- Описание взаимодействия компонентов друг с другом, например:
- как система управления взаимодействует с объектом управления;
- как электрические системы взаимодействуют с электронными блоками и датчиками;
- как система взаимодействует с окружением;
- тепловое и электромагнитное воздействие одних компонентов на другие;
- как отказ одной системы или компонента приводит к отказу других. - Описание сценариев работы системы и ее компонентов, например:
- сценарии работы системы при изменении давления в тормозной системе;
- сценарий работы системы при снижении уровня заряда батареи;
- сценарий работы при зарядке электромобиля;
- последовательность выполнения функций при выполнении того или иного сценария работы.
Вся описанная информация содержится в едином источнике данных, а не разбросана по пояснительным запискам или отдельным схемам. Это значит, что:
- Все участники процесса проектирования, работая с описанием архитектуры, используют актуальные данные о принципах устройства и работы изделия.
- Принципы работы и устройства изделия доступны всем участникам процесса проектирования, а не только живут в голове главного конструктора.
- При необходимости формирования документов, например пояснительных записок, они формируются преимущественно автоматически как отчеты по описанию архитектуры и имеют актуальное содержание.
- Изменения сначала вносятся в модель с изменением всех зависимых объектов, и только потом на основе этих данных обновляются отчетные документы. Это гарантирует отражение изменений во всех зависимых документах.
Описание принципов устройства и работы изделия фрагментировано по пояснительным запискам и схемам, не имеющим информационных связей.
При необходимости внесения изменений требуется длительная и трудоемкая ручная оценка влияния изменений. Такая оценка из-за недостаточности времени часто носит субъективный характер и не отражает всех последствий изменений.
В результате внесенное изменение может привести к неожиданным результатам: неработоспособности изделия в целом или лавине вторичных изменений.
После выявления всех зависимостей требуется не менее трудоемкий процесс внесения изменений. При множественном использовании одних и тех же данных в различных документах есть риск, что изменения в одном документе не будут отражены в другом документе.
При использовании ЛОЦМАН:PLM Архитектурное проектирование принцип устройства и работы мехатронной системы описан в рамках единой модели, которая обеспечивает:
- Быстрый и объективный анализ всех взаимосвязей элементов модели: где и как реализуется изменяемое требование, какие функции еще выполняет заменяемый компонент, с чем еще взаимодействует изменяемый компонент и так далее.
- Формирование пояснительных записок и схем в виде отчетов по архитектурной модели. Все изменения в модели автоматически отражаются в отчетах при их переформировании.
Результат:
- Снижение трудоемкости процесса анализа влияния изменений.
- Повышение качества анализа влияния изменений.
- Сокращение трудоемкости внесения изменений.
- Минимизация невнесенных изменений.
- Сокращение количества вторичных изменений.
Сложность проекта складывается из множества составляющих:
- Количество систем, компонентов и их разнородность — чем их больше, тем сложнее проект.
- Количество предъявляемых требований — чем их больше, тем сложнее проект.
- Степень новизны применяемых инженерных решений, например применение в автомобиле системы автопилота, переход с ДВС на тяговые электродвигатели, переход на водородные топливные ячейки и другие.
ЛОЦМАН:PLM Архитектурное проектирование позволяет скрывать сложность, используя иерархию и абстракцию. Можно посмотреть на изделие как на черный ящик, а затем «погрузиться» на следующий уровень детализации, не теряя связей с верхнеуровневыми целями.
ЛОЦМАН:PLM Архитектурное проектирование позволяет скрывать сложность через управление точками зрения на изделие. Описание архитектуры может быть сделано таким образом, что разные интересы заинтересованных сторон описываются разными диаграммами или их совокупностью, например:
- Описание архитектуры с точки зрения выполнения основных операционных возможностей, например как должно быть устроено изделие, чтобы реализовать возможности:
- перевозки пассажиров по маршруту;
- обеспечения комфортных условий;
- информирования пассажиров;
- зарядки электробуса;
- технического обслуживания.
На каждую из возможностей разрабатывается отдельный набор диаграмм, описывающих только ее реализацию. Это позволяет сохранить фокус на решении поставленных задач, а не распыляться сразу на все.
К примеру, описание архитектуры с точки зрения технического обслуживания отображает только те элементы модели, которые описывают, как в изделии реализуются требования к техническому обслуживанию.
При этом все элементы диаграмм — это часть общей модели. Создавая функцию «Подъем пантографа» на диаграмме «Архитектура зарядки электробуса», эта функция становится частью общей модели и может использоваться на диаграмме «Посадка-высадка пассажиров».
- Описание архитектуры с точки зрения функциональной безопасности отображает функции, их отказы и последствия. Содержит информацию о реализации функций в системных компонентах, требованиях безопасности и способах выполнения требований безопасности: резервирование каналов, дублирование функционала и так далее.
Большинство проблем проектирования сложных технических изделий возникает на стыке систем — интерфейсах.
Интерфейс — совокупность средств, методов и правил, обеспечивающая взаимодействие между двумя или более составными частями изделия или между изделием и внешними по отношению к нему объектами.
ГОСТ 59193-2020, п. 3.1.6
-
Несовпадение интерфейсов
Проблема в том, что в результате проектирования системы имеют различные интерфейсы.
Интерфейсы могут отличаться как на физическом уровне, например UART или CAN, USB или Type-C, так и на уровне сигналов и данных, что отследить гораздо сложнее.
Пример: система А отправляет давление как float — число с плавающей точкой: 101.325 кПа. Система Б ожидает получить int — целое число: 101 кПа. В результате происходит потеря точности, где 0.325 кПа может быть критично. В худшем случае возможен системный сбой из-за несовпадения типов.
-
Изменения интерфейсов
Интерфейсы меняются, и это нормально для инженерных проектов, особенно с высокой долей новизны технических решений. Однако изменения интерфейса могут быть не учтены разработчиками смежных систем.
В результате две подсистемы, разработанные параллельно, становятся несовместимыми. Интеграция превращается в выяснение отношений «кто виноват» и авральную переделку уже готовых составных частей изделия.
Пример: инженер изменил протокол связи с UART на CAN. Он обновил свою схему, но забыл или не счел нужным уведомить об этом разработчика платы расширения. Тот продолжает проектировать свою систему под UART. В результате взаимодействие систем будет невозможно.
-
Семантическая неоднозначность интерфейсов
Даже если типы данных совпадают, смысл, вкладываемый разными инженерами в один и тот же сигнал, может кардинально различаться. Это особенно актуально, когда интерфейсы находятся на стыке разных инженерных дисциплин: механики, электроники, программного обеспечения. У каждой из этих дисциплин сложились свои профессиональные термины.
Пример: в документации написано: «Интерфейс "Статус двигателя" передает значения 0, 1, 2».
Инженер-механик думает: «0 — выключен, 1 — включен, 2 — неисправен».
Инженер-программист думает: «0 — норма, 1 — предупреждение, 2 — ошибка».
Система будет работать, но непредсказуемо. Аварийная логика запустится не в тот момент или не запустится вообще. Найти причину такого поведения крайне сложно, потому что формально интерфейс работает — цифры передаются.
-
Динамическая несовместимость интерфейсов
Системы могут быть идеально совместимы по типам данных и протоколам, но не работать из-за рассогласования во времени.
Пример: подсистема А выдает данные каждые 10 мс. Подсистема Б ожидает данные каждые 100 мс. Блок Б либо «захлебнется» потоком и потеряет часть данных, либо будет простаивать и потеряет актуальность данных.
При этом система работает, но с ошибками или потерей производительности. Диагностировать это сложно, потому что ошибка может быть «плавающей». Такие проблемы особенно актуальны в системах реального времени: управлении двигателем, обработке видеопотока, телеметрии.
-
Потеря прослеживаемости
Интерфейс редко бывает «сам по себе». Он всегда порожден каким-то требованием, например «измерять температуру», и реализован в каком-то компоненте, например «датчик DS18B20». В документации эта связь часто теряется.
В результате вы не можете проверить, действительно ли данный интерфейс реализует исходное требование. Также вы не можете оценить «ущерб» от изменения этого интерфейса.
Пример: в техническом задании сказано: «Система должна аварийно останавливаться при перегреве». Инженер создал сигнал «Temp_Alarm». Программист его принял. Через полгода выясняется, что сигнал срабатывает при 100°C, а требовалось при 80°C. Никто не может доказать, где возникло расхождение.
Описанные проблемы:
- обнаруживаются на этапе интеграции и тестирования, когда все уже построено;
- стоят очень дорого: перепроектирование, переделка плат, переписывание кода, сдвиг сроков;
- порождаются не «злым умыслом», а разрывом коммуникации и отсутствием единого формального языка для описания интерфейсов на всех уровнях.
Обозначенные проблемы решаются с помощью ЛОЦМАН:PLM Архитектурное проектирование, который обеспечивает:
- Создание единой для всех соразработчиков модели изделия, в которой описаны интерфейсы систем, в том числе порты и связи.
- Возможность настройки специализированных автоматизированных проверок соответствия интерфейсов.
- Централизованное внесение изменений.
- Связь требования и реализующего интерфейса, в том числе анализ покрытия интерфейсов требованиями.
Часть данных, описывающих принципы устройства и работы изделия, может вовсе не формализоваться ни в пояснительных записках, ни в других документах, например:
-
Функции изделия и его составных частей, их взаимодействия, отказы и последствия, которые могут использоваться при оценке функциональных опасностей.
-
Окружение системы, необходимое для понимания на ранних стадиях проектирования, с чем система будет или может взаимодействовать, чтобы не столкнуться с непредвиденными факторами на поздних стадиях.
-
Неочевидные форматы взаимодействия компонентов.
Например, на чертеже отражается, что вал соединен с шестерней через шпоночное соединение. В пояснительной записке отражены частота вращения вала и величина крутящего момента.
Но нигде может быть не отражено, что при вращении от вала на шестерню передаются температура от редуктора и вибрации. О таких взаимодействиях, не учтенных при проектировании, могут вспомнить только на натурных испытаниях и столкнуться с необходимостью изменения конструкции.
-
Сценарии работы, которые нужны для валидации требований и правильной интерпретации того, как изделие должно работать.
Техническое задание далеко не всегда гарантирует, что все зафиксированные в нем требования отражают истинные потребности заказчика.
-
Для описания сценария взаимодействия компонентов используются сами компоненты, описание их связей, межкомпонентных обменов и другие данные.
Если при описании сценария не хватает данных, значит, что-то не было зафиксировано в модели: например, какая-либо связь, функция или компонент.
Бумага стерпит такую ситуацию, так как при описании принципов работы изделия не нужно использовать ранее введенные в текст слова. Модель потребует корректировки, создания нужных объектов и их связей.
При этом можно обнаружить конфликты или другие недоработки, которые в тексте выявить гораздо сложнее.
ЛОЦМАН:PLM Архитектурное проектирование позволяет зафиксировать всю необходимую информацию о принципах устройства и работы изделия и сделать ее единой для всех участников проектирования.
Для выявления требований к изделию или его составным частям, как правило, используется экспертный метод, который может дополняться:
- бенчмаркингом;
- опытом предыдущих проектов;
- мозговым штурмом;
- интервьюированием потенциальных заказчиков.
Обозначенные методики не имеют достаточной системности и структурированности для того, чтобы обеспечить полноту требований к разрабатываемой системе.
В результате техническое задание на изделие в целом или его составные части может быть неполным. В нем могут отсутствовать важные требования, которые впоследствии приведут к дорогостоящим изменениям.
Для обеспечения полноты требований необходимо использовать дополнительные методики:
- моделирование;
- разработка сценариев эксплуатации;
- трассировка.
Данные методики требуют инструментальной поддержки. Именно такую поддержку оказывает ЛОЦМАН:PLM Архитектурное проектирование.
В части выявления требований ЛОЦМАН:PLM Архитектурное проектирование в связке с ЛОЦМАН:PLM позволяет:
-
Увидеть новые требования на основе анализа диаграмм описания архитектуры.
-
Увидеть элементы архитектуры, не имеющие требований, а значит минимизировать число упущенных требований через трассировку требований на элементы архитектуры и отчет об отсутствующих связях.
-
Валидировать исходные требования, то есть подтвердить их обоснованность, через трассировку требований на сценарии эксплуатации или на элементы анализа применения.
Текстовое изложение требований или описание сценария работы компонентов с использованием естественного языка может содержать логические ошибки и противоречия.
Такая информация может быть неправильно интерпретирована исполнителями, что приведет к результату, отличному от ожидаемого. Наличие дополнительных пояснений к требованиям в виде схемы или рисунка не всегда достаточно для правильной интерпретации.
ЛОЦМАН:PLM Архитектурное проектирование переводит естественный язык текстового описания в формальный язык моделирования, для которого определены четкие правила. Эти правила могут быть проверены автоматически.
Информация в модели строго формализована в виде информационных объектов: требований, функций, компонентов, интерфейсов, их атрибутов, взаимосвязей и правил.
Отсутствие описания принципов работы сложной технической системы и уход опытных инженеров приводят к необходимости заниматься инженерной археологией — разбираться в том, что было сделано когда-то давно другими инженерами.
При правильном и последовательном использовании создание моделей в ЛОЦМАН:PLM Архитектурное проектирование может стать эффективным способом извлечения и систематизации запутанных «сакральных знаний» о проектируемых системах или о работе оборудования компании.
Такие знания часто фрагментированы и находятся в головах отдельных инженеров.
Описание технической системы в виде архитектуры позволяет:
-
Зафиксировать важные аспекты технической системы в виде модели с однозначной нотацией:
- эксплуатирующую систему;
- сценарии эксплуатации;
- взаимодействия, в том числе неочевидные, между составными частями изделия;
- требования к составным частям изделия. -
Обеспечить однозначность интерпретации этих данных для всех заинтересованных сторон.
Как результат — исключить потерю данных, необходимых для последующей эксплуатации, ремонта, воспроизведения и модернизации технической системы.
Обратная разработка, или обратный инжиниринг, реверс-инжиниринг, — это исследование готового устройства или программы, а также документации на него с целью понять принцип его работы.
Например, чтобы обнаружить недокументированные возможности, внести изменения или воспроизвести устройство, программу или иной объект с аналогичными функциями.
Тема обратной разработки особенно актуальна на волне импортозамещения, ухода зарубежных производителей и поставщиков. Многие наивно думают, что для этого достаточно 3D-сканера и штангенциркуля. Но все проблемы — в нюансах:
- почему у детали именно такая форма;
- почему у трубки именно такой диаметр;
- для чего нужна эта перегородка в конструкции, если ее хочется убрать, потому что она удорожает изготовление.
При обратной разработке важно помнить, что форма мехатронного изделия, в том числе зафиксированная в 3D-моделях, чертежах и схемах, не позволяет отобразить и понять все аспекты функционирования изделия.
Простое копирование формы мехатронной системы не приведет к воспроизведению функций прототипа.
В результате в процессе испытания сделанной копии начинаются проблемы.
Описание технической системы в виде архитектуры позволяет:
- описать место исследуемой системы в среде эксплуатации;
- описать предполагаемые сценарии работы;
- зафиксировать ожидаемые функции прототипа;
- зафиксировать выявленные принципы работы исследуемой системы;
- определить, как элементы конструкции реализуют требуемые функции;
- увидеть пробелы в требованиях, характеристиках, сценариях, интерфейсах и связях.
Как результат — получить максимум возможной информации для воспроизведения требуемых функций и успешной валидации готового изделия.
