Концепция информационного моделирования: различия между версиями
Vserge (обсуждение | вклад) м (→Пространственные данные: форматирование) |
Vserge (обсуждение | вклад) (→Открытые форматы: Добавлен формат USD) |
||
(не показано 9 промежуточных версий этого же участника) | |||
Строка 82: | Строка 82: | ||
Интересные статьи и материалы доступны на сайте ООО "САТУРС" в разделе "[http://cradle.saturs.ru/category/system-engineering/requirements_management/ Разработка и управление требованиями]" |
Интересные статьи и материалы доступны на сайте ООО "САТУРС" в разделе "[http://cradle.saturs.ru/category/system-engineering/requirements_management/ Разработка и управление требованиями]" |
||
А также на сайте "Свода знаний по системной инженерии" [http://sewiki.ru/AP_233 AP233 для описания требований] |
А также на сайте "Свода знаний по системной инженерии" [http://sewiki.ru/AP_233 AP233 для описания требований] |
||
+ | |||
+ | Полномасштабное решение задач управления требованиями в соответствии с требованиями стандарта ГОСТ Р 59194— 2020 возможно только при представлении требований к изделию и его составным частям в форме базы данных в автоматизированной системе. В этом случае применяемая для управления требованиями автоматизированная система (например, АС УДИ, ИС СУТ, [https://project.dovidnyk.info/index.php/home/razrabotkaiupravlenietrebovaniyami/65-doors-_sredstvo_upravleniya_trebovaniyami DOORS], [http://saturs.ru/index.php?r=block/plain&label=cradle 3SL Cradle] ) управляет каждым отдельным требованием и связями между требованиями, обеспечивающими прослеживаемость. Многие задачи контроля требований могут быть решены автоматизировано с использованием функций такой системы управления требованиями. Решение задач управления требованиями без применения автоматизированных систем, как правило, осуществляется путем разработки и управления изменениями соответствующих документов, что представляет собой трудоемкую задачу. |
||
+ | Требования, представленные в форме базы данных, при необходимости (для согласования, передачи, вывода на печать и т. п.) могут быть преобразованы в документ, в том числе странично- ориентированный. Такой документ рассматривается как производный по отношению к исходной базе данных и не подлежит самостоятельному изменению. Внесение изменений в производный документ выполняется только путем изменения исходной базы данных и последующего форми- рования на ее основе новой версии документа. |
||
+ | Примерами документов с требованиями являются: |
||
+ | * ТЗ на изделие по ГОСТ 15.016, по ГОСТ 19.201 — для программных изделий; |
||
+ | * ТЗ на автоматизированную систему по ГОСТ 34.602 — для автоматизированных систем, |
||
+ | * Проектные конструкторские документы по ГОСТ 2.102; |
||
+ | * «Спецификация системы/подсистемы», «Спецификации требований к ПО» и «Спецификация требований к интерфейсу», в соответствии с ГОСТ Р 51904 и др. |
||
+ | Кроме того, проектные требования могут быть представлены в виде конструкторского документа(ов) по ГОСТ 2.102, программного документа по ГОСТ 19.101, документа по ГОСТ 34.201 и т. п. (например, пояснительные записки, схемы и т. п.) |
||
+ | |||
+ | Примечание: на нашем портале появился раздел [[Управление требованиями]], в котором постепенно будет собрана вся информация по данной теме. |
||
+ | |||
+ | ====== Стандарты управления требованиями ====== |
||
+ | В части управления требованиям разработаны и введены в действие национальные стандарты |
||
+ | ГОСТ Р 59194— 2020 "УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ. Основные положения" |
||
===== Методология процесса моделирования ===== |
===== Методология процесса моделирования ===== |
||
Строка 118: | Строка 133: | ||
IDEF14 (Network Design) - данный метод позволяет моделировать вычислительные сети. Модель предназначена для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности. |
IDEF14 (Network Design) - данный метод позволяет моделировать вычислительные сети. Модель предназначена для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности. |
||
+ | |||
+ | |||
+ | ===== Модели-ориентированный подход ===== |
||
+ | Model-based Design - или моделеориентированный подход в проектировании является одним из новейших подходов к проектированию сложных объектов. |
||
+ | |||
+ | В соответствии с материалами [https://www.mathworks.com/matlabcentral/answers/440277-what-are-mil-sil-pil-and-hil-and-how-do-they-integrate-with-the-model-based-design-approach "What are MIL, SIL, PIL, and HIL, and how do they integrate with the Model-Based Design approach?"] и [https://www.youtube.com/watch?v=EZthOn4_0rw "Difference between MIL SIL PIL HIL"] можно сказать, что в рамках анализа киберфизических системем формируются несколько видов тестовых систем: Моделирование модели в цикле (анг. Model-in-the-Loop (MIL) simulation), Моделирование программного обеспечения в цикле (Software-in-the-Loop (SIL) simulation), Моделирование процессора в цикле (Processor-in-the-Loop (PIL) simulation) или FPGA в цикле (FPGA-in-the-Loop (FIL) simulation) и Моделирование аппаратного обеспечения в цикле (Hardware-in-the-Loop (HIL) Simulation). |
||
+ | Тестирование MIL, SIL, PIL и HIL входит в состав верификационной части подхода к проектированию на основе моделей после того, как вы определили требования разрабатываемого компонента/системы и они были смоделированы на уровне моделирования (например, платформа Simulink). Перед развертыванием модели на оборудовании для производства выполняется несколько этапов проверки, которые перечислены ниже. Здесь я беру пример проектирования контроллера для двигателя постоянного тока и помещаю код, сгенерированный на основе модели контроллера, в поддерживаемую систему на кристалле. |
||
+ | |||
+ | 1) Моделирование модели в цикле (MIL) или тестирование на основе модели |
||
+ | Во-первых, вы должны разработать модель реальной установки (аппаратного обеспечения) в среде моделирования, такой как Simulink, которая отражает большинство важных функций аппаратной системы. После создания модели установки разработайте модель контроллера и проверьте, может ли контроллер управлять установкой (в данном случае моделью двигателя) в соответствии с требованиями. Этот шаг называется Model-in-Loop (MIL), и вы тестируете логику контроллера на имитируемой модели установки. Если ваш контроллер работает должным образом, вы должны записать входные и выходные данные контроллера, которые будут использоваться на более позднем этапе проверки. |
||
+ | |||
+ | 2) Моделирование программного обеспечения в цикле (SIL) |
||
+ | После того, как ваша модель была проверена в MIL simulation, следующим этапом является программное обеспечение в цикле (SIL), где вы генерируете код только из модели контроллера и заменяете блок контроллера этим кодом. Затем запустите моделирование с помощью блока контроллера (который содержит код C) и установки, которая по-прежнему является программной моделью (аналогично первому шагу). Этот шаг даст вам представление о том, может ли ваша управляющая логика, т.е. модель контроллера, быть преобразована в код и может ли она быть реализована аппаратно. Вы должны записать здесь ввод-вывод и сопоставить его с тем, чего вы достигли на предыдущем шаге. Если вы обнаружите в них огромную разницу, возможно, вам придется вернуться к MIL и внести необходимые изменения, а затем повторить шаги 1 и 2. Если у вас есть модель, которая была протестирована на SIL, и ее производительность приемлема, вы можете перейти к следующему шагу. |
||
+ | |||
+ | 3) Моделирование процессора в цикле (PIL) или FPGA в цикле (FIL) |
||
+ | Следующим шагом является тестирование процессора в цикле (PIL). На этом шаге мы поместим модель контроллера на встроенный процессор и запустим моделирование замкнутого цикла с имитируемой установкой. Итак, мы заменим подсистему контроллера блоком PIL, в котором код контроллера будет выполняться на аппаратном обеспечении. Этот шаг поможет вам определить, способен ли процессор выполнять разработанную логику управления. Если есть сбои, вернитесь к своему коду, SIL или MIL, и исправьте их. |
||
+ | |||
+ | 4) Моделирование аппаратного обеспечения в цикле (HIL) |
||
+ | Перед подключением встроенного процессора к реальному оборудованию вы можете запустить имитированную модель установки в системе реального времени, такой как Speedgoat. Система реального времени выполняет детерминированное моделирование и имеет физические реальные соединения со встроенным процессором, например аналоговые входы и выходы, а также интерфейсы связи, такие как CAN и UDP. Это поможет вам определить проблемы, связанные с каналами связи и интерфейсом ввода-вывода, например, затухание и задержка, которые возникают из-за аналогового канала и могут привести к нестабильной работе контроллера. Это поведение не может быть зафиксировано при моделировании. Тестирование HIL обычно проводится для критически важных для безопасности применений, и этого требуют стандарты валидации в автомобильной и аэрокосмической промышленности. |
||
+ | |||
+ | 5) Фактическое оборудование |
||
+ | После того, как ваша модель установки была проверена с помощью PIL, теперь вы можете заменить модель установки оригинальным оборудованием, скажем, лабораторной моделью, и запустить тест. Допустим, это двигатель постоянного тока, регулятор скорости которого разрабатывается, а затем контроллер находится в FPGA / процессоре, который теперь подключен к двигателю постоянного тока путем подключения входов и выходов / состояний в нужных точках датчиков / преобразователей). |
||
==== ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ СИСТЕМНАЯ ИНЖЕНЕРИЯ ==== |
==== ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ СИСТЕМНАЯ ИНЖЕНЕРИЯ ==== |
||
Строка 190: | Строка 227: | ||
Управление конфигурацией проекта или Configuration Management – это идентификация, создание, поддержание и контроль конфигурации в ходе проекта<ref>https://upravlenie-proektami.ru/upravlenie-konfiguraciey-proekta-ili-configuration-management</ref>. |
Управление конфигурацией проекта или Configuration Management – это идентификация, создание, поддержание и контроль конфигурации в ходе проекта<ref>https://upravlenie-proektami.ru/upravlenie-konfiguraciey-proekta-ili-configuration-management</ref>. |
||
Основная задача управления конфигурацией – в любом момент времени иметь доступ к 100% актуальной версии конфигурационного элемента, которые необходимо использовать, и быть уверенным, что ни один конфигурационный элемент не конфликтует с другими конфигурационными элементами. По факту, это небольшая, но очень важная часть управления изменениями в проекте. |
Основная задача управления конфигурацией – в любом момент времени иметь доступ к 100% актуальной версии конфигурационного элемента, которые необходимо использовать, и быть уверенным, что ни один конфигурационный элемент не конфликтует с другими конфигурационными элементами. По факту, это небольшая, но очень важная часть управления изменениями в проекте. |
||
+ | |||
+ | В соответствии с {{cite book | vauthors=((Watts, F. B.)) | date= 2012 | title=Engineering Documentation Control Handbook. Configuration Management and Product Lifecycle Management | publisher=Elsevier | edition=FOURTH EDITION | url=https://linkinghub.elsevier.com/retrieve/pii/B9781455778607000016 | doi=10.1016/B978-1-4557-7860-7.00001-6 | isbn=978-1-4557-7860-7}}: |
||
+ | Управление конфигурацией - это простой, понятный, быстрый, точный, эффективный, взвешенный и хорошо понятный процессный подход к планированию, идентификации, контролю и отслеживанию конфигурации продукта с момента его создания на протяжении всего срока службы с минимальными затратами. |
||
+ | |||
+ | Инженеры, да и многие другие виды профессий, ненавидят слово “контроль”. Слишком большой контроль снижает скорость производственной деятельности. Скорость - это элемент, отсутствующий в большинстве систем. Что еще отличает инжиниринг от других видов деятельности - это управление жизненным циклом изделия (объекта). Обратите внимание, что термин “отслеживание” используется вместо классического термина Министерства обороны “учет состояния”. Задача специалиста по управлению конфигурацией состоит в том, чтобы смешать нужное количество каждого из этих элементов в процессах управления конфигурацией – выпуске продукта и документа, спецификации, запросе на изменении. |
||
+ | Чтобы процессы были “систематическими и хорошо понятными”, они должны быть задокументированы. Дисциплина должна быть описана в наборе стандартов, а вовлеченные в нее люди должны быть обучены этим стандартам. |
||
+ | |||
+ | Конфигурация - это техническое описание и расположение или комбинация деталей и материалов, которые способны удовлетворять требованиям, определенным спецификацией продукта, другими спецификациями и чертежами. |
||
===== Управление конфигурацией в машиностроениии ===== |
===== Управление конфигурацией в машиностроениии ===== |
||
Строка 270: | Строка 315: | ||
Именно по этой пречине стоит обратить внимание на эти материалы. Более подробнее познакомиться с этой информацией можно в разделе [[Геоинформационные системы]]. |
Именно по этой пречине стоит обратить внимание на эти материалы. Более подробнее познакомиться с этой информацией можно в разделе [[Геоинформационные системы]]. |
||
+ | |||
+ | Стоит отметить, что в Европе вопросами пространственных даных занимается отдельная организация infrustructure for spatial infomation in Eroupe (INSPIRE). |
||
+ | Материалы, которые выпускает данная организация доступны по ссылке: https://inspire.ec.europa.eu/docs |
||
===== Common Information Model ===== |
===== Common Information Model ===== |
||
Строка 337: | Строка 385: | ||
====== Стандарт Functional Mock-up Interface for embedded systems (eFMI) ====== |
====== Стандарт Functional Mock-up Interface for embedded systems (eFMI) ====== |
||
Стандарт Functional Mock-up Interface for embedded systems (eFMI) - это открытый стандарт для поэтапной разработки расширенных функций управления, подходящих для критически важных для безопасности целей и задач в реальном времени. Это позволяет применять (физические) модели во встроенном программном обеспечении, предоставляя стандартизированную контейнерную архитектуру для поэтапной доработки первого высокоуровневого алгоритмического решения для реальной встроенной реализации в выделенной целевой среде, такой как электронный блок управления (ECU) или микроконтроллер. С этой целью стандарт определяет различные представления моделей в процессе уточнения от (физической) модели до встроенного программного обеспечения: (1) Поведенческие / эталонные результаты для тестирования (контейнеры поведенческих моделей), (2) Независимое от цели ограниченное алгоритмическое решение (Контейнер кода алгоритма) на основе языка программирования GALEC, (3) Реализации C, адаптированные и оптимизированные для требований конкретных целевых сред (контейнеры производственного кода) и (4) Двоичные дистрибутивы и их „рецепты сборки“, готовые для интеграции во встроенную систему (контейнеры двоичного кода). |
Стандарт Functional Mock-up Interface for embedded systems (eFMI) - это открытый стандарт для поэтапной разработки расширенных функций управления, подходящих для критически важных для безопасности целей и задач в реальном времени. Это позволяет применять (физические) модели во встроенном программном обеспечении, предоставляя стандартизированную контейнерную архитектуру для поэтапной доработки первого высокоуровневого алгоритмического решения для реальной встроенной реализации в выделенной целевой среде, такой как электронный блок управления (ECU) или микроконтроллер. С этой целью стандарт определяет различные представления моделей в процессе уточнения от (физической) модели до встроенного программного обеспечения: (1) Поведенческие / эталонные результаты для тестирования (контейнеры поведенческих моделей), (2) Независимое от цели ограниченное алгоритмическое решение (Контейнер кода алгоритма) на основе языка программирования GALEC, (3) Реализации C, адаптированные и оптимизированные для требований конкретных целевых сред (контейнеры производственного кода) и (4) Двоичные дистрибутивы и их „рецепты сборки“, готовые для интеграции во встроенную систему (контейнеры двоичного кода). |
||
+ | |||
+ | ====== Библиотека Physiolibrary ====== |
||
+ | |||
+ | [http://www.physiolibrary.org Physiolibrary] is a free open-source Modelica library designed for modeling human physiology. This library contains basic physical laws governing human physiology, usable for cardiovascular circulation, metabolic processes, nutrient distribution, thermoregulation, gases transport, electrolyte regulation, water distribution, hormonal regulation and pharmacological regulation. |
||
===== Интерактивные документы ===== |
===== Интерактивные документы ===== |
||
Строка 347: | Строка 399: | ||
Еще одна статья по поводу вычислимых документов доступна на [https://habr.com/ru/company/wunderfund/blog/316826/ HABR] |
Еще одна статья по поводу вычислимых документов доступна на [https://habr.com/ru/company/wunderfund/blog/316826/ HABR] |
||
+ | ==== Смарт Контракты ==== |
||
+ | Развитие области Смарт контактов позволяет сформировать целый пласт новых технических возможностей применим ТиМ |
||
+ | |||
+ | ==== "Умные" стандарты ==== |
||
+ | |||
+ | Умные стандарты предполагают возможность автоматизированного анализа и извлечение смысла из нормативных документов с целью последующей обработки этих данных. |
||
+ | Подробнее можно прочитать по [[Умные стандарты|ссылке]] |
||
+ | = Концепция информационного моделирования = |
||
Все этой приводит нас к формированию в рамках концепции информационного моделирования инфраструктуры интерактивных документов, которые могут быть переданы в качестве результатов работы инженера по определенной теме. |
Все этой приводит нас к формированию в рамках концепции информационного моделирования инфраструктуры интерактивных документов, которые могут быть переданы в качестве результатов работы инженера по определенной теме. |
||
Строка 404: | Строка 464: | ||
==== Открытые форматы ==== |
==== Открытые форматы ==== |
||
===== Пространственные данные ===== |
===== Пространственные данные ===== |
||
− | + | ======C3D file format====== |
|
Наименование: Coordinate 3D files |
Наименование: Coordinate 3D files |
||
Строка 411: | Строка 471: | ||
Краткое описание: Формат файла C3D предназначен для хранения необработанных данных из среды сбора 3D-данных, каждый набор данных хранится в виде одной пробной версии необработанных 3D-координат и аналоговых выборок с определенным разделом параметров, который описывает свойства данных каждого файла. Все ранние файлы C3D включали данные о вкладе камеры и остаточный объем 3D-вычислений, сохраненный с каждой 3D-координатой, что позволяло постоянно контролировать и оценивать качество и точность каждого записанного значения 3D-данных. Одновременно во время каждого 3D-кадра можно отбирать несколько выборок аналоговых данных, чтобы гарантировать временную синхронизацию, при этом каждая аналоговая выборка записывается как значение, непосредственно считываемое с АЦП, и записывается как необработанные значения выборки. В целом дизайн формата C3D позволяет сохранять все собранные данные с минимальной обработкой и позволяет пользователю проверять качество необработанных и необработанных 3D- и аналоговых данных, собранных во время эксперимента. Однако, по мере развития систем сбора данных, многие производители начали обрабатывать необработанные выборочные данные перед созданием файла C3D и создали свои собственные дополнительные значения данных в файле в виде псевдо-3D точек для хранения обработанных и вычисленных значений данных. Хотя это не нарушает спецификацию C3D, это означает, что конечные пользователи теперь должны безоговорочно доверять усилиям своего производителя по сбору и обработке данных, поскольку многие файлы C3D в наши дни не содержат никаких необработанных данных, поскольку производитель удалил исходные “необработанные” данные из наблюдения. Это означает, что любые ошибки при сборе и обработке данных до создания файла C3D эффективно скрываются от конечного пользователя в интересах производителя, предотвращая оценку качества процесса сбора данных. |
Краткое описание: Формат файла C3D предназначен для хранения необработанных данных из среды сбора 3D-данных, каждый набор данных хранится в виде одной пробной версии необработанных 3D-координат и аналоговых выборок с определенным разделом параметров, который описывает свойства данных каждого файла. Все ранние файлы C3D включали данные о вкладе камеры и остаточный объем 3D-вычислений, сохраненный с каждой 3D-координатой, что позволяло постоянно контролировать и оценивать качество и точность каждого записанного значения 3D-данных. Одновременно во время каждого 3D-кадра можно отбирать несколько выборок аналоговых данных, чтобы гарантировать временную синхронизацию, при этом каждая аналоговая выборка записывается как значение, непосредственно считываемое с АЦП, и записывается как необработанные значения выборки. В целом дизайн формата C3D позволяет сохранять все собранные данные с минимальной обработкой и позволяет пользователю проверять качество необработанных и необработанных 3D- и аналоговых данных, собранных во время эксперимента. Однако, по мере развития систем сбора данных, многие производители начали обрабатывать необработанные выборочные данные перед созданием файла C3D и создали свои собственные дополнительные значения данных в файле в виде псевдо-3D точек для хранения обработанных и вычисленных значений данных. Хотя это не нарушает спецификацию C3D, это означает, что конечные пользователи теперь должны безоговорочно доверять усилиям своего производителя по сбору и обработке данных, поскольку многие файлы C3D в наши дни не содержат никаких необработанных данных, поскольку производитель удалил исходные “необработанные” данные из наблюдения. Это означает, что любые ошибки при сборе и обработке данных до создания файла C3D эффективно скрываются от конечного пользователя в интересах производителя, предотвращая оценку качества процесса сбора данных. |
||
+ | |||
+ | ======Universal Scene Description====== |
||
+ | Источник: https://openusd.org |
||
+ | |||
+ | Конвейеры, способные создавать фильмы и игры с компьютерной графикой, обычно генерируют, хранят и передают большие объемы 3D-данных, которые мы называем “описанием сцены”. Каждое из множества взаимодействующих приложений в процессе разработки (моделирование, затенение, анимация, освещение, fx, рендеринг) обычно имеет свою собственную специальную форму описания сцены, адаптированную к конкретным потребностям и рабочим процессам приложения, которая не доступна для чтения или редактирования никаким другим приложением. Universal Scene Description (USD) - это первое общедоступное программное обеспечение, которое удовлетворяет потребность в надежном и масштабируемом обмене и дополнении произвольных 3D-сцен, которые могут быть составлены из множества элементарных элементов. |
||
+ | |||
+ | USD позволяет обмениваться элементарными активами (например, моделями) или анимацией. Но, в отличие от других пакетов обмена, USD также позволяет собирать и организовывать любое количество ресурсов в виртуальные наборы, сцены, кадры и миры, передавать их из приложения в приложение и редактировать без разрушения (как переопределения) с помощью единого согласованного API в одном scenegraph. USD предоставляет богатый набор инструментов для чтения, записи, редактирования и быстрого предварительного просмотра 3D-геометрии, затенения, освещения, физики и растущего числа других областей, связанных с графикой. Кроме того, поскольку ядро USD scenegraph и механизм компоновки не зависят от какого-либо конкретного домена, USD можно легко расширить для кодирования и компоновки данных в других доменах. |
||
+ | |||
+ | В частности, USD - это проект с открытым исходным кодом, выпущенный под лицензией TOST. |
||
===== Атрибутивные данные ===== |
===== Атрибутивные данные ===== |
Текущая версия на 21:39, 23 ноября 2024
Предпосылки разработки концепци информационого моделирования
Настоящий документ определяет методологическую основу применения технологий информационного моделирования на различных этапах жизненного цикла объекта. В этом документе сделана попытка заложить основу для формирования требований к информационным моделям и подготовке информационных моделей для цифровых двойников в рамках комплекса стандартов ЕСИМ. Одновременно с этим формирует основу терминологическую основу для нормативно-правовой системы РФ в области информационного моделирования и «безбумажного» инжиниринга. Концепция распространяется на применение технологии информационного моделирования территорий, природных и антропогенных объектов, в том числе зданий и сооружений (комплексов зданий и сооружений) любого назначения, включая объекты подсобного и обслуживающего назначения, объекты транспортного хозяйства и связи, наружные сети и сооружения, объекты благоустройства и озеленения территории, временные здания и сооружения и прочие объекты, входящие в понятие «антропогенной объект». В целях наиболее широкого охвата отраслей экономики, в рамках которых осуществляются применение технологий информационного моделирования, настоящая концепция определяет общий подход к управлению жизненными циклами объектов с использованием технологий информационного моделирования.
Единство применения технологий информационного моделирования обеспечивается:
- единством терминологии;
- единым составом задач и мероприятий;
- единым порядком разработки и унификацией форм технической документации;
- единой модель данных
- единством правил действия всех исполнителей;
- единством нормативов по строительству.
Термины, определения и сокращения
Термины и определения
В настоящем стандарте применены термины в соответствии со стандартом ГОСТ Р 10.00.0002-202х Единая система информационного моделирования. Термины и определения.
Сокращения
ЕСИМ – единая система информационного моделирования;
ЕИП – единое информационное пространство;
ЕСКД – Единая система конструкторской документации;
ЖЦ – Жизненный цикл;
ИМ – информационная модель;
ИЦММ – инженерная цифровая модель местности;
ЦИМ – Цифровая информационная модель;
ОКС – Объект капитального строительства;
СЭД – система (системы) электронного документооборота;
СПДС – Система проектной документации в строительстве;
ТИМ – технологии информационного моделирования;
БУКО – Базовый укрупненный классификатор отрасли;
СОИ – Системы обработки информации;
Технические средства – Технические средства системы обработки информации;
OOSEM - Object-oriented System Engineering Method - Метод объектно-ориентированной системной инженерии
История развития
Предшествующие методологии
Безусловно технологии информационного моделирирования не появились из ничего, они стали результатом активного развития информационных технологий в машиностроении, строительстве и других отраслях.
УПРАВЛЕНИЕ ПРОЕКТОМ
Управление проектом это глобальная дисциплина, которая позволяет реализовывать технически сложные Проекты.
Для строительства дамбы Хувера была разработана методология управления на основе Ганта (1920). После проекта строительства Дамбы Хувера управление проектом развивалось как научно-разрабатываемся дисциплина на основе событий: • 1956: The American Association of Cost Engineers (now AACE International) • 1957: The Critical Path Method (CPM) Invented by the Dupont Corporation • 1958: The Program Evaluation Review Technique (PERT) Invented for the U.S. Navy’s Polaris Project • 1962: United States Department of Defense Mandate the Work Breakdown Structure (WBS) Approach • 1965: The International Project Management Association (IPMA) Was Founded • 1969: Project Management Institute (PMI) Launched to Promote the Project Management Profession
ИНЖИНИРИНГ
«Инженерное дело (инженерия) — область человеческой интеллектуальной деятельности, дисциплина, профессия, задачей которой является применение достижений науки, техники, использование законов физики и природных ресурсов для решения конкретных проблем, целей и задач человечества. Инженерное дело реализуется через применение как научных знаний, так и практического опыта (инженерных навыков, умения) с целью создания (в первую очередь проектирования) полезных технологических и технических процессов и объектов, которые реализуют эти процессы»[1].
Совет американских инженеров по профессиональному развитию (American Engineers' Council for Professional Development — ECPD) дал следующее определение термину «инженерия»: «Творческое применение научных принципов для проектирования структур, машин, аппаратуры, производственных процессов, а также работа по использованию их отдельно или в комбинации; конструирование или управление тем же самым с полным знанием их дизайна; предсказание их поведения в определенных эксплуатационных режимах. Люди, которые постоянно и профессионально практикуют инженерию, называются инженерами».
Согласно определению, данному Европейской экономической комиссией ООН в 80-е гг. прошлого века, инжиниринг — это особая деятельность, связанная со строительством и эксплуатацией предприятий и объектов инфраструктуры. Другими словами, совокупность проектных и практических работ и услуг, относящихся к инженерно-технической области и необходимых для возведения объекта и содействия его эксплуатации.
Таким образом, инжиниринг находится между наукой и производством, формируя технологическую (в том числе техническую) базу производственной деятельности. В сформированной Европейской экономической комиссией и принятой инженерным сообществом классификации выделяются несколько видов инжиниринга. Наиболее распространенные — консультационный, строительный, технологический и комплексный инжиниринг. Последний включает в себя многие функции перечисленных видов: проектирование, поставку оборудования, руководство строительно-монтажными работами, сдачу промышленного объекта «под ключ».
инжиниринга: деятельность по инженерно-техническому и инженерно-экономическому сопровождению жизненного цикла технических систем (в том числе промышленных объектов) от инвестиционного замысла до окончания эксплуатации.
Для этого имеет смысл обратиться к стандарту ГОСТ Р 57306-2016 "ИНЖИНИРИНГ. Терминология и основные понятия в области инжиниринга"
Также, имеет смысл рассмотреть применение инженерного подхода при разработке ПО на основе статьи "Инженерный подход к разработке ПО"
СИСТЕМНАЯ ИНЖЕНЕРИЯ
Разработанная в рамках INCOSE методология системной инженерии послужила основой для создания комплексной методологии информационного моделирования. Подробнее познакомиться с данной методологией можно в прочитав руководство "Systems engineering handbook: a guide for system life cycle processes and activities" Шаблон:Cite book На сайт OMGWIKI доступна крайне интересная презентация 2017 года о развитии системной инженерии в части информационного взаимодействия и развития различных стандартов, протоколов обмена и т.д: "Data Exchange Standards Overview AP233/AP239/AP242 and MoSSEC". В частности в этой презентации вы сможете найти ответ на вопрос какой формат для информационного взаимодействия лучше: STEP, XML, UML и т.д.
Еще одна презентация An Overview of AP233 STEP’s Systems Engineering Standard, с которой выступал 20 октября 2003 года Jim U’Ren, председатель рабочей группы AP233 NASA/JPL. В этой презентации можно увидеть много слайдов, аналогичных тем, что через 10 лет начали показывать представители разработчиков ПО области информационного моделирования.
Более подробно про системную инженерию можно прочитать на портале Systems Engineering Thinking Wiki
В части системной инженерии можно посмотреть интересные материалы от компании ООО «САТУРС» раздел "Системная инженерия" На сайте NASA доступна презентация "AP233. An Information Model for Systems Engineering", в которой дается история развития информационного моделирования в части системной инженерии.
Управление требованиями
Интересные статьи и материалы доступны на сайте ООО "САТУРС" в разделе "Разработка и управление требованиями" А также на сайте "Свода знаний по системной инженерии" AP233 для описания требований
Полномасштабное решение задач управления требованиями в соответствии с требованиями стандарта ГОСТ Р 59194— 2020 возможно только при представлении требований к изделию и его составным частям в форме базы данных в автоматизированной системе. В этом случае применяемая для управления требованиями автоматизированная система (например, АС УДИ, ИС СУТ, DOORS, 3SL Cradle ) управляет каждым отдельным требованием и связями между требованиями, обеспечивающими прослеживаемость. Многие задачи контроля требований могут быть решены автоматизировано с использованием функций такой системы управления требованиями. Решение задач управления требованиями без применения автоматизированных систем, как правило, осуществляется путем разработки и управления изменениями соответствующих документов, что представляет собой трудоемкую задачу. Требования, представленные в форме базы данных, при необходимости (для согласования, передачи, вывода на печать и т. п.) могут быть преобразованы в документ, в том числе странично- ориентированный. Такой документ рассматривается как производный по отношению к исходной базе данных и не подлежит самостоятельному изменению. Внесение изменений в производный документ выполняется только путем изменения исходной базы данных и последующего форми- рования на ее основе новой версии документа. Примерами документов с требованиями являются:
- ТЗ на изделие по ГОСТ 15.016, по ГОСТ 19.201 — для программных изделий;
- ТЗ на автоматизированную систему по ГОСТ 34.602 — для автоматизированных систем,
- Проектные конструкторские документы по ГОСТ 2.102;
- «Спецификация системы/подсистемы», «Спецификации требований к ПО» и «Спецификация требований к интерфейсу», в соответствии с ГОСТ Р 51904 и др.
Кроме того, проектные требования могут быть представлены в виде конструкторского документа(ов) по ГОСТ 2.102, программного документа по ГОСТ 19.101, документа по ГОСТ 34.201 и т. п. (например, пояснительные записки, схемы и т. п.)
Примечание: на нашем портале появился раздел Управление требованиями, в котором постепенно будет собрана вся информация по данной теме.
Стандарты управления требованиями
В части управления требованиям разработаны и введены в действие национальные стандарты ГОСТ Р 59194— 2020 "УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ. Основные положения"
Методология процесса моделирования
IDEF – Сокращение от Integration Definition Metodology (Объединение Методологических Понятий). Семейство совместно используемых методов для процесса моделирования. IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) является основным пользователем данной технологии. Ей, также, пользуются некоторые крупные корпорации в США.
IDEF0 (Function Modeling) – данный метод используется для создания функциональной модели, которая является структурированным отображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции.
IDEF1 (Information Modeling) – данный метод применяется для построения информационной модели, которая представляет собой структурированную информацию, необходимую для поддержки функций производственной системы или среды.
IDEF2 (Simulation Model Design) – данный метод позволяет построить динамическую модель меняющегося во времени поведения функций, информации и ресурсов производственной системы или среды. Данная модель используется редко. В основном востребована на предприятиях, где необходимо описать непрерывную дейтельность на конвейерах или аналогичные функции.
IDEF3 (Process Description Capture) – данный метод используется для сбора информации о состоянии моделируемой системы. Это структурный метод, показывающий причинно-следственные связи и события. Он также показывает, как организована работа, и какие пользователи работают с моделируемой системой. IDEF3 состоит из двух методов. Process Flow Description (PFD) – описание процессов, с описанием того, как организована работа между различными элементами моделируемой системы. Object State Transition Description (OSTD) – описание переходов состояний объектов, с описанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.
IDEF4 (Object-Oriented Design) – данный метод объектно-ориентированного планирования был разработан для поддержки объектно-ориентированной идеологии. Подробнее - Технология UML.
IDEF5 (Ontology Description Capture) – данный метод позволяет разрабатывать, изучать и поддерживать онтологию моделируемой системы. Термин «онтология» включает в себя каталог терминов области знаний; правила, объясняющие, как термины могут комбинироваться, создавая при этом корректные ситуации в области знаний и согласованные выводы, используемые в моделируемой системе.
IDEF6 (Design Rational Capture Method) - данный метод позволяет использовать рациональный опыт проектирования.
IDEF7 ( Information System Auditing) - данный метод описывает проведение методологии аудита информационной системы.
IDEF8 (User Interface Modeling) – данный метод позволяет разрабатывать необходимые модели Графического Интерфейса Пользователя (Human-System Interaction Design). Метод предназначена для проектирования взаимодействия человека и технической системы.
IDEF9 (Business Constraint Discovery) - данная модель предназначена для анализа имеющихся условий и ограничений (в том числе физических, юридических или любых других) и их влияния на принимаемые решения в процессе реинжиниринга.
IDEF10 - Implementation Architecture Modeling
IDEF11 - Information Artifact Modeling
IDEF12 - Organization Modeling
IDEF13 - Three Schema Mapping Design
IDEF14 (Network Design) - данный метод позволяет моделировать вычислительные сети. Модель предназначена для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности.
Модели-ориентированный подход
Model-based Design - или моделеориентированный подход в проектировании является одним из новейших подходов к проектированию сложных объектов.
В соответствии с материалами "What are MIL, SIL, PIL, and HIL, and how do they integrate with the Model-Based Design approach?" и "Difference between MIL SIL PIL HIL" можно сказать, что в рамках анализа киберфизических системем формируются несколько видов тестовых систем: Моделирование модели в цикле (анг. Model-in-the-Loop (MIL) simulation), Моделирование программного обеспечения в цикле (Software-in-the-Loop (SIL) simulation), Моделирование процессора в цикле (Processor-in-the-Loop (PIL) simulation) или FPGA в цикле (FPGA-in-the-Loop (FIL) simulation) и Моделирование аппаратного обеспечения в цикле (Hardware-in-the-Loop (HIL) Simulation). Тестирование MIL, SIL, PIL и HIL входит в состав верификационной части подхода к проектированию на основе моделей после того, как вы определили требования разрабатываемого компонента/системы и они были смоделированы на уровне моделирования (например, платформа Simulink). Перед развертыванием модели на оборудовании для производства выполняется несколько этапов проверки, которые перечислены ниже. Здесь я беру пример проектирования контроллера для двигателя постоянного тока и помещаю код, сгенерированный на основе модели контроллера, в поддерживаемую систему на кристалле.
1) Моделирование модели в цикле (MIL) или тестирование на основе модели Во-первых, вы должны разработать модель реальной установки (аппаратного обеспечения) в среде моделирования, такой как Simulink, которая отражает большинство важных функций аппаратной системы. После создания модели установки разработайте модель контроллера и проверьте, может ли контроллер управлять установкой (в данном случае моделью двигателя) в соответствии с требованиями. Этот шаг называется Model-in-Loop (MIL), и вы тестируете логику контроллера на имитируемой модели установки. Если ваш контроллер работает должным образом, вы должны записать входные и выходные данные контроллера, которые будут использоваться на более позднем этапе проверки.
2) Моделирование программного обеспечения в цикле (SIL) После того, как ваша модель была проверена в MIL simulation, следующим этапом является программное обеспечение в цикле (SIL), где вы генерируете код только из модели контроллера и заменяете блок контроллера этим кодом. Затем запустите моделирование с помощью блока контроллера (который содержит код C) и установки, которая по-прежнему является программной моделью (аналогично первому шагу). Этот шаг даст вам представление о том, может ли ваша управляющая логика, т.е. модель контроллера, быть преобразована в код и может ли она быть реализована аппаратно. Вы должны записать здесь ввод-вывод и сопоставить его с тем, чего вы достигли на предыдущем шаге. Если вы обнаружите в них огромную разницу, возможно, вам придется вернуться к MIL и внести необходимые изменения, а затем повторить шаги 1 и 2. Если у вас есть модель, которая была протестирована на SIL, и ее производительность приемлема, вы можете перейти к следующему шагу.
3) Моделирование процессора в цикле (PIL) или FPGA в цикле (FIL) Следующим шагом является тестирование процессора в цикле (PIL). На этом шаге мы поместим модель контроллера на встроенный процессор и запустим моделирование замкнутого цикла с имитируемой установкой. Итак, мы заменим подсистему контроллера блоком PIL, в котором код контроллера будет выполняться на аппаратном обеспечении. Этот шаг поможет вам определить, способен ли процессор выполнять разработанную логику управления. Если есть сбои, вернитесь к своему коду, SIL или MIL, и исправьте их.
4) Моделирование аппаратного обеспечения в цикле (HIL) Перед подключением встроенного процессора к реальному оборудованию вы можете запустить имитированную модель установки в системе реального времени, такой как Speedgoat. Система реального времени выполняет детерминированное моделирование и имеет физические реальные соединения со встроенным процессором, например аналоговые входы и выходы, а также интерфейсы связи, такие как CAN и UDP. Это поможет вам определить проблемы, связанные с каналами связи и интерфейсом ввода-вывода, например, затухание и задержка, которые возникают из-за аналогового канала и могут привести к нестабильной работе контроллера. Это поведение не может быть зафиксировано при моделировании. Тестирование HIL обычно проводится для критически важных для безопасности применений, и этого требуют стандарты валидации в автомобильной и аэрокосмической промышленности.
5) Фактическое оборудование После того, как ваша модель установки была проверена с помощью PIL, теперь вы можете заменить модель установки оригинальным оборудованием, скажем, лабораторной моделью, и запустить тест. Допустим, это двигатель постоянного тока, регулятор скорости которого разрабатывается, а затем контроллер находится в FPGA / процессоре, который теперь подключен к двигателю постоянного тока путем подключения входов и выходов / состояний в нужных точках датчиков / преобразователей).
ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ СИСТЕМНАЯ ИНЖЕНЕРИЯ
Адаптация системной инженерии к применению языка системного моделирования SysML привела к разработке объектно-ориентированной методологии системной инженерии. Данная методология подробно изложена в книге "A Practical Guide to SysML, Third Edition: The Systems Modeling Language" Шаблон:Cite book Дополнительно можно прочитать параграф 9.4 Object‐oriented Systems Engineering Method книги "Systems engineering handbook: a guide for system life cycle processes and activities" Шаблон:Cite book
Данной методологии посвящен целый раздел на портале INCOSE Object-Oriented SE Method: Первоначально разработанный системными инженерами из Lockheed Martin и Консорциума систем и программного обеспечения, метод объектно-ориентированного системного проектирования (OOSEM) представляет собой метод разработки на системном уровне, который сочетает объектно-ориентированные концепции с традиционными методами системного проектирования. Две основные цели метода - облегчить интеграцию системного проектирования с объектно-ориентированной (OO) разработкой программного обеспечения и применить моделирование OO таким образом, чтобы это приносило пользу процессу системного проектирования.
Первоначально OOSEM был основан на унифицированном языке моделирования (UML) Группы управления объектами (OMG); теперь он использует язык моделирования OMG Systems (SysML) для представления информации о системном анализе и проектировании. Он содержит действия по анализу потребностей и требований, проектированию логической и распределенной архитектуры, а также включает руководство по изучению торговли, валидации и проверке.
Несколько хороших источников информации о OOSEM:
- Хороший обзор OOSEM доступен в "Практическом руководстве по SysML", Третье издание, Сэнфорд Фриденталь, Алан Мур и Рик Штайнер. Эта книга в основном посвящена SysML, но в главе 17 OOSEM применяется к тематическому исследованию системы безопасности жилых помещений. Книга и сопутствующие материалы доступны на сайте Elsevier. Сопутствующие материалы включают рисунки PowerPoint из каждой главы и модели для примеров в форматах Magic Draw и HTML. Книга также доступна на Amazon.
- Раздел 9.4 Руководства INCOSE Systems Engineering, Четвертое издание, является еще одним хорошим обзором метода.
- Лаборатория прикладной физики Университета Джона Хопкинса разработала учебный материал по использованию SysML и OOSEM.
- Мэри Толберт разработала модель процесса OOSEM с использованием Eclipse Process Framework. Чтобы просмотреть модель, загрузите OOSEM Process Baseline (1/2020), извлеките содержимое zip-файла, откройте папку oosem_process_baseline, а затем откройте index.html файл с помощью Internet Explorer.
в контексте системной инженерии FIATECH развивал направление по информационному взаимодействию для нефтегазовой отрасли. результатом данной работы появился стандарт ISO 15926
ISO 15926
Основной источник информации по данному стандарту вы сможете найти на портале https://15926.org
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Business Process Management (BPM)
Управление бизнес-процессами (англ. business process management, BPM) — это системный подход к выявлению, проектированию, исполнению, документированию, измерению, мониторингу и контролю как автоматизированных, так и неавтоматизированных бизнес-процессов, нацеленный на стабильное достижение показателей, согласованных со стратегическими целями организации. Управление бизнес-процессами (BPM) охватывает осознанную, коллективную, все в большей степени опирающуюся на информационные технологии деятельность по выявлению, оптимизации и управлению сквозными «от и до» бизнес-процессами, нацеленную на бизнес- результат и создание ценности для потребителей и позволяющую организации быстрее достигать своих бизнес-целей. BPM позволяет предприятию согласовывать бизнес-процессы и стратегию и тем самым повышать итоговую эффективность за счет оптимизации конкретных действий, будь то в рамках отдельного подразделения, в масштабах предприятия или на стыке нескольких организацийШаблон:Cite book.
BPM отвечает на вопросы где, когда, зачем, как и какая работа выполняется и кто отвечает за ее выполнение.
BPMS/BPMT (англ. Business Process Management System/Tool, система (инструмент) управления бизнес-процессами) — технологическое программное обеспечение для поддержки концепции BPM. Среди нотаций моделирования бизнес-процессов в различных решениях используются языки BPMN, EPC (англ. Event-driven Process Chain), IDEF0 и другие. Среди известных нотаций выполнения бизнес-процессов, применяемых в программных системах — BPEL и её диалекты, YAWL.
Business Process Management Notation
Subject-oriented Business Process Management
Основной областью для изменений организации при внедрённой методологии BPM часто называют «самостоятельно регулируемые социально-технические системы»[2] . Технические системы, особенно системы управления потоками работ (воркфлоу), находятся в организационном контексте и поэтому являются экономически выгодными, когда используются людьми. Поэтому необходимо применять объединённые модели, методы и инструменты их описания в системных взаимосвязях и дальнейшего использования в рамках полноценного, холистического подхода к управлению организациями.
Обозначенный выше субъектно-ориентированный подход позволяет сформировать системную методологию анализа производственной деятельности в рамках информационного моделирования. Субъектно-ориентированное управление бизнес-процессом включает в себя не только возможность перевода представленных фактов в модель на естественном языке. Оно позволяет также постоянно изменять протекание бизнес-процесса в структурированном виде. Субъектно-ориентированная методика перемещает в центр внимания Актёров (субъектов), выполняющих сочетающиеся друг с другом последовательности действий (предикаты). Объектом в S-BPM моделировании является сам процесс. Таким образом, S-BPM – это методика, которая сама может быть полностью определена своими собственными элементами. Это само-описание S-BPM показывает согласованность подхода и является залогом его успешного само-внедрения.
«Процесс» в S-BPM методологии соответствует общепринятому определению бизнес-процесса[3][4][5][6]. А именно, интегрируя все определения, последовательность взаимосвязанных друг с другом действий (задач, функций), которые:
- определяют начало, ведение и конец, результат процесса;
- выполняются субъектами (людьми и/или системами);
- реализуются в надлежащей логической и хронологической последовательности;
- осуществляются с помощью доступных ресурсов (персонал, материальные и информационные ресурсы,);
- выполняются для обработки объектов бизнеса, иначе, реализации сути бизнеса;
- служат для того, чтобы удовлетворить потребности клиента (и способствовать созданию ценности – результата, значимого для рынка).
Объекты бизнеса – это те объекты, которые оказывают влияние на бизнес, используя коммуникационные связи во время выполнения заданий, иначе говоря, совокупность объектов бизнеса составляет его суть или сущность. В S-BPM, таким образом, включены те объекты, которые необходимы для обмена сообщениями между субъектами, а также для различных видов деятельности субъектов.
Последовательности действий в методологии S-BPM:
- Анализ
Первым шагом в S-BPM-моделировании, как правило, является анализ, сущность которого заключается в исследовании процесса, его рамочных условий и разложении его на компоненты. Часть информации для анализа получается, с одной стороны, из организационной структуры и стратегии, с другой стороны, в результате, в частности, мониторинга и аналитической деятельности, для того, чтобы определить причины ошибок и отклонений наблюдаемых процессов от требуемых.
- Моделирование
Под моделированием понимается упрощённое отображение реальности с использованием специальных средств описания (Богданов и др., 1967). До этого отображения концептуальное, абстрактное разделение обособленных и понятно связных частей характеризуемого факта производится на основе наблюдаемой действительности. При моделировании бизнес-процессов, по существу, речь идёт о том, как представить, какие субъекты (люди, машины как действующие лица), какие виды деятельности (обязанности, функции) по отношению к какому объекту (как правило, привязанная к конкретным носителям информация), с помощью каких инструментов (например, ИТ- систем), как всё это взаимодействует для достижения желаемых целей и результатов процесса. При этом формируется, во-первых, абстрактная модель процесса. Эта модель ещё независима от конкретных участников. Эти данные будут использованы в процессе организационного и информационно-технологического внедрения. Анализ процесса осуществляется целой командой участников со специфическими ролями. Здесь важно участие и тесная кооперация Экспертов, Посредников, Актёров и Начальников. Эксперты и Посредники совместно с Начальниками на первом этапе формируют видение сквозных процессов и, конечно, процессов верхнего уровня, моделирование этих процессов зависит от избранной методологии, но предпочтительно использование проверенных или известных методик типа ARIS. Затем, после определения всех исходящих и входящих дочерних процессов, можно переходить к анализу результативных процессов, т.е. процессов уровня получения конкретных результатов, в которых участвуют Актёры, и здесь роль Посредников чрезвычайно важна. Но об этом будет ещё подробно рассказано.
- Валидация
Под валидацией в рамках методологии S-BPM подразумевается проверка, является ли процесс эффективным, то есть приносит ли он ожидаемый от него результат в виде продукта или предоставления услуг. Объектом валидации считается сам бизнес-процесс и/или его модель. При валидации выясняется, соответствует ли модель, как отображение процесса, существующим задачам процесса и его ресурсам.
- Оптимизация
В то время как целью валидации является определение соответствия модели реалиям бизнеса, оптимизация отвечает за эффективность бизнес-процессов. Эффективность процесса определяется атрибутами с используемыми ресурсами, такими как, например, длительность, стоимость или частота. Оптимизация означает решение задачи нахождения оптимизированного по заданному набору параметров (т.е. в смысле организационного достижения цели с соответствующим значением присвоенных параметров) дизайна процесса со всеми необходимыми шагами. При этом в качестве ресурсных параметров могут выступать и субъекты, т.е. исполнительные механизмы и/или человеческие ресурсы. В этом случае, параметрами оптимизации могут быть компетенции исполнителей, плавающий график присутствия персонала или статистика брака в зависимости от времени суток и усталости исполнителей.
- Организационно-специфическая реализация
С помощью организационно-специфической реализации проверенные и оптимизированные процессы вводятся в существующую и, возможно, новую конструктивную организационную окружающую среду.
- Информационно-технологическая (ИТ) реализация
ИТ-реализация процесса означает его отображение в виде потока работ (воркфлоу) при интеграции с пользовательским интерфейсом, логикой обработки и соответствующей ИТ-системой.
- Мониторинг
Оптимизированные и внедрённые процессы переходят на стадию принятия на производстве (продуктивное использование) и ежедневно выполняются в организационной и ИТ-среде. Мониторинг производит во время реализации бизнес- процесса необходимые измерения и вычисляет текущие значения (as-is) для заранее определённых параметров производительности. Результаты обрабатываются в отчётности по целевым группам и предоставляются заранее выбранным адресатам. Оценка результатов, при сравнении текущих и желаемых показателей (as-is/to-be), приводит при нежелательном отклонении к анализу исследования причин и далее, в зависимости от характера необходимых мер, вновь к анализу одной из представленных ниже последовательности процедур.
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ ПРОЕКТА
Управление конфигурацией проекта или Configuration Management – это идентификация, создание, поддержание и контроль конфигурации в ходе проекта[7]. Основная задача управления конфигурацией – в любом момент времени иметь доступ к 100% актуальной версии конфигурационного элемента, которые необходимо использовать, и быть уверенным, что ни один конфигурационный элемент не конфликтует с другими конфигурационными элементами. По факту, это небольшая, но очень важная часть управления изменениями в проекте.
В соответствии с Шаблон:Cite book: Управление конфигурацией - это простой, понятный, быстрый, точный, эффективный, взвешенный и хорошо понятный процессный подход к планированию, идентификации, контролю и отслеживанию конфигурации продукта с момента его создания на протяжении всего срока службы с минимальными затратами.
Инженеры, да и многие другие виды профессий, ненавидят слово “контроль”. Слишком большой контроль снижает скорость производственной деятельности. Скорость - это элемент, отсутствующий в большинстве систем. Что еще отличает инжиниринг от других видов деятельности - это управление жизненным циклом изделия (объекта). Обратите внимание, что термин “отслеживание” используется вместо классического термина Министерства обороны “учет состояния”. Задача специалиста по управлению конфигурацией состоит в том, чтобы смешать нужное количество каждого из этих элементов в процессах управления конфигурацией – выпуске продукта и документа, спецификации, запросе на изменении. Чтобы процессы были “систематическими и хорошо понятными”, они должны быть задокументированы. Дисциплина должна быть описана в наборе стандартов, а вовлеченные в нее люди должны быть обучены этим стандартам.
Конфигурация - это техническое описание и расположение или комбинация деталей и материалов, которые способны удовлетворять требованиям, определенным спецификацией продукта, другими спецификациями и чертежами.
Управление конфигурацией в машиностроениии
Одновременно с этим существует понятие управления конфигурацией изделия (продукта): Управление конфигурацией (УК) - это управленческий процесс, оказывающий воздействие на другие процессы ЖЦ. Его цель - обеспечить соответствие создаваемого продукта заданным требованиям, а также обеспечить возможность контроля заинтересованными сторонами того, что создаваемый продукт соответствует их потребностям. Для решения задач УК сложного изделия выполняют декомпозицию исходного объекта анализа на отдельные управляемые объекты - объекты конфигурации. В качестве объекта конфигурации (далее для удобства также используется термин "объект") может выступать изделие (комплект, комплекс, сборочная единица, деталь), система, программное обеспечение, аппаратное обеспечение, материал, отдельный документ, объект инфраструктуры и т.п.
Управление конфигурацией в программной инженерии
Конфигурационное управление (англ. software configuration management, SCM) в программной инженерии — комплекс методов, направленных на систематический учёт изменений, вносимых разработчиками в программный продукт в процессе его разработки и сопровождения, сохранение целостности системы после изменений, предотвращение нежелательных и непредсказуемых эффектов, формализацию процесса внесения изменений. В связи с высокой динамичностью сферы разработки ПО, в ней конфигурационное управление особенно полезно. К процедурам можно отнести создание резервных копий, контроль исходного кода, требований проекта, документации и т. д. Степень формальности выполнения данных процедур зависит от размеров проекта, и при правильной её оценке данная концепция может быть очень полезна.
Цели конфигурационного управления:
- Контроль: SCM позволяет отслеживать изменения в контролируемых объектах, обеспечивает соблюдение процесса разработки;
- Управление: SCM диктует процесс автоматической идентификации в ходе всего жизненного цикла ПО, обеспечивает простоту модификации и сопровождения ПО;
- Качество;
Задачи конфигурационного управления:
- идентификация конфигурации;
- контроль конфигурации: контроль над изменениями материалов;
- учёт текущего состояния: состояние документов, состояние кода, состояние отдельных задач и всего проекта в целом;
- управление процессом разработки;
- управление сборкой;
- управление окружением;
- отслеживание задач и проблем (в частности, отслеживание ошибок);
Управление конфигруацией в ИТ
Configuration Management Database (CMDB) = Базы данных управления конфигурациями
Многие организации стремятся основывать ИТ-управление на базе CMDB. База данных CMDB содержит данные, описывающие управляемые ресурсы, такие как компьютерные системы и прикладное программное обеспечение, артефакты процесса, такие как записи об инцидентах, проблемах и изменениях, а также взаимосвязи между этими объектами. Данные могут включать в себя авторизованные базовые параметры конфигурации или моментальные снимки текущего состояния ИТ-среды. Содержимое базы данных CMDB часто управляется процессом управления сервисными активами и конфигурациями и служит основой и точкой интеграции для других процессов управления ИТ, таких как управление изменениями и управление доступностью.
CMDB может быть частью системы управления конфигурацией. Он может интегрировать другие хранилища управленческих данных (MDRs), в том числе другие CMDB. Полезность CMDB зависит от качества, надежности и безопасности данных, организованных с помощью CMDB. На практике эта цель является сложной задачей, поскольку данные управления хранятся в MDRS, которые используют разные модели данных и поддерживают разные интерфейсы доступа. Примерами потенциальных MDRs являются CIM Object Manager (CIMOM), инструменты поставщиков и собственные хранилища данных клиентов.
Решение, предполагающее преобразование всех данных в единую модель данных или объединение всех данных в едином хранилище, не является ни практичным, ни желательным. Что необходимо, так это решение для объединения разнородных MDRs, включая объединение всех данных об ИТ-ресурсе, даже если данные для ресурса могут быть распределены по нескольким MDRs. ИТ-ресурсы включают элементы конфигурации (например, компьютеры, программное обеспечение, службы, здания), артефакты процесса (например, записи об инцидентах и формы запроса на изменение) и взаимосвязи между ними. Каждый ресурс, включая отношения, может иметь отдельно управляемый жизненный цикл, а его состояние может быть представлено набором свойств.
Процедуры управления конфигурацией
Ревизия конфигурации — процесс проверки соответствия документа нижнего уровня всем требованиям верхнего.
Аудит конфигурации — процесс проверки соответствия готового продукта или его части документации.
Контроль конфигурации — процесс, при котором все предлагаемые изменения продукта проходят одобрение специальной группы (или отдельного человека). Одна из функций такой группы — контроль актуальности всех имеющихся документов, а также контроль того что все изменения сначала вносятся в документацию, а уже затем в объект изменения.
Учет состояния конфигурации — процесс подготовки отчетов о текущем состоянии продукта и состоянии утверждённых изменений.
Стандарты
В части управления конфигурацией существует достаточно большое количество стандартов:
- ГОСТ Р 59193-2020 УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ. Основные положения, который разработан в рамках ТК 482 "Поддержка жизненного цикла экспортируемой продукции военного и продукции двойного назначения"
- Configuration Management Database (CMDB) Federation Specification
Предшествующие технологии
Информационные технологии
Начинать нужно всегда с терминов и определений, который приведены в ГОСТ Р 52292-2004 "Информационная технология. ЭЛЕКТРОННЫЙ ОБМЕН ИНФОРМАЦИЕЙ. Термины и определения"
История развития технологий моделирования
Безусловно делать выводы о целесообразности разработки нового подхода или новой модели данных необходимо проведя комплексный анализ узе существующих методологий, технологий и практики. Детальный исторический анализ приведен в отдельном разделе "Истрия развития информационного моделирования в мире"
Однако необходимо обратить внимание на развития вычислительных или алгоритмических подходов в различных дисциплинах. На наш взгляд в настоящее время в строительстве и в инженерном деле в целом "вычислительные дисциплины" или "алгоритмические дисциплины" выходят на первый план, что создает новые возможности при использовании информационных технологий и моделирования в частности.
В качестве отправной точки очень полезно изучить отчет английского центра развития исследований и инноваций: "A Survey of Industry Data Models and Reference Data Libraries: To identify requirements for, and provide input to, a Foundation Data Model" Шаблон:Citation
Геометрическое моделирование
В информатике вычислительная геометрия - это изучение алгоритмов для решения задач, сформулированных в терминах геометрии. Некоторые чисто геометрические проблемы возникают в результате изучения вычислительных геометрических алгоритмов, и изучение таких проблем также считается частью вычислительной геометрии.
Основным стимулом для развития вычислительной геометрии как дисциплины был прогресс в компьютерной графике, автоматизированном проектировании и производстве (CAD / CAM), но многие проблемы в вычислительной геометрии носят классический характер.
Другие важные области применения вычислительной геометрии включают робототехнику (планирование движения и проблемы видимости), географические информационные системы (ГИС) (геометрическое местоположение и поиск, планирование маршрутов), проектирование интегральных схем (проектирование и проверка геометрии ИС), автоматизированное проектирование (CAE) (программирование машин с числовым программным управлением (ЧПУ)).
Тремя основными разделами вычислительной геометрии являются:
- Комбинаторная вычислительная геометрия, также называемая алгоритмической геометрией, которая имеет дело с геометрическими объектами как с дискретными объектами.
- Числовая геометрия, также называемая машинной геометрией, автоматизированным геометрическим проектированием (CAGD) или геометрическим моделированием, которая в основном связана с представлением объектов реального мира в формах, подходящих для компьютерных вычислений в системах CAD / CAM. Эта ветвь может рассматриваться как дальнейшее развитие начертательной геометрии и часто считается ветвью компьютерной графики и / или САПР, тогда как первую ветвь часто называют просто вычислительной геометрией.
- Нечисловая геометрия, которая изучает и разрабатывает нечисловые геометрические алгоритмы. Это старейшая ветвь вычислительной геометрии, которая восходит к геометрическим построениям с помощью линейки и циркуля. Алгоритмы геометрических построений являются душой и источником геометрии и не являются числовыми по своей природе. Хотя до недавнего времени такие построения можно было выполнять только с помощью линейки и циркуля, два десятилетия назад появились новые средства геометрических построений. Это были различные оптические устройства, способные манипулировать изображениями геометрических фигур, такие как зеркала, светоделители, голограммы и т.д.
Наблюдение о том, что геометрические построения могут быть выполнены оптически, а не с помощью линейки и циркуля, легло в основу "Оптической вычислительной геометрии", выдвинутой Евгением Карасиком в 1990 году.
Геопространственное информационное моделирование
Геонформатика и Геоинформационные системы, можно сказать, стали первопроходцами в области информационного моделирования. Разработчики этих систем одними из первых осознали что геометрические данные (вне зависимости от представления растрового или векторного) должны быть отделены от атрибутивных данных. Уровень проработки и зрелости данной технологии можно оценить по количеству стандартов, которые разработаны и разрабатываются Открытым геопространственным консорциумом (OGC). Однако на наш взгляд ключевым результатом развития геоинформационных технологий является значительный объем исследований в области абстракции данных. Так, например для структурированния информации в рамках геоинформационных систем сформированы абстрактные классы: Abstract Specifications:
Именно по этой пречине стоит обратить внимание на эти материалы. Более подробнее познакомиться с этой информацией можно в разделе Геоинформационные системы.
Стоит отметить, что в Европе вопросами пространственных даных занимается отдельная организация infrustructure for spatial infomation in Eroupe (INSPIRE). Материалы, которые выпускает данная организация доступны по ссылке: https://inspire.ec.europa.eu/docs
Common Information Model
В телекоммуникационной отрасли также шло активное развитие подходов к описанию телекоммуникационной инфраструктуры. В результаты работы Distributed Management Task Force и при поддержке CIM Forum был разработан стандарт Common Information Model.
Common Information Model (общая информационная модель, CIM) — открытый стандарт, определяющий представление управляемых элементов IT среды в виде совокупности объектов и их отношений, предназначенный обеспечить унифицированный способ управления такими объектами, вне зависимости от их поставщика или производителя.
Стандарт CIM включает в себя Спецификацию и Схему, а также Метамодель:
Схема управления CIM
Схема CIM предоставляет фактические описания моделей. Схемы управления являются строительными блоками для платформ управления и приложений управления, таких как настройка устройств, управление производительностью и управление изменениями. CIM структурирует управляемую среду как совокупность взаимосвязанных систем, каждая из которых состоит из отдельных элементов.
Предоставляя набор классов со свойствами и ассоциациями, которые обеспечивают хорошо понятную концептуальную основу, CIM организует информацию об управляемой среде. Схема CIM структурирована на эти отдельные уровни: базовая модель, общая модель, схемы расширения.
Если вы хотите загрузить HTML или XML-версии схемы CIM, пожалуйста, выберите нужную вам версию здесь.
Спецификация CIM
CIM может использоваться многими способами, и спецификация CIM определяет детали для интеграции с другими моделями управления. Информационная модель требует набора типов или синтаксиса юридических утверждений и набора выражений для управления общими аспектами предметной области (в данном случае сложными компьютерными системами). В CIM информация для выполнения задач организована таким образом, чтобы ее могли использовать разрозненные группы людей.
Метамодель CIM
Метамодель CIM определяет семантику для построения новых соответствующих моделей и схему, которая представляет эти модели. Требования к моделированию и среда часто различаются и меняются с течением времени. Метамодель дополнительно расширена за счет возможности расширения ее элементов за счет использования классификаторов.
Актуальные версии
DSP # | Версия | Наименование | Дата |
---|---|---|---|
DSP0221 | 3.0.0 | Managed Object Format Specification | 13 Dec 2012 |
DSP0219 | 1.0.0 | UML Profile for CIM | 11 Aug 2009 |
DSP0004 | 3.0.1 | Common Information Model (CIM) Metamodel | 30 Aug 2014 |
-- | 2.54.1 | CIM Schema | 8 Mar 2022 |
Предметно-ориентированные модели на языке Modelica
С 1996 года некоммерческая Ассоциация Modelica разрабатывает согласованные стандарты открытого доступа и программное обеспечение с открытым исходным кодом в области киберфизических систем.
Действующие стандарты Ассоциации Modelica:
- Язык Modelica
- Функциональный макет интерфейса - Functional Mock-up Interface (FMI)
- Структура и параметризация системы - System Structure and Parameterization (SSP)
- Протокол распределенного совместного моделирования - Distributed Co-Simulation Protocol (DCP)
- Функциональный макет интерфейса для встраиваемых систем - Functional Mock-up Interface for embedded Systems (eFMI)
Все стандарты сопровождаются программным обеспечением с открытым исходным кодом для поддержки использования стандарта, таким как Стандартная библиотека Modelica, содержащая около 1600 компонентов модели Modelica во многих областях, другие библиотеки Modelica с открытым исходным кодом или средство проверки соответствия FMI для проверки соответствия модели требованиям стандарта FMI.
Крупные исследовательские проекты тратят более 100 млн евро в 2007-2022 годах на дальнейшее совершенствование языка Modelica, библиотек Modelica, FMI, eFMI, DCP и связанных с ними технологий: EMPHYSIS, EUROSYSLIB, MODELISAR, OPENPROD, MODRIO, ACOSAR, OPENCPS, EMPHYSIS и IBPSA Project 1.
Стандарт языка Modelica
Стандарт языка Modelica определяет объектно-ориентированный язык на основе уравнений для описания киберфизических систем на высоком уровне с использованием физических или сигнальных соединителей. Модели Modelica от разных сторон и / или разных инструментов могут быть составлены вместе, и результирующая система может быть смоделирована или проанализирована другими средствами. Инструменты Modelica поддерживают экспорт и импорт моделей в формате Modelica или FMI.
Стандарт Functional Mock-Up Interface (FMI)
Стандарт Functional Mock-Up Interface (FMI) определяет контейнер zip-файлов для описания, обмена и хранения артефактов моделирования, используя комбинацию xml-файлов, статических и динамических связанных двоичных файлов и/или C-кода. FMI определяет семантический и прикладной программный интерфейс (API) для выполнения (или включения таких артефактов) в приложениях моделирования. Поддерживаются как обмен моделями (доступ к системе гибридных обыкновенных дифференциальных уравнений), так и совместное моделирование (решатель является частью артефакта) моделей киберфизических систем. Например, FMI для совместного моделирования определяет C-функции для инициализации системы, установки параметров и входных переменных, выполнения одного шага моделирования и запроса выходных значений.
Стандарт System Structure and Parameterization (SSP)
Стандарт System Structure and Parameterization (SSP) логически описывает, как компоненты модели соединяются и, возможно (иерархически) составляются в составные компоненты, а также как данные параметризации модели хранятся и обмениваются между ними. Компоненты могут присутствовать на разных компьютерах. SSP совместим с FMI по своей конструкции.
Стандарт Distributed Co-Simulation Protocol (DCP)
Стандарт Distributed Co-Simulation Protocol (DCP) - это протокол связи прикладного уровня. Он предназначен для интеграции моделей или систем реального времени в среду моделирования. Он позволяет обмениваться конфигурационной информацией и данными, связанными с моделированием, с помощью базовой системы связи (такой как UDP, TCP или CAN). В то же время DCP поддерживает интеграцию инструментов и систем реального времени от разных поставщиков. DCP предназначен для повышения эффективности рабочих процессов, основанных на моделировании, и снижения затрат на интеграцию. DCP совместим с FMI по своей конструкции.
Стандарт Functional Mock-up Interface for embedded systems (eFMI)
Стандарт Functional Mock-up Interface for embedded systems (eFMI) - это открытый стандарт для поэтапной разработки расширенных функций управления, подходящих для критически важных для безопасности целей и задач в реальном времени. Это позволяет применять (физические) модели во встроенном программном обеспечении, предоставляя стандартизированную контейнерную архитектуру для поэтапной доработки первого высокоуровневого алгоритмического решения для реальной встроенной реализации в выделенной целевой среде, такой как электронный блок управления (ECU) или микроконтроллер. С этой целью стандарт определяет различные представления моделей в процессе уточнения от (физической) модели до встроенного программного обеспечения: (1) Поведенческие / эталонные результаты для тестирования (контейнеры поведенческих моделей), (2) Независимое от цели ограниченное алгоритмическое решение (Контейнер кода алгоритма) на основе языка программирования GALEC, (3) Реализации C, адаптированные и оптимизированные для требований конкретных целевых сред (контейнеры производственного кода) и (4) Двоичные дистрибутивы и их „рецепты сборки“, готовые для интеграции во встроенную систему (контейнеры двоичного кода).
Библиотека Physiolibrary
Physiolibrary is a free open-source Modelica library designed for modeling human physiology. This library contains basic physical laws governing human physiology, usable for cardiovascular circulation, metabolic processes, nutrient distribution, thermoregulation, gases transport, electrolyte regulation, water distribution, hormonal regulation and pharmacological regulation.
Интерактивные документы
Впервые автор этой концепции столкнулся с интерактивными документами при работе с системой вычислительной математике от Wolfram Research - Mathematica. Данная система использовала встроенный вычислительный язык Alpha, который позволял проводить вычисления не только математических вычислений, но и дозволял получать данные для химических и физических вычислений используя термины, оформленные по определенным правилам. Одновременно с этим в продуктовой линейке Wolfram Rsearch есть специальное приложение WOLFRAM PLAYER, которое позволяло не просто использовать интерактивные возможности среды Matemetica, но и позволяло сохранить специальный документ, который можно было передать Заказчику или коллеге для того, чтобы он мог познакомиться с результатами исследования или расчетов в интерактивном режиме. При этом все параметры расчетов можно было изменять и анализировать поведение исследуемой системы в зависимости от параметров. Позже, когда заинтересовался интерактивными документами обнаружилось некоторое количество научных исследований на данную тему, ссылки на которые постараюсь позже разместить. В качестве современных регулярно используемых примеров таких документов - можно рассматривать интерактивные рабочие тетради для Python и Julia. Развитие прокта интеграктивных (вычислимых документов) получило свое развитие в открытом проекте https://jupyter.org Описание формата bnformat доступно по ссылке: https://github.com/jupyter/nbformat или https://nbformat.readthedocs.io/en/latest/ . Проверка формата докуентов осуществляется в соответствии со схемой, которая размещена по ссылке: https://github.com/jupyter/nbformat/blob/main/nbformat/v4/nbformat.v4.schema.json . Еще одна статья по поводу вычислимых документов доступна на HABR
Смарт Контракты
Развитие области Смарт контактов позволяет сформировать целый пласт новых технических возможностей применим ТиМ
"Умные" стандарты
Умные стандарты предполагают возможность автоматизированного анализа и извлечение смысла из нормативных документов с целью последующей обработки этих данных. Подробнее можно прочитать по ссылке
Концепция информационного моделирования
Все этой приводит нас к формированию в рамках концепции информационного моделирования инфраструктуры интерактивных документов, которые могут быть переданы в качестве результатов работы инженера по определенной теме.
Building Information Modelling
Разработку данной технологии курирует международная ассоциация buildingSMART.
Краткая информация о деятельности ассоциации
Ценностями ассоциации являются:
- Нейтральный и независимый, и поэтому не обязанный какой-либо группе или компании, будь то поставщики программного обеспечения, строительные компании, архитекторы или другие, или даже правительства;
- Открытый и прозрачный, потому что процессы, с помощью которых работает bSI, должны быть понятны и понятны всем, чтобы продемонстрировать свою независимость и нейтралитет;
- Некоммерческая организация, что означает, что любая прибыль, которую она может получить от коммерческой или квазикоммерческой деятельности, используется в некоммерческих целях, таких как разработка стандартов.
Целями ассоциации в реализации своей миссии являются:
- Разработка и поддержание открытых международных стандартов информационного моделирования зданий (open BIM);
- Ускорить освоение рынком интероперабельности с помощью успешных устойчивых проектов;
- Для предоставления сетевых возможностей, спецификаций и письменных рекомендаций;
- Для решения дорогостоящих проблем, препятствующих обмену данными,
- Распространить процессы и технологии buildingSMART на всю строительную среду на протяжении всего ее жизненного цикла, включая руководство, производство, управление объектами и техническое обслуживание.
buildingSMART разрабатывает открытые стандарты информационного моделирования зданий, open BIM. Стандарты касаются моделей данных, процессов и терминов. Спецификация IFC Industry Foundation Classes представляет собой спецификацию buildingSMART для модели данных buildingSMART. Термины свойств, определенные в IFC, связаны с терминами, определенными в словаре данных buildingSMART. buildingSMART поддерживает связь с Международной организацией по стандартизации ISO, региональными и национальными органами по стандартизации для разработки международных, региональных и национальных стандартов. Спецификация IFC Industry Foundation Classes зарегистрирована как ISO 16739. buildingSMART активно работает в качестве организации по связям с ISO /TC 59/SC 13. Дальнейшие версии IFC будут представлены в ISO /TC 59/ SC 13/JWG 12 для принятия в качестве следующих дополнений или выпусков ISO 16739.
Краткая информация о модели данных
Соответствующее программное приложение требуется для поддержки четко определенного подмножества схемы данных и ссылочных данных. Подмножество, на которое он ссылался как MVD определения представления модели. Конкретное определение представления модели определяется для поддержки одного или нескольких признанных рабочих потоков в секторе строительства зданий и управления объектами. Каждый рабочий процесс определяет требования к обмену данными, которые должны поддерживаться соответствующими программными приложениями.
buildingSMART International публикует официальные определения представления модели и требования к обмену в качестве соответствующих спецификаций. Официальный веб-сайт для публикации этой спецификации, соответствующих определений представления модели и требований к обмену, а также вспомогательных материалов, таких как соглашения с разработчиками, примеры наборов данных, ссылки на инструменты разработки, дискуссионный форум и базу данных проблем, а также программы сертификации, является technical.buildinsmart.org. Документация публикуется по адресу standards.buildingsmart.org.
Спецификация IFC включает термины, концепции и элементы спецификации данных, которые используются в рамках дисциплин, контрактов и профессий сектора строительства и управления объектами. Термины и понятия используют простые английские слова, элементы данных в спецификации данных соответствуют соглашению об именовании:
- имена элементов данных для типов, сущностей, правил и функций начинаются с префикса "Ifc" и продолжаются английскими словами в соглашении об именовании camelCase (без подчеркивания, первая буква в word в верхнем регистре);
- имена атрибутов внутри объекта соответствуют соглашению об именовании camelCase без префикса;
- определения набора свойств, являющиеся частью этого стандарта, начинаются с префикса "Pset_" и продолжаются английскими словами в соглашении об именовании camelCase;
- определения набора количеств, которые являются частью этого стандарта, начинаются с префикса "Qto_" и продолжаются английскими словами в соглашении об именовании camelCase.
Архитектура схемы данных IFC определяет четыре концептуальных уровня, каждая отдельная схема назначается ровно одному концептуальному уровню. На рисунке 1 показана архитектура схемы
- уровень ресурсов — самый низкий уровень включает в себя все отдельные схемы, содержащие определения ресурсов, эти определения не включают глобально уникальный идентификатор и не должны использоваться независимо от определения, объявленного на более высоком уровне;
- Базовый уровень — следующий уровень включает в себя схему ядра и схемы расширения ядра, содержащие наиболее общие определения сущностей, все сущности, определенные на базовом уровне или выше, имеют глобально уникальный идентификатор и, возможно, информацию о владельце и истории;
- Уровень интероперабельности — следующий уровень включает схемы, содержащие определения сущностей, которые специфичны для общего продукта, процесса или специализации ресурсов, используемых в нескольких дисциплинах, эти определения обычно используются для междоменного обмена и совместного использования информации о конструкции;
- Уровень домена — самый высокий уровень включает схемы, содержащие определения сущностей, которые являются специализациями продуктов, процессов или ресурсов, специфичных для определенной дисциплины, эти определения обычно используются для обмена информацией внутри домена и обмена информацией.
Область применения
Industry Foundation Classes, IFC, представляют собой открытый международный стандарт модели данных для информационной модели здания (BIM), которые обмениваются и совместно используются программными приложениями, используемыми различными участниками сектора строительства или управления объектами. Стандарт включает определения, которые охватывают данные, необходимые для зданий и мостов на протяжении их жизненного цикла. Этот выпуск и предстоящие выпуски расширяют область применения, включая определения данных для инфраструктурных активов на протяжении их жизненного цикла. Industry Foundation Classes определяют схему данных и структуру формата файла обмена. Схема данных определена
- на языке спецификации данных EXPRESS, определенном в стандарте ISO 10303-11,
- на языке определения схемы XML (XSD), определенном в рекомендациях XML Schema W3C,
в то время как определение схемы EXPRESS является исходным, а определение схемы XML генерируется из схемы на языке EXPRESS в соответствии с правилами сопоставления, определенными в ISO 10303-28. Обменные форматы файлов для обмена и совместного использования данных в соответствии с концептуальной схемой являются
- Кодирование открытого текста структуры exchange, определенное в стандарте ISO 10303-21,
- Расширяемый язык разметки (XML), определенный в Рекомендации XML W3C.
Могут использоваться альтернативные форматы файлов обмена данными, если они соответствуют данной схеме данных.
Подмножество схемы данных и ссылочных данных называется Model View Definition (MVD). Конкретный MVD определяется для поддержки одного или нескольких признанных рабочих процессов в секторе строительства и управления объектами. Каждый рабочий процесс определяет требования к обмену данными для программных приложений. Соответствующие программные приложения должны идентифицировать определение представления модели, которому они соответствуют.
Форматы хранения и обработки данных
Открытые форматы
Пространственные данные
C3D file format
Наименование: Coordinate 3D files
Источник: https://www.c3d.org/overview.html
Краткое описание: Формат файла C3D предназначен для хранения необработанных данных из среды сбора 3D-данных, каждый набор данных хранится в виде одной пробной версии необработанных 3D-координат и аналоговых выборок с определенным разделом параметров, который описывает свойства данных каждого файла. Все ранние файлы C3D включали данные о вкладе камеры и остаточный объем 3D-вычислений, сохраненный с каждой 3D-координатой, что позволяло постоянно контролировать и оценивать качество и точность каждого записанного значения 3D-данных. Одновременно во время каждого 3D-кадра можно отбирать несколько выборок аналоговых данных, чтобы гарантировать временную синхронизацию, при этом каждая аналоговая выборка записывается как значение, непосредственно считываемое с АЦП, и записывается как необработанные значения выборки. В целом дизайн формата C3D позволяет сохранять все собранные данные с минимальной обработкой и позволяет пользователю проверять качество необработанных и необработанных 3D- и аналоговых данных, собранных во время эксперимента. Однако, по мере развития систем сбора данных, многие производители начали обрабатывать необработанные выборочные данные перед созданием файла C3D и создали свои собственные дополнительные значения данных в файле в виде псевдо-3D точек для хранения обработанных и вычисленных значений данных. Хотя это не нарушает спецификацию C3D, это означает, что конечные пользователи теперь должны безоговорочно доверять усилиям своего производителя по сбору и обработке данных, поскольку многие файлы C3D в наши дни не содержат никаких необработанных данных, поскольку производитель удалил исходные “необработанные” данные из наблюдения. Это означает, что любые ошибки при сборе и обработке данных до создания файла C3D эффективно скрываются от конечного пользователя в интересах производителя, предотвращая оценку качества процесса сбора данных.
Universal Scene Description
Источник: https://openusd.org
Конвейеры, способные создавать фильмы и игры с компьютерной графикой, обычно генерируют, хранят и передают большие объемы 3D-данных, которые мы называем “описанием сцены”. Каждое из множества взаимодействующих приложений в процессе разработки (моделирование, затенение, анимация, освещение, fx, рендеринг) обычно имеет свою собственную специальную форму описания сцены, адаптированную к конкретным потребностям и рабочим процессам приложения, которая не доступна для чтения или редактирования никаким другим приложением. Universal Scene Description (USD) - это первое общедоступное программное обеспечение, которое удовлетворяет потребность в надежном и масштабируемом обмене и дополнении произвольных 3D-сцен, которые могут быть составлены из множества элементарных элементов.
USD позволяет обмениваться элементарными активами (например, моделями) или анимацией. Но, в отличие от других пакетов обмена, USD также позволяет собирать и организовывать любое количество ресурсов в виртуальные наборы, сцены, кадры и миры, передавать их из приложения в приложение и редактировать без разрушения (как переопределения) с помощью единого согласованного API в одном scenegraph. USD предоставляет богатый набор инструментов для чтения, записи, редактирования и быстрого предварительного просмотра 3D-геометрии, затенения, освещения, физики и растущего числа других областей, связанных с графикой. Кроме того, поскольку ядро USD scenegraph и механизм компоновки не зависят от какого-либо конкретного домена, USD можно легко расширить для кодирования и компоновки данных в других доменах.
В частности, USD - это проект с открытым исходным кодом, выпущенный под лицензией TOST.
Атрибутивные данные
Компьютерные модели
Закрытые форматы
Пространственные данные
Атрибутивные данные
Компьютерные модели
Сравнительный анализ форматов
Общие положения концепции
Технологии Информационного Моделирования (ТИМ)
Технология информационного моделирования - это результат развития предшествующих методологий и технологий, который в конечном итоге сформируют единую технологию информационного моделирования[8]. Концепция Единой системы информационного моделирования основанную на комплексном системном подходе. Определяет принципы, цели и задачи применения технологий информационного моделирования в различных отраслях экономики обеспечивая тем самым междисциплинарный подход. Одновременно с этим данная концепция формирует общее понимание применения цифровых технологий и методологический переход от традиционного – документно-ориентированного подхода к моделе-ориентированному и дата-ориентированному подходам. Опираясь на указанные подходы в рамках настоящей концепции, формируется взаимосвязь с национальными нормативно-техническими комплексами, такими как Единая система конструкторской документации (ЕСКД), Система проектной документации в строительстве (СПДС) и другими стандартами в области инженерной деятельности. Настоящий стандарт определяет общую методологию формирования, хранения и обращения с информационными моделями антропогенных объектов различного назначения.
Основное назначение концепции ЕСИМ заключается в установлении единых методологических правил информационного моделирования, обеспечивающих, прежде всего:
- взаимосвязь положений различных нормативно-технических документов ЕСИМ, исключающую противоречия в их толковании;
- унификацию состава, содержания, модели данных, правил выполнения, оформления, обращения и применения информационных моделей с учетом их назначения;
- организацию информационного обмена участников процессов жизненного цикла объекта, в том числе перевод в машиночитаемый вид и передачу информации;
- применение современных информационных технологий, методов и средств управления данными объектов;
- возможность гармонизации нормативно-технических документов ЕСИМ с международными стандартами в области информационного моделирования;
- формирование основы для использования различных контрактных условий на консультационные услуги в области информационного моделирования, в частности применение интегрированных контрактов и других видов контрактов;
- объединение и формирование единого методологического подхода для интеграции и использования геоинформационных систем (ГИС) и
- формирование основы для развития информационного моделирования как передовой цифровой платформы, обеспечивающей переход на дата-ориентированный подход в инжиниринге и строительстве, с последующим полным переходом на безбумажные технологии.
Общие методологические правила, определяемые концепцией ЕСИМ, распространяются на:
- принципы, требования и рекомендации ко всем видам деятельности, связанным с применением технологии информационного моделирования для различных видов антропогенных объектов, территорий и ОКС на всех стадиях жизненного цикла;
- принципы, требования и рекомендации к описанию процессов управления и методам создания ИМ на всех стадиях жизненного цикла антропогенных объектов, территорий и ОКС, для последующего обмена, хранения, актуализации и использования данных ИМ;
- принципы, требования и рекомендации по применению библиотек компонентов информационного моделирования;
- принципы, требования, рекомендации и форматы данных для организации обмена информационными моделями, а также организации архивов информационных моделей долгосрочного архивного хранения;
- принципы, требования и рекомендации по взаимодействию проектных, строительных, машиностроительных и других предприятий участвующих в создании сложных технических объектов.
В целях исключения дублирования терминов и определений, а также противоречий в документах национальной системы стандартизации Российской Федерации, все национальные стандарты Российской Федерации в области информационного моделирования следует разрабатывать с учетом концепции ЕСИМ и стандарта ГОСТ Р 10.00.0002-202х Единая система информационного моделирования. Термины и определения.
Основой для разработки концепции информационного моделирования послужили как российские, так и зарубежные разработки в области системного анализа и инженерии. В частности, проект EPISTLE[24], разработка языка EXPRESS[25, 26], разработка стандартов ISO 15926[20], опыт использования ГОСТ 34 серии, IEC 61970[6] и т.д.
В монографии "Управление бизнес-процессами: современные методы"[9] приводится методология анализа и моделирования бизнес-процессов: субъектно-ориентированный подход.
Субъектно-ориентированный подход к процессам означает отказ от ориентации, сосредоточенной исключительно на результатах. Успех деятельности может быть достигнут только при высокой степени удовлетворённости и взаимной интеграции заинтересованных сторон (работодателя и работника), и их соучастия в достижении результата. Отсутствие знаний о бизнес-процессах и их деталях может привести к неверным решениям с негативными последствиями. Искажённые или неполные знания процессов неизбежно приводят к финансовым потерям и издержкам в организации. Для анализа процессов используется понятие Workflow – упорядоченное во времени множество рабочих заданий, получаемых и обрабатываемых сотрудниками с помощью средств механизации/автоматизации и/или вручную, но в тех последовательностях и в рамках тех правил, которые определены для данного бизнес-процесса. Данное определение приводит международная организация стандартизации методов автоматизации рабочих процессов. [Workflow Management Coalition]
Необходимыми являются:
- Ориентация на продукт: рыночная ориентация на партнёров и продукты включает в себя сервисы и программное обеспечение и является одним из существенных факторов в рамках организации процессов. Применение ресурсов организации (Информации, Материала, Компетенций и т.п.) распространяется на весь жизненный цикл продукта[10].
- Ориентация на клиентов и рынок: в дополнение к ориентации на продукты клиенто- ориентированность выступает в качестве такого же важного фактора. Даже сам жизненный цикл продукта должен быть согласован с представлениями клиента (напр., экологичность продукта в рамках дебатов по поводу защиты климата или использования генно-модифицированных продуктов питания). Тем не менее, при разработке и производстве товаров и услуг всё ещё превалируют принципы экономии.
- Системное мышление: требуется на всех уровнях во время рассмотрения всех процессов компании, особенно в процессах принятия решений, рассмотрения контекста и обмена информацией за пределами системы.
- Мышление в терминах моделей: отображение потенциалов и текущих проблем через абстракцию: (события и структуры). Определение «сущности» без потери связи с целью выходит на первый план.
Уровень зрелости процесса – это степень, до которой процесс определён, управляем, измеряем, контролируем и эффективен.
Концепция информационного моделирования базируется на следующих стандартах и комплексах стандартов:
ГОСТ Р 58179-2018 Инжиниринг в строительстве. Термины и определения.
ГОСТ 15971-90. Системы обработки информации. Термины и определения.
ГОСТ Р 57700.3-2017 Численное моделирование динамических рабочих процессов в социотехнических системах. Термины и определения.
ГОСТ Р 57700.19-2019 Численное моделирование динамических рабочих процессов в социотехнических системах. Требования к архитектуре процессов.
ГОСТ Р 52294-2004 Информационная технология (ИТ). Управление организацией. Электронный регламент административной и служебной деятельности. Основные положения.
ГОСТ Р 52294-2004 Информационная технология (ИТ). Управление организацией. Электронный регламент административной и служебной деятельности. Основные положения.
ГОСТ Р 57269-2016 Интегрированный подход к управлению информацией жизненного цикла антропогенных объектов и сред. Термины и определения (Переиздание).
ГОСТ Р ИСО 22274-2016 Системы управления терминологией, базами знаний и контентом. Концептуальные аспекты разработки и интернационализации систем классификации (Переиздание).
ПНСТ 434-2020 (ИСО 16300-1:2018) Умное производство. Интероперабельность единиц возможностей для промышленных прикладных решений. Часть 1. Критерии интероперабельности единиц возможностей согласно требованиям к применению.
Информационная модель
Определение информационной модели
Традиционно различные аспект физических объектов и окружающей среды выделяются в отдельные области исследования и рассматриваются в отрыве от большого количества связанных параметров других предметных областей. Что приводит к невозможности применения в полном объеме системного подхода. Ранее данный подход был обусловлен сложностью сопровождения больших объемов информации и ограничениями технических средств, однако с началом применения технологий компьютерного и в последствии информационного моделирования данная задача может быть решена с применением современных технических средств, в частности высокопроизводительными системами. Эта информация сопровождается различными группами пользователей или исследователей, результатом чего является дублирование информации, одностороннее ее изучение и требует значительных усилий по интеграции. Для целей последовательного формирования системного взгляда на технологии информационного моделирования и одновременного формирования концепции единой системы информационного моделирования будет рассматривать технологию от отдельных понятий до методов её использования. Безусловно имеет смысл формирования понятийного аппарата с определения понятия информации. Информация − важнейший компонент (объект) любого информационного процесса. Под информационным процессом будем понимать процесс сбора (отражения, восприятия), фиксирования, отображения на различные носители, передачи, обработки (преобразования), хранения и использования информации. Информационный процесс может состояться только при наличии информационной системы, обеспечивающей все его составляющие − источник информации, канал связи, соглашения (правила) интерпретации сигналов и приемник информации.[11, с. 10] В современном мире термин информация включает не только совокупность данных, но и обмен сведениями между людьми, человеком и автоматом (ЭВМ), автоматом и автоматом, обмен сигналами в животном и растительном мире, передачу признаков от клетки к клетке, от организма к организму. В последнее время все чаще звучит термин Big Data, который подразумевает обработку огромных объемов данных с помощью компьютеров. Чтобы как-то структурировать информацию кроме классических классификаторов, таксономии и онтологии предлагаю ввести термин «Информационный набор», который будет означать структурированную информацию по определённой теме или задаче. Как известно один и тот же объект можно рассматривать с разных сторон и исследовании разных задач. В результате будут сформированы различные информационные наборы, описывающие объект исследования. Объединение в единое целое различных информационных наборов позволяет говорит о необходимости рассмотрения каждого исследуемого объекта как сложной динамической системы. Поэтому, прежде чем перейти к определению системы необходимо ввести еще несколько понятий: Качество — это внутренне присущая предметам и явлениям определенность, органическое единство свойств, признаков, особенностей, отличающих данный предмет или явление от других. Качество есть то, что делает предметы или явления тем, что они есть, данными, а не другими[17]. Вещь (сущность) — это система качеств. Различные сущности — это различные системы качеств. Одна и та же сущьность — это одна и та же система качеств. Качественное понимание вещи является единым и в онтологическом, и в логическом, и в грамматическом планах[17]. Свойство это общее всем сущностям данного класса. Свойства в их отношении к сущностям можно разбить на две группы. Свойства одной группы являются границей данной вещи, т. е. с исчезновением этого свойства данная вещь превращается в другую. Такие свойства назовем качествами сущности. Иными словами, качество - это существенное свойство. Свойства другой группы не являются границами данной сущности. Их будем называть просто свойствами [17]. Отношение – взаимосвязь между элементами системы или сторонами объекта, возникающая при наличии информационного обмена с использованием канала связи. Отношением будет называться то, что образует сущность из данных элементов. Этими элементами в свою очередь могут быть свойства или другие сущности [17]. Есть разные варианты определения системы [3]: Определение 1: Система комплекс взаимодействующих элементов. Определение 2: Система упорядоченное определенным образом множество элементов, взаимосвязанных между собой и образующих некоторое целостное единство. Определение 3: Система с математической точки зрения – это некоторая часть мира, которую в любое данное время можно описать, приписав конкретные значения некоторому множеству переменных. Определение 4: Системой является произвольная вещь, на которой реализуются какие-то свойства, находящиеся в произвольно взятом определенном отношении. Определение 5: система (system) - комбинация взаимодействующих элементов, организованных для достижения одной̆ или нескольких поставленных целей. Примечания: 1. Система может рассматриваться как продукт или как совокупность услуг, которые она обеспечивает. 2. На практике интерпретация данного термина зачастую уточняется с помощью ассоциативного существительного, например, система самолета. В некоторых случаях слово «система» может заменяться контекстным синонимом, например, самолет, хотя это может впоследствии затруднять восприятие системных принципов.
Исходя из указанных определений можно определить понятие элемент системы (system element) - представитель совокупности элементов, образующих систему. Примечание — Элемент системы является отдельной частью системы, которая может быть создана для выполнения заданных требований. Систе́ма — Система с математической точки зрения – это некоторая часть мира, которую в любое данное время можно описать, приписав конкретные значения некоторому множеству переменных. С целью всестороннего исследования сложных изделий определим понятие объекта-системы (object) как категорию, обозначающую явление или процесс, на которые направлена предметно-практическая и познавательная деятельность субъекта (наблюдателя). При этом в качестве объекта может выступать и сам субъект[8, 16, 17]. Для дальнейшего понимания необходимо определить смысл понятия информационного моделирования, который позволит определить классификацию информационных моделей. Методы обработки информационных моделей и способы взаимодействия с информационными моделями. В рамках настоящей концепции вводятся понятия, концепты и их определения. Обосновывается введение указанных понятий и концептов, которые послужат основой для формирования терминологической базы и последующего её развития. Для формирования комплексного представления определим иерархию и взаимосвязь физического объекта, информационных моделей и других видов моделей. Физический объект – это все виды объектов, а именно антропогенные и природные объекты, включая объекты капитального строительства производственного и непроизводственного назначения, линейных объектов, объектов добывающей промышленности и т.д. Для целей формирования комплексного представления информационного моделирования представим структуру информационной модели и ее взаимосвязь с Информационная модель – общий инструмент информационного взаимодействия.
В рамках формируемого комплекса стандартов предполагается обеспечить интеграцию различных типов информационных моделей, чтобы обеспечить возможность гибкого информационного взаимодействия участников деятельности в рамках цифровой экономики. В частности предполагается обеспечить интеграцию геоинформационных моделей[2, 14], информационные модели машиностроительных изделий[9], математических моделей[12, 13, 15], компьютерных моделей и информационных моделей в соответствии с определением buildingSMART[19, 21, 22]. Концепция определения информационной модели объекта и его характеристик в рамках настоящего стандарта можно представить в виде схемы (рисунок 7.1.) Информационная модель может включать: определение объекта, информационные наборы, графические представления, соответствующие информационным наборам, алгоритмы и математические модели, правила трансформации.
Модель данных описания объекта определяется в рамках настоящего комплекса стандартов в двух группах стандартов: Требования информационного моделирования объектов и требования информационного моделирования территорий. Определение объекта краткое описание объекта, включающее уникальный идентификационный номер в соответствии с ГОСТ Р ИСО/МЭК 9834-8-2011 Информационная технология. Взаимосвязь открытых систем. Процедуры работы уполномоченных по регистрации ВОС. Часть 8. Создание, регистрация универсально уникальных идентификаторов (УУИд) и их использование в качестве компонентов идентификатора объекта АСН.1. Информационные наборы являются уникальным описанием объекта с учетом точки зрения и предметной области и формируют способ представления объекта в соответствии с предметной областью. Информационный набор должен предоставлять возможность однозначной трансформации в представление информации другого информационного набора для обеспечения возможности междисциплинарного анализа.
Для упрощения понимания иерархии и взаимосвязи различных типов моделей приведем рисунок:
Статические и динамические информационным модели
Статические информационные модели
К этому типу моделей относятся модели, которые содержат не параметризованную историческую или прогнозируемую информацию. К этому типу моделей относятся геоинформационные модели, например, модель рельефа, или информационная модель объекта капитального строительства, которая прошла государственную экспертизу. В частности, к этому типу моделей относятся: векторная модель - содержащая информацию о точках, линиях и полигонах закодированных и хранящихся в виде набора координат X,Y (в современных ГИС часто добавляется третья пространственная и четвертая, например, временная координата). Векторная модель особенно удобна для описания дискретных объектов и меньше подходит для описания непрерывно меняющихся свойств (например, плотность населения). Растровые модель - описывает непрерывные объекты и явления. Растровое изображение представляет собой набор значений для отдельных элементарных составляющих (ячеек), оно подобно отсканированной карте или картинке.
Динамические информационные модели
К этому типу информационных моделей относятся модели, которые содержат параметрические данные, компьютерные модели, вычисляющие новые характеристики или параметры объекта на основе поступающих данных.
Интеграция BIM–CFD и ее приложения представляют собой активную исследовательскую тему для будущего развития отраслей AEC, особенно в области эффективной энергетической среды. Растущее число исследований показало, что консолидация BIM–CFD имеет многообещающие перспективы во многих приложениях. Приложения интеграции BIM–CFD можно рассматривать в четырех направлениях:
- архитектурное проектирование и управление зданиями,
- энергетика,
- проектирование систем ОВ и ВК
- управление безопасностью объектов.
Последствия и потенциальные тенденции интегрированного применения BIM–CFD в каждой области были определены в результате всестороннего исследования практики архитектурного проектирования и текущего состояния такой консолидации, а также был установлен общий поток текущих процессов проектирования зданий[11].
Одновременно с этим традиционному архитектурному дизайну как раз не хватает упомянутых областей, не хватает гибкости при запросе новой концепции или параметров повторного проектирования без интегрированной концепции проектирования BIM-CFD, а также интерактивных и кооперативных возможностей на ранних стадиях концептуального проектирования. Преимущества использования интегрированного анализа BIM–CFD заключаются в двух аспектах.
- Во-первых, это особенно полезно при моделировании сложных и амбициозных зданий, поскольку реалистичные и точные входные данные легко доступны для моделирования CFD.
- Во вторую очередь, результаты анализа CFD с точки зрения качества воздуха, энергопотребления, тепловых и вентиляционных характеристик и т.д. Могут еще больше обогатить BIM, предоставляя информационную поддержку широкому кругу решений. Тем не менее, текущие усилия по интеграции BIM и CFD в основном сосредоточены на стадии проектирования, с целью достижения более устойчивой и комфортной застроенной среды.
Способы хранения и управления информационными моделями
Информационные модели подразделяются по времени хранения и использования в рамках единого информационного пространства и электронного архива: на информационные модели, предназначенные для оперативного взаимодействия (краткосрочного хранения) и информационные модели долгосрочного хранения, предназначенные для длительного (более 10 лет) хранения информации об объектах. Ниже перечислены типы информационных моделей классированные по времени и способу использования: • Координационные информационные модели • Информационные модели краткосрочного хранения • Информационные модели долгосрочного хранения • Информационные модели повторного применения • Информационные модели для цифровых двойников
В части информационных моделей для цифровых двойников понимаются информационные модели, которые могут быть доведены до полноценных информационных двойников в соответствии с концепциями Боровкова А.И.[1, 10]
5.4.5.1. Информационные модели и временные ряды данных 5.4.5.2. Математические модели Аналитические модели (символьные информационные модели) Численные модели (см. гост компьютерное моделирование) Способы представления математических моделей и результатов моделирования в составе информационной модели. 5.4.5.3. Имитационные модели 5.4.5.4. Процессные модели 5.4.5.5. Машиностроительные информационные модели 5.4.5.6. Строительные информационные модели 5.4.5.7. Информационные модели электроники 5.4.5.8. Другие виды моделей
Юридическая значимость информационной модели
Переход экономики на цифровые «рельсы» формирует новые требования к применению современных технологий. Внедрение технологий информационного моделирования создает основу для развития цифровых технологий в области инжиниринга, в первую очередь в строительной отрасли, поскольку в области машиностроения этот процесс развивается значительно быстрое. Влияние развития технологий информационного моделирования на развитие строительной отрасли является одним значимым компонентом цифровой экономики, поскольку строительная отрасль является одним из локомотивов развития национальной в частности и мировой экономики в целом. Однако для раскрытия всех потенциальных возможностей, которые позволяет реализовать технология необходимо пересмотреть существующие процессы и отношение к юридической составляющей информационной модели. В настоящее время информационное моделирование рассматривается исключительно как новый инструмент по подготовке проектной документации, что формирует требования к работе с информационной моделью как с документами и юридические требования и правила работы применяются в соответствии с существующими правилами и требованиями по работе с классической документацией. Однако полноценное внедрение и полный переход на применение технологий информационного моделирования требует разрешения нескольких вопросов: • Формирование условий юридической значимости информационной модели (сводной) и ее производных (частей) как самостоятельных объектов права; • Обеспечение оборота цифровых объектов интеллектуальной собственности в строительной отрасли и в инжиниринге в целом; • Формирование правил использования информационной модели как документа на переходный период, пока не будут разработаны новые правила обращения информационных моделей как юридически значимых объектов.
Прежде чем рассмотреть вопрос юридической значимости информационной модели, необходимо рассмотреть вопросы интеллектуальных прав. Данный вопрос активно рассматривается в зарубежной литературе [4, 18, 23, 28]. Одним из решений данного вопросы в области строительных проектов является разработка так называемого «BIM-протокола»[5], который по сути является приложением к контракту, определяющий вопросы обмена информацией и содержащий[7]: • Цели и задачи совместного использования информации; • Тип информации, подлежащей обмену; • Качество информации, подлежащей обмену, в частности, ее подлинность, актуальность, полноту и непротиворечивость; • Требования в отношении: • защиты информации, где это уместно; • разрешенные и запрещенные права на использование информации; • обязательства, уведомлять владельца информации в случае любого потенциального или известного нарушения безопасности данных; • Основные требования к информационной безопасности; • Механизмы хранения и / или очистки совместно используемой информации; • Процедуры мониторинга реализации соглашения об обмене информацией
В соответствии с ежегодным исследованием Arcadis Contract Solutions Group [3, 27] споры, возникающие в строительных проектах, можно классифицировать по следующим пяти ключевым направлениям: продолжительность споров, средняя стоимость, общие причины, наиболее популярные методы разрешения и региональные нюансы. В их последнем отчете[27] выявленные причины споров в основном связаны с поведением человека, а не с техническими вопросами. "Многие участники проекта знают, что им нужно сделать, чтобы разрешить спор, но не делают этого и попадают в те же ловушки”. В докладе упоминается, что в 2018 году средняя глобальная стоимость споров составила 33 миллиона долларов США, а средняя глобальная продолжительность споров составила 17 месяцев. Основной причиной строительных споров оставалось плохое управление контрактом, за которым следовали: плохо составленные или неполные и необоснованные претензии, плохое понимание работодателем/ подрядчиком/ субподрядчиком своих договорных обязательств, ошибки и/или упущения в контрактном документе и неполная проектная информация или требования работодателя (для проектирования-строительства и проектирования-строительства). По мере усложнения строительства в связи с внедрением новых технологий увеличивается количество споров. Внедрение технологий информационного моделирования меняет методологию разрабатки и использования инженерных документов/чертежи и данных, формирования временных и бюджетные оценок и методологию выполнения работ на площадке. В связи со всеми этими изменениями меняется и анализ претензий и споров. Правовые последствия внедрения технологии информационного моделирования можно рассматривать по трем направлениям: • Профессиональное/контрактное измерение, то есть правовой статус информационной модели на различных этапах жизненного цикла объекта. Можно рассматривать следующие правовые статусы информационной модели: обязательный, информационный, справочный и для повторного использования; • Техническое измерение, т.е. контроль версий программного обеспечения, преобразование 2D - 3D - 4D; интероперабельность; архивирование и сохранение данных; потеря данных, авторское право и интеллектуальная собственность; • Владение интеллектуальными правами на результат деятельности с применением технологий информационного моделирования.
5.5.3. Использование информационной модели как документа 5.5.4. Использование информационной модели как юридически значимого объекта 5.5.5. Применение информационного моделирования с данными ограниченного доступа к информации (коммерческая тайна (далее КТ, для служебного пользования (далее –ДСП), государственная тайна (далее - Гостайна)
Управление конфигурациями и изменениями при применении ТИМ
5.5 Взаимосвязь информационных моделей и нормативно-технических документов При формировании цифровых двойников используется понятие матрицы ограничений, которая позволяет определить весь перечень требований к будущему объекту и на основе которой производится формирование будущего объекта. Для дальнейшего развития информационного моделирования будем подразделять все ограничения на два типа: Бизнес-требования и Нормативно-технические требования. Последний вид требований включает необходимость формирования машиночитаемых нормативно-технических документов.
5.6 Совместная работа в рамках информационного моделирования Важным аспектом при организации совместной работы различных специалистов, а также автоматизированных систем является понятие интероперабельности, которое включает в себя два или более обменивающихся информацией сущностей. Сущностями могут быть устройства, машины, люди, модули программного обеспечения, системы, приложения или предприятия в соответствии с ГОСТ ПНСТ . В рамках информационного обмена, в контексте настоящей концепции, рассматривается передача или совместное использование информации, моделей, сведений или документов. Соответственно интерфейсы взаимодействующих сущностей определяют правила и механизмы передачи или совместного использования информации, моделей, сведений или документов. Соответственно ЕСИМ ставит своей целью формирование концепции единого информационного пространства для междисциплинарного анализа и последующего принятия решений.
Типы и виды информации
5.6.2 Формы хранения информационных моделей Технология информационного моделирования предопределяет в рамках открытого похода только единую модель данных и несколько вариантов представления модели данных в виде файлов: IFC, IFCXML, HDF5 и др. Однако одновременно с этим нет ограничений по использованию программных интерфейсов и применение JSON и REST. Исходя из этого считаем целесообразным не ограничивать в рамках комплекса стандартов каким-то одним способом представления и хранения информационных моделей. В связи с этим настоящий комплекс стандартов определяет в рамках
5.6.3 Управление изменениями и работа с замечаниями
5.6.4 Координация производственных процессов
5.6.5 Создание и использование единого информационного пространства Все составляющие корпоративных знаний, применяемые в управлении и прежде всего в рамках электронного регламента административной и служебной деятельности, должны поддерживаться как единое логическое целое. При этом информационные ресурсы, касающиеся принятых схем построения и реализации деятельности организации, а также информация, получаемая в ходе реализации этих схем, должны быть взаимно согласованы, а информационная среда электронного регламента административной и служебной деятельности должна быть составной частью общей информационной корпоративной среды и удовлетворять следующим общим требованиям:
- обеспечивать логическое единство базы знаний и данных для всей организации, независимо от ее территориальной распределенности;
- поддерживать целостную систему данных, записей и документов, относящихся ко всем уровням управления организации, и поддерживать сквозную навигацию по связанным объектам представления корпоративных знаний как по единому логически связанному информационному пространству;
- обеспечивать необходимый для организации уровень защиты информации, в том числе контроль целостности, аутентичность и конфиденциальность данных, записей и документов с использованием при необходимости современных методов и средств криптографии, контроль доступа и разграничение прав и полномочий пользователей;
- обеспечивать связность описаний, событий, документов и данных на всех уровнях управления, осуществлять их верификацию и локализацию противоречий и рассогласований, а также давать полную информацию о возникающих рассогласованиях с возможно точной локализацией их источников;
- обеспечивать возможность непосредственного участия в проектировании деятельности всех ключевых работников организации независимо от их территориального расположения;
- поддерживать постоянную актуализацию всех информационных ресурсов и своевременное информирование всех заинтересованных лиц о происходящих изменениях;
- минимизировать затраты на управление и содержание информационной среды, применяя, по возможности, однотипные технологии, программные и технические средства на рабочих местах персонала.
Поскольку организации при осуществлении своей деятельности, как правило, необходимо постоянно изменяться с учетом требований рынка, развития нормативно-правовой базы, перемен во взаимодействии с окружающей средой, возникновения новых технологий и т. п., то соответствующий уровень информационной среды электронного регламента административной и служебной деятельности должен быть постоянно адекватным обновленной модели деятельности организации. Такое положение является нормой эффективной работы организации. При этом к поддерживаемым административными средствами оперативным штатным изменениям могут относиться изменения:
- целей организации и подразделений;
- функций подразделений, организационной и кадровой структуры;
- нормативной и методической базы, правил организации и исполнения рабочих процессов;
- типов данных, видов и форм получаемой первичной информации и форматов ее консолидированного представления различным лицам из состава персонала управления;
- другие составляющие регламента административной и служебной деятельности, реализуемые в электронном виде.
Особенности применения
Все информационные объекты и отношения между ними, используемые в информационной среде электронного регламента и введенные до внесения в них изменений, должны поддерживаться в полном объеме, применяться в новых способах обработки и сохраняться в первоначальном виде.
При наличии в организации других действующих информационных систем должно быть обеспечено получение информации из этих систем, "настройка" и поддержание персональных отчетов с заранее определенными параметрами или параметрами, устанавливаемыми на момент формирования отчетов, при условии интеграции данных из разных систем. Такая интеграция реализуется через применение специальных средств обработки данных, позволяющих:
- осуществлять отбор данных по задаваемым пользователям критериям по всем информационным ресурсам, относящимся к выделенным выше уровням управления;
- сигнализировать ответственным лицам о выходе самих данных или их прогнозируемых величин за допустимые пределы;
- поддерживать сравнение (прямое или косвенное) или взаимопроверку данных, поступивших из различных источников (в том числе из различных действующих информационных систем) и представленных в различных отчетных формах;
- определять эффективность действующих процессов;
- обеспечивать функции мониторинга и упреждающего выявления негативных тенденций;
- осуществлять извлечение скрытой информации из накопленных данных, помогающей выявлять "узкие места" при выполнении рабочих процессов, и решать задачи параметрической и структурной оптимизации деятельности организации в соответствии с заданными критериями.
5.8.6.1. Определение ответственных за формирование и управление контентом, создаваемом в рамках процессов информационного моделирования 5.8.6.2. Иерархия информационных пространств 5.8.6.2. Взаимодействие и синхронизация единых информационных пространств 5.8.7. Использование единых информационных пространств в рамках документо-ориентированного подхода 5.8.7.1. Учет изменений проектной документации 5.8.7.2. Взаимосвязь информационных моделей и проектной документации 5.8.7.3. Согласование информационных моделей и проектной документации
Информация и знания
Управление знаниями - это процесс, в ходе которого мы сознательно создаём, структурируем и используем базу знаний организации, являющейся интеллектуальным авуаром успеха.
Знания отличают от информации следующие свойства:
Структурированность
Знания должны быть «разложены по полочкам». Для печатных знаний (книг, журналов, равно как и для компьютерных хранилищ) это означает удобную архитектуру и прозрачность хранилища знаний, т.е. наличие ясных названий и заголовков, удобного представления структуры (оглавлений, рубрикаторов).
Удобство доступа и усвоения
Для человека - это способность быстро понять и запомнить или, наоборот, вспомнить. Для компьютерных знаний - средства доступа, т.е. поиск, краткие аннотации к документам, индексы и прочее.
Лаконичность
Лаконичность позволяет быстро осваивать и перерабатывать знания и повышает «коэффициент полезного содержания». В данный список лаконичность была добавлена из-за проблемы информационного шума и «мусорных» документов, характерной именно для компьютерной информации, Интернет и электронного документооборота.
Непротиворечивость
Знания не должны противоречить друг другу, что очевидно или, по крайней мере, желательно. Однако на вход хранилища знаний может поступать противоречивая информация. На этапе сбора знаний необходимо обнаружить противоречия и разрешить их, либо же присвоить информации характеристику достоверности.
Оценка достоверности
Безусловно, сохраняя или используя знания, желательно иметь представление об их достоверности. Хорошее хранилище знаний (учебник или база данных) для своих элементов должно иметь такую оценку, в частности описывать диапазон их применимости.
Процедуры обработки
Знания нужны для того, чтобы их использовать: получать новые знания, передавать их другим, преобразовывать в иную форму, решать задачи и прочее. Для этого должны существовать не только процедуры обработки знаний, но и данные, структурированные для такой обработки, т. е. информация должна приводиться к формату знаний.
Проверка качества информационной модели
Проверка качества информационной модели основа на базовых принципах информационного моделерования - объектного подхода
Стандарт ИСО 9000:2000 определяет эти термины следующим образом:
«Верификация — подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены».
«Валидация — подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены».
верификация — проводится практически всегда, выполняется методом проверки (сличения) характеристик продукции с заданными требованиями, результатом является вывод о соответствии (или несоответствии) продукции; валидация — проводится при необходимости, выполняется методом анализа заданных условий применения и оценки соответствия характеристик продукции этим требованиям, результатом является вывод о возможности применения продукции для конкретных условий.
Классификация и идентификация в информационном моделировании
Для обеспечения структурирования информации и данных в рамках информационного моделирования применяются методы и системы классификации. При этом системы классификации широко применяются для облегчения обработки и интерпретации объектов посредством надлежащего упорядочения знаний в рассматриваемой области и предоставления на этой основе соответствующей структурированной информации, необходимой для непротиворечивой характеристики рассматриваемых объектов. Классификационные системы проектируются таким образом, чтобы избегать создания структур, которые не смогут предоставлять запрашиваемую информацию или будут чрезмерно сложны для понимания пользователями. Разработка надежной классификационной иерархии упрощается, если она отражает хорошо проработанную систему понятий, опирающуюся на общепризнанные принципы управления терминологией. При таком отображении понятия, образующие понятийную систему, становятся классами в системе классификации. Зачастую классификация производится по группам на основе принципа подобия, когда схожие элементы объединяются в одну группу. Однако сходство элементов может проявляться в самых разных аспектах, и в процессе классификации предметы должны объединяться в функциональном или прагматическом плане с учетом конкретной цели этого процесса. Объекты, подлежащие классификации, могут представлять собой предметы, людей, идеи, услуги и т.п. Ключевым требованием к системам классификации является обеспечение их согласованности. Классы должны четко отделяться друг от друга, а области их применимости не должны пересекаться. В тех случаях, когда предусматривается использование применительно к системе классификации какого-либо процесса обработки информации, особенно актуально требование четкого структурирования и отсутствия неопределенности. Используемые определения должны однозначно идентифицировать конкретные понятия, которые лежат в основе образования различных классов. В области информационного моделирования одновременно с классификацией могут активно использоваться управление требованиями, идентификация элементов, маркировка объектов, систем, которые предполагают дополнительные уровни структурирования информации для целей определенных областей применения. Согласованная терминология, на ровне с классификацией, идентификацией и т.д. создает надежную основу для точно выраженного информационного обмена как между пользователями, так и между прикладными программами. Одновременно с построением согласованной терминологической базы информационное моделирование требует формализации в описании процессов деятельности, что приводит к необходимости построения дополнительно классификации процессов деятельности в области информационного моделирования для разных этапов жизненного цикла как объекта-системы. Это приводит нас к необходимости построения комплексного описания предметной области с использованием формальных инструментов, которым в настоящее время является построение онтологии предметной области. Для обеспечения всеобъемлющей и подробной формализации области знаний используются концептуальной схемы, которые состоят из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Одним из важных правил создания классов и формулирования определений должны быть задокументированы и сделаны доступными для пользователей и для поставщиков контента. Должны быть четко задокументированы критерии или правила создания новых уровней иерархической структуры и новых классов. В случае построения онтологий документированию должны быть подвергнуты связи и правила. Необходимо учитывать, что разрабатываемые системы классификации, идентификации и онтологии должны обладать свойством расширяемости, что означает способность к восприятию новых классов и их правильному размещению в иерархической или сетевой структуре. Классы должны создаваться на том уровне или в той позиции иерархии, которая надлежащим образом отражает их отношения с уже существующими классами. Системы классификации должны обладать свойством расширяемости в том смысле, что они должны быть способны реагировать на новые требования или учитывать перспективы развития в рамках рассматриваемой сферы применения. В качестве инструмента управления предметными областями различных отраслей предлагается рассмотреть возможность введения базовых укрупненных классификаторов по отраслям, как неотъемлемая часть информационной модели. Учитывая необходимость гармонизации с международным сообществом при построении системы классификации, идентификации и онтологий в области информационного моделирования крайне необходимо использовать интернациональный подход, который позволит выстроить многоязыковую среду взаимодействия. В частности, несмотря на использование английского языка в качестве лингва-франка в области информационного моделирования, локализация на языки, отличные от английского, признается желательной поскольку это формирует комфортную информационную среду для реализации информационного взаимодействия. К ситуациям, в которых должен существовать локализованный контент, относятся: • информационный обмен; • эксплуатация оборудования; • обязательные требования; • требуемая локальная информация в рамках промышленных проектов.
5.9.1. Базовые укрупненные классификаторы по отраслям 5.9.2. Рекомендации и методика применения классификаторов к элементам модели 5.9.3. Рекомендации и методика по расширению классификаторов на следующий уровень
Типовые сценарии применения ЕСИМ
6.1 Определение сценария применения технологии информационного моделирования
6.2 Назначение сценариев
6.3 Типовые прикладные сценарии по отраслям
6.4 Принципы реализации сценариев
6.5 Указания по адаптации сценариев
6.6 Контроль выполнения сценариев
Жизненный цикл
В условиях возрастающих неопределенностей развития конкретных применений научно-технических достижений, с одной стороны и возросших требований к ресурсосбережению во всех контекстах этого понятия - с другой, основным направлением развития стратегических инициатив становится внедрение управления жизненным циклом сложных изделий (объектов) и, связанных с ними систем. Такой подход позволяет достигать баланса интересов всех сторон через достижение управляемого баланса различных, зачастую несовместимых напрямую характеристик как самих сложных систем, так и связанных с ними процессов и рисков. В масштабах государства такая постановка задачи для построения стратегии необходимо влечет переход от частных решений в отдельных областях и ограниченных временных отрезках к междисциплинарным решениям, рассматриваемым на достаточно длительных временных отрезках от создания изделия (объекта) до вывода его из эксплуатации. Вследствие протяженных в структурном и временном понимании жизненных циклов сложных систем задача может решаться путем перехода от "дискретного" управления отдельными этапами создания и применения сложных систем на основе программного, проектного и процессного подходов к методикам управления жизненным циклом на основе интегрированного подхода. Данный подход предполагает формирование информационной модели объекта, которая одновременно собирает всю информацию об изделии и является единым источником для различных потребителей. Жизненный цикл объекта-системы представляет собой совокупность этапов (фаз) развития объекта-системы, которые характеризуются определенной совокупностью признаков, процессов, регламентов, определяющих производственную деятельность Различают жизненный цикл проекта, жизненный цикл изделия, жизненный цикл системы, жизненный цикл объекта и жизненный цикл территории. Несмотря на то, что вроде бы все эти названия схожи по сути они могут значительно отличаться друг от друга в зависимости от рассматриваемого объекта. В контексте рассматриваемого комплекса стандартов можно добавить еще один - жизненный цикл информационной модели. Исходя из этого целесообразно определить единые методологические основы определения и описания понятия жизненного цикла, а также сформировать общие методологические подходы по управлению различными жизненными циклами в рамках информационного моделирования. С целью унификации подходов описания жизненных циклов введем понятие базового жизненного цикла объекта-системы, который включает 12 стадий: Идея, Концепция, Планирование, Требования, Проект, Проверка на соответствие требованиям, Реализация, Валидация и Верификация, Эксплуатация, Накопление знаний, Модернизация, Вывод из эксплуатации (см. Рисунок 8.1) Стадии могут выполняться одновременно, с наложением или последовательно. Это зависит от объекта, среды или проекта. На каждой стадии жизненного цикла осуществляется менеджмент знаний. Базовый жизненный цикл может быть однозначно сопоставлен (трансформирован) с любым жизненным циклом системы с целью унификации подходов исследования процессов на различных стадиях жизненного цикла системы. Одной из важных особенностей данного подхода является возможность сквозного накопление знаний. Базовый жизненный цикл включает контрольные этапы «Проверка на соответствие требованиям», «Верификация и Валидация» и «Ввод в эксплуатацию», на которых могут быть выполнены автоматизированные проверки на основе математических моделей.
Стадии жизненного цикла объекта или среды отражают состояния объекта и его изменения. Этапы жизненного цикла объекта или среды могут входит в состав стадий и предполагают выполнение определенного объема работ в течение ограниченного времени. Процессы жизненного цикла отражают те действия, которые должны обязательно выполняться системой для обеспечения эффективной деятельности; определяются как совокупность взаимосвязанных действий, преобразующих входные данные в выходные; одни и те же процессы могут выполняться на различных стадиях (этапах) ЖЦ. Для обеспечения связности развития информации об объекте-системе используется «закон сохранения информации», который может быть определен на базе понятия «Информационное поле», охватывающее полную информацию жизненного цикла объекта. Информационное поле включает граничные условия для анализа информационной модели объекта. Схема информационного поля представлена на рисунке 8.2.
Информационное пространство должно являться подмножеством информационного поля. С целью описания всех характеристик жизненного цикла введем понятие процессов жизненного цикла. Процессы жизненного цикла реализуются под управлением ряда заинтересованных сторон, вовлеченных в выполнение соответствующих этапов процессов жизненного цикла. Под заинтересованными сторонами понимают организации и лица, которые инициируют создание, выполняют проектирование и разработку, осуществляют эксплуатацию и сопровождение электронного регламента. Заинтересованными сторонами, таким образом, являются: заказчик, поставщик, разработчик, пользователи, эксплуатирующий персонал и персонал сопровождения. Каждая организация самостоятельно определяет состав и содержание процессов жизненного цикла в рамках информационного моделирования.
7.2. Методология управления жизненными циклами 7.3. Концепция универсального жизненного цикла
Процессы информационного моделирования
Взаимосвязь процессов информационного моделирования и процессных моделей
При описании процессов информационного моделирования следует различать два вида моделей: • модели описания процессов информационного моделирования • процессные модели. Под моделями описания процессов информационного моделирования понимаются модели описания бизнес-процессов в одной из доступных нотаций (предпочтительно BPMN). В свою очередь процессные модели подразумевает возможность проведения расчетов процессов и их метрик, а также возможность непрерывного мониторинга выполнения реализации информационного моделирования
Процессы информационного моделирования для разных этапов жизненного цикла
8.2.1 Процессы информационного моделирования территории
8.2.2 Процессы информационного моделирования подземного пространства В данном разделе предполагается описать общие подходы к моделированию информационных моделей гидрологии, геологии и других видов моделей, которые составляю целостное представление о подземном пространстве.
8.2.3 Процессы информационного моделирования исходных данных или технических условий
8.2.4 Процессы информационного моделирования антропогенного объекта
8.2.5 Информационное моделирование процессов этапа градостроительного проектирования В рамках этапа градостроительного проектирования предполагается рассматривать процессы информационного моделирования, отвечающие за формирование функциональных градостроительных зон, проведение комплексного экологического моделирования территории и т.д. 8.2.6. Информационное моделирование процессов этапа проектирования 8.2.7. Информационное моделирование процессов этапа строительства Информационная модель строительного производства Информационная модель консервации Информационная модель пуско-наладочных работ 8.2.8. Информационное моделирование процессов ввода в эксплуатацию 8.2.9. Информационное моделирование процессов этапа эксплуатации 8.2.10. Информационное моделирование процессов этапа вывода из эксплуатации 8.2.11. Информационное моделирование процессов этапа сноса и утилизации
Пространственно-временные модели
8.3.1. Информационные модели технологических процессов Для моделирования технологических процессов в настоящее время активно используются технологические карты. Однако переход к цифровым технологиям предъявляет новые характеристики и требования к методологии разработки технологических карт и описания производственных процессов. В первую очередь цифровые процессы и должны позволять формировать процессные модели, которые могут собираться в цепочки, что позволяет проводить комплексный анализ последовательности операций.
8.3.2. Сценарные информационные модели
9 Порядок применения информационного моделирования
9.1. Системная инженерия
9.1.1. Таксономия строительной отрасли
9.1.2. Онтология строительной отрасли
9.1.3. Объектно-ориентированный подход
9.1.4. Модельно-ориентированный подход
9.1.5. Функциональный подход
9.2. Виды деятельности в рамках информационного моделирования
9.2.1 Общее описание видов деятельности, применяющих информационное моделирование
9.2.1 Взаимосвязь видов деятельности, специальностей и функциональных ролей информационного моделирования
9.3. Классификация и идентификация информационных моделей
Библиография
- 1. ГОНЧАРОВ А. С., САКЛАКОВ В. М. Цифровой двойник: обзор существующих ре-шений и перспективы развития технологии Кемерово: Издательство: Кузбасский государственный технический университет имени Т.Ф. Горбачева, 11-13.10.2018.C. 24–26.
- 2. Цветков В. Я. Информационные модели и геоинформационные модели // Обра-зовательные ресурсы и технологии. 2016. № 4 (16).
- 3. Bodea C.-N. Legal implications of adopting Building Information Modeling (BIM) C. 10.
- 4. Currie L. BUILDING INFORMATION MODELLING: ITS IMPACT ON INSURANCE, INTELLECTUAL PROPERTY RIGHTS AND DESIGN LIABILITY. 2014.
- 5. Guerin L. [и др.]. BIM LEGAL & PROCUREMENT.
- 6. Moscow Engineering Physics Institute [и др.]. AN APPROACH TO THE DEVELOPMENT OF ONTOLOGY FOR ELECTRIC-POWER ENGINEERING DOMAIN BASED ON STANDARDS ISO 15926, IEC 61970 // Автоматизация процессов управления. 2019. № 2 (56). C. 59–68.
- 7. bim-protocol-2nd-edition-2.pdf.
- 8. 14:00-17:00 ISO 1087:2019 Terminology work and terminology science—Vocabulary // 2019.
- 9. Бетелин В. Б. Информационные модели и информационные технологии в маши-ностроении // Международный журнал «Программные продукты и системы». 1990. № № 4.
- 10. Боровков А. И. [и др.]. ЦИФРОВЫЕ ДВОЙНИКИ И ЦИФРОВАЯ ТРАНСФОРМА-ЦИЯ ПРЕДПРИЯТИЙ ОПК // Сборник материалов «Оборонная техника». 2018. № №1.
- 11. Кононюк А. Е. Информациология. Общая теория информации. Книга 1 / А. Е. Ко-нонюк, Киев: Освіта України, 2011. 476 c.
- 12. Мочалин С. М. Математическая модель описания транспортного процесса в средних системах доставки грузов // Вестник ОГУ. 2004. № №2.
- 13. Пижурин А. А., Муращенко Д. Д. Оптимизационная математическая модель за-дачи оперативного планирования и управления лесопильно-деревообрабатывающим производством в условиях рыночной экономики // Вестник МГУЛ – Лесной вестник. 1998. № №3.
- 14. Розенберг И. Н. Геоинформационное моделирование как фундаментальный метод познания // Перспективы науки и образования. 2016. № 3 (21).
- 15. Российской У., I B. Y. Математическая модель межкультурного взаимодействия 1 № 499.
- 16. Уемов А. И. Системный подход и общая теория систем. / А. И. Уемов, Москва: ИЗДАТЕЛЬСТВО «МЫСЛЬ», 1978.
- 17. Урманцев Ю. А. Общая теория систем: Состояние, приложения и перспективы развития / Ю. А. Урманцев, 1968. 63 c.
- 18. AUGI Liability and Intellectual Property with BIM / AUGI,.
- 19. Australasia buildingSMART National Building Information Modelling Initiative // Strategy. 2012. № June (1). C. 64.
- 20. Batres R. [и др.]. An upper ontology based on ISO 15926 // Computer Aided Chemical Engineering. 2005. № C (20). C. 1543–1548.
- 21. British Standard Institution (BSI), No I. C. PAS 1192-3:2014—Specification for information management for the operational phase of assets using building information modelling // British Standards Institution (BSI). 2014. № 1. C. 1–44.
- 22. Eastman, Tiecholz BIM Building Information Modelling / Eastman, Tiecholz, 2008.
- 23. Fan S.-L. Intellectual Property Rights in Building Information Modeling Application in Taiwan // Journal of Construction Engineering and Management. 2014. № 3 (140). C. 04013058.
- 24. Miller L. A. 1980—Project EPISTLE: A System for the Automatic Analysis of Business Correspondence [1980 - Project EPISTLE: A System for the Automatic Analysis of Busi-ness Correspondence] (1980 - Project EPISTLE: A System for the Automatic Analysis of Business Correspondence) C. 280–282.
- 25. Pauwels P., Terkaj W. EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology // Automation in Construction. 2016. № March (63). C. 100–133.
- 26. Schenck D., Wilson P. R. Information modeling: the EXPRESS way / D. Schenck, P. R. Wilson, New York: Oxford University Press, 1994. 388 c.
- 27. GLOBAL CONSTRUCTION DISPUTES REPORT 2019 LAYING THE FOUNDATION FOR SUCCESS. 2019.
- 28. Building Information Modelling and Intellectual Property Rights.
- ↑ Инжиниринг и инженерия – есть ли разница?
- ↑ Exner, A.; Exner, H,; Hochreiter, G.:„Unternehmens(Selbst)Steuerung - Ein praktikables Managementmodell“, in: Organisationsentwicklung – Zeitschrift für Unternehmensentwicklung und Change Management, No. 2, S. 56–65, 2010
- ↑ Becker et al. 2008, стр. 6
- ↑ Schmelzer et al., 2010, стр. 61
- ↑ Fischermann, 2006
- ↑ Громов и др. 2002
- ↑ https://upravlenie-proektami.ru/upravlenie-konfiguraciey-proekta-ili-configuration-management
- ↑ В настоящее время (2022 год) ТИМ не закончила процесс формирования и поэтому в настоящее время рекомендуется использовать термин во множественном числе - Технологии информационного моделирования.
- ↑ Громов А. И., Фляйшман А., Шмидт В. Управление бизнес-процессами: современные методы : монография. Москва: Юрайт, 2016. 368 с.
- ↑ Lehner и др. Lehner, F.; Wildner, S.; Scholz M.: Wirtschaftsinformatik – Eine Einführung, München, 2007
- ↑ Шаблон:Cite journal