В данной статье мы простым языком расскажем как устроена модель данных в dBricks и расскажем о причинах выбора именно такого подхода.
Для лучшего понимания мы используем примеры системы из области авиастроения, но следует понимать, что инструмент dBricks может быть применен для проектирования систем в любой другой отрасли.
Наша цель - оптимизировать:
Обязательным условием успеха является согласованное и однозначное определение всех интерфейсов между всеми устройствами системы.
Воплотить систему в жизнь означает осуществить кучу соображений и решений. Все они должны быть согласованы и каждое отдельное действие влияет на остальные свойства системы. Наличие согласованных требований и методов позволяет избежать лишней итеративности и экономить силы.
В следующих разделах мы покажем возможные действия по использованию лучших практик в создании согласованной модели данных.
Любая система состоит из объектов, которые обмениваются некими данными. В случае подсистем самолёта этими объектами являются устройства (приборы). Данные приборы:
Например:
Пилоту для управления самолетом требуется информация об актуальном угле тангажа (pitch). Этот угол должен отображаться на так называемом индикаторе (DU) в кабине. Индикатор самостоятельно не способен измерять угол тангажа и должен получать эту информацию. Инерциальный прибор ADIRU измеряет угол тангажа самолета и может передать эти данные на индикатор пилота.
Оба эти устройства должны поддерживать обмен параметров тангажа:
Для корректной обработки необходимо определить свойства этого параметра. Понятно, что оба прибора должны однозначно расшифровывать этот параметр для его корректного использования. Во многих проектах неявные преобразования типов данных являются источником огромного количества проблем при разработке!
Для нашего параметра тангажа мы определяем следующие свойства:
В примере нашей системы мы добавим устройство вычислитель управления полетом (FCC), который также является потребителем значений тангажа для корректной работы.
Таким образом наша система будет выглядеть следующим образом:
При переходе к определению интерфейсов взаимодействия системы непременно возникают следующие необходимости:
Одна из главных особенностей dBricks это разделение описаний устройств и проектов. Шаблон устройства полностью описывает его в виде серийно выпускаемого прибора без привязки к проекту. Таким образом при необходимости внесения изменений во все устройства проекта, достаточно внести их в шаблон этого устройства.
В нашем примере проекта применяется несколько устройств одного типа: два ADIRU.
Для применения в нашей системе этих устройств в нормализованном виде мы выполняем следующие действия:
Стрелки на этом рисунке показывают связи между шаблонами устройств и устройствами в проекте. Использование шаблонов устройств означает, что новые сущности не создаются. Каждое устройство описывается только ОДИН раз и в ОДНОМ месте.
Сам проект представляет собой интерфейсную модель данных, которая не является единой сущностью. Это объект, который состоит из других объектов и связанных друг с другом.
В предварительных этапах мы определили данные, которыми будет обмениваться наша система. Для завершения описания мы всё ещё должны описать следующее:
Для описания физических взаимосвязей модели данных необходимо определить дополнительные объекты:
Передача параметра звучит просто. Однако существует множество возможностей как параметр может быть передан и как передатчик и приемник его обрабатывают.
Чтобы гарантировать правильное «понимание» с обеих сторон, важно определить:
Для описания всех необходимых деталей упаковки / распаковки вы ввели новую сущность под названием “Наполнение порта”. Оно определяет всю необходимую информацию для упаковки / распаковки и служит связующим звеном между логической передачей данных и физическим подключением. Эта сущность является частью описания шаблона устройства и также доступно для всех устройств созданных на основании этого шаблона в проекте. Наполнение порта может быть назначено для одного или нескольких выходных или дуплексных аппаратных портов. Такой подход позволяет значительно сэкономить время создания системы и её проверке, поскольку обычно устройства содержат множество однотипных выходных портов.
Наполнение порта зависит от типа порта, но всегда содержит перечень передающихся параметров и подробные сведения для их упаковки (кодирования).
Рассмотрим устройство наполнения порта на примере стандарта ARINC 429: Как вы можете знать обмен данными в ARINC 429 производится словами по 32 бита. Эти слова обычно передаются циклично с заданной частотой обновления, которая должна быть определена. Чтобы отличить одно слово от другого 8 первых бит слова определяют его номер. И в добавок ко всему большинство данных в ARINC 429 передаются в виде данных с фиксированной точкой, для чего требуется определять младший и старший значащий разряд и размер данных.
На данном этапе мы определили:
Созданная структура позволяет нам легко проводить валидацию. Мы можем гарантировать согласованность данных проверив, что все определенные нами связи параметров содержат соответствующие требования по упаковке и не противоречат подключениям на уровне проводов. Согласованная структура данных отлично подходит для проведения автоматизированных проверок, которые многократно производятся в dBricks.
Конечно в реальной жизни инженерная мысль порождает множество сложных функций и исключений. Но какой инженер без трудностей? ;-)
Несмотря на все исключения основная идея всегда остается без изменений:
В итоге применения dBricks:
После того, как вы получите модель интерфейса системы, dBricks поможет Вам множеством дополнительных функций, которые упростят Вашу повседневную жизнь. Он предоставит Вам данные в формате различных отчётов, включая такие формальные документы как схемы и полноценный протокол информационного взаимодействия (ICD). Он предоставит Вам различные неформальные отчеты, которые помогут Вам создать наиболее совершенную систему.
Просто убедитесь в этом самостоятельно: Получить демо доступ к dBricks
P.S. Ниже приведено несколько упрощенных схем моделей данных для каждого вышеупомянутого шага.
UML схема для Шага #1
UML схема для Шага #2 UML схема для Шага #3
UML схема для Шага #4
