Моделирование предметной области

UML. Взгляд со стороны или Как UML удерживает аналитиков в прошлом

01.07.2020 16:06:10 |

Автор: admin

Данная статья является переработанным материалом моего доклада на конференции Analyst Days 6 (2017).

Статья посвящена UML и особенностям его применения в настоящее время. Немного исторических сведений, совсем немного, только основные моменты:

UML зародился в 90-х годах как результат работы по создания языка объектно-ориентированного моделирования.
Спецификация 1.0 вышла в 1997 году.
Спецификация 2.0 вышла в 2005 году.
На сегодняшний день версия UML 2.5, развитие получили несколько профилей, такие как SysML и SoaML.

Если посмотреть, как UML применялся тогда и сейчас, и обдумать, то можно сделать следующий вывод: Пусть версия UML сейчас 2.5, но с первой версии принципы использования языка не изменились.

И как следствие: Аналитики используют концепцию описания программных систем, которая была заложена более 20 лет назад. Сама концепция хорошая, но нужно соотносить ее с местом и контекстом применения.

Если дальше продолжить этот анализ применения UML, а также соотнести его с требований текущего времени, то выводы такие:

Все методики использования UML ходят вокруг Use Case Driven Development.
Моделям на UML не хватает целостности. Выбранный подход раздельного описания аспектов структуры и поведения, уровней бизнеса и приложений усложняет восприятие моделей в целом.
UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции.

Про подход Use Case Driven Development я ничего говорить не буду, одно из воплощений его это Rational Unified Process. Далее я расскажу про последние два пункта.

Аспекты представления

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

Что делает аналитик, когда пытается увязать все диаграммы в одну модель? Он начинает строить гибридные диаграммы и таблицы связей. В результате получается не единая модель, а множество диаграмм, к которому добавились еще диаграммы и таблицы.

Уровни представления

Допустим бизнес-аналитик описал предметную область с помощью диаграмм UML. И теперь системному аналитику или тому же самому аналитику требуется сформировать модель программной системы. Если аналитик ориентирован на UML, то начнет создавать представления соответствующие сделанным ранее, но уже в рамках системы. Это будет выглядеть опять в виде аналогичных диаграмм.

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

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

В результате опять получается множество диаграмм и таблиц.

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

Сервис-ориентированная подход

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

Коротко расскажу про сервис-ориентированный подход, чтобы далее было понятно почему SoaML не подходит для его моделирования. За основу возьмем интерпретацию определений из TOGAF.

Для простой формализации сервис-ориентированном подхода нам потребуются 2 абстракции:

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

Посмотрим, как это моделируется на SoaML. Заодно сравним, как будет отличаться объектно-ориентированное моделирование на UML и сервис-ориентированное моделирование на SoaML.

Человек и Магазин

Задача простая, описать модель покупки товара в магазине.

Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий Use Case и его детализацию в виде диаграммы деятельности или диаграммы последовательности.

Человек выступает не как пользователь, а как одна из сторон взаимодействия.
Теперь решим данную задачу с помощью SoaML, строго в соответствии со спецификацией.

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

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

В рамках данного сервиса: Продавец выступает как provider, а Покупатель как consumer.
Продавец как поставщик предоставляет одну операцию продать. Бизнес-анализ закончен, переходим на уровень системы.

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

Из обновленного бизнес-процесса можно выделить одну операцию продать, оформим ее в базовый интерфейс Умеющий продавать.

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

Получаем следующие сервисные интерфейсы:

Желание продавать, который наследуется от интерфейса Умеющий продавать;
Потребность покупать, который зависит от интерфейса Умеющий продавать.

Теперь можно представить модель целевого сервиса в виде диаграммы композитной структуры.

Сравним результаты объектно-ориентированного моделирования на UML и сервис-ориентированного моделирования на SoaML.

Визуально вся разница вот в этих маленьких квадратиках на границе компонентов. Я отметил их красным цветом.Неужели это вся разницы?

Разница между объектно-ориентированным и сервис-ориентированным моделирование на самом деле есть, просто SoaML свел всё к объектам. Но об этом позже.

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

Что же не так, по моему мнению, с SoaML.

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

Во-вторых: Сервис описывается как объект структуры, это нехорошо. В русской речи распространена фраза Поставщик представляет сервис, вот это компонент-ориентированный подход, который реализован в SoaML.

Но в случае с сервис-ориентированной парадигмой правильнее говорить Поставщик оказывает сервис. А если по другому перевести Сервис на русский язык, то всё сразу встает на свои места: Поставщик оказывает услугу.

С этой точки зрения Сервис это не Объект, это Поведение.

В-третьих: На слайде о сервис-ориентированной архитектуре я рассказал о двух абстракциях: Процесс и Сервис. Рассматривать и описывать их через призму объектно-ориентированного подхода является, мягко говоря, напряженной задачей.

Парадигмы

Вернемся к UML. UML посредством своей парадигмы пытается описать другие парадигмы.

И если с компонентно-ориентированной парадигмой всё получается, она может быть представлена как логическое продолжение объектно-ориентированной. То с сервис-ориентированной получилось нехорошо.
В данном случае выражать одну парадигму через другую неудачная идея.
Использование такой концепции я продемонстрировал с SoaML на примере задачи Человек и Магазин.

Относится к парадигмам лучше как обозначено ниже.

Продемонстрирую, чем отличается сервис-ориентированное моделирование, от объектно-ориентированного.

Человек и Собака

Задача простая: Нужно построить простую модель взаимодействия, в которой Человек гуляет с Собакой. Данную задачу не задумываясь, наверное, решит любой студент технического факультета.
В школах и универах на соответствующих специальностях объектно-ориентированное программирование является обязательным.
Объектно-ориентированный подход представлен ниже.

А как будет выглядеть модель с сервис-ориентированным подходом? Не знаю, ответит ли такой вопрос студент.

Вот что я хотел бы получить. (Подумай сам, потом открой)

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

Можно вспомнить историю объектно-ориентированного программирования.
Как к нему скептически относились в начале его появления даже очень авторитетные люди, такие как Эдсгер Дейкстра и Никлаус Вирт.
И до сих пор некоторые люди считают ООП недостойным внимания.

Ну так вот, данная модель тоже может вызвать усмешки. Дело в том что сервис-ориентированная парадигма не имеет достаточной поддержки на начальном уровне программирования и проектирования.
Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring. Думаю, что программисты добираются до них с головой, уже отформатированной под объектно-ориентированный подход.
Аналитики строят свое представление о сервис-ориентированной архитектуре и проектирование по статьям в интернете, которые по-разному понимают, что это такое, а некоторые статьи без глубокого погружения в специфику и технические детали вообще малопонятны. В результате аналитики возвращаются к общепринятым Use Case между системой и пользователями. Распространено также, что архитектура системы и ее компонентный состав уже зафиксированы архитектором или обусловлены выбранной платформой. И тогда аналитики опять просто описывают Use Case между системой и пользователями.

Сравните объектно-ориентированный подход и эту, казалось бы, смешную, где Человек оказывает Собаке услугу Гулять.
Когда она перестанет быть для вас смешной, а будет смешным казаться объектно-ориентированный подход, где Человек реализует метод гулять, на вход которому подается Собака!!! Вот тогда к вам пришло понимание сервис-ориентированной парадигмы.

Еще нужно заметить, что эти парадигмы вполне совместимы. Человек по-прежнему может выполнять свойственные ему действия: спать и танцевать, а Собака лаять.

Еще один момент: В этом примере я ввел новое понятие Сервис.
При этом я пока четко не определил правила его использования, но оно отличается от того что в SoaML. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.

Вместо заключения

UML ограничивает возможности аналитика в выборе подхода к моделированию. Если загнать всё в одну парадигму или выразить предметную область несвойственным для нее подходом, то ваше представление может оказаться искажением. Поэтому выбирайте подходящие языки моделирования.
Не отрывайтесь далеко от разработчиков в знании современных технологий и направлений их развития. Лучше иметь знания глубже, чем просто в общих чертах. Иначе вы не сможете построить модели соответствующие новым подходам в информационных технологиях.
Проблемы подобные имеющимся в UML можно найти в любом языке моделирования. Любая парадигма, любая модель ущербна относительно реального мира. Учитесь мыслить с различными подходами, в отличии от UML, человек способен это делать.

Подробнее..

Категории: Анализ и проектирование систем , Uml , Моделирование предметной области

3. Частотные характеристики систем автоматического управления. ч. 3.3 Апериодическое звено 1го порядка

25.01.2021 00:11:48 |

Автор: admin

3.3. Апериодическое звено 1го порядка (инерционное звено)

Вывод свойств(характеристик) апериодического звена сделаем на примере фрагмента (части) ядерного реактора, а именно входной камеры смешения.

Рисунок 3.3.1 Расчетная схема камеры смешения

Сделаем следующие допущения:

расход теплоносителя постоянен: G = const;
теплоемкость теплоносителя = const;
входящий в камеру смешения теплоноситель полностью перемешивается в камере смешения, т.е. температура жидкости, поступающей в каждый тепловыделяющий канал, одинакова;
теплообмен камеры смешения с окружающей средой пренебрежимо мал.

Уравнение теплового баланса:

$\rho \cdot C_p \cdot V \cdot \frac{dT(t)}{dt} = G \cdot C_p \cdot \left[T_{ВХ}(t) -T_{ВХ}(t) \right] \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.1)}$

где: $\rho$ - плотность теплоносителя, кг/м^3
C_p удельная теплоемкость, $Дж/(кг \cdot K)$
объем камеры смешения, м^3 ;
расход теплоносителя, кг/с ;
$T_{ВХ}(t), T_{ВХ}(t)$ температура теплоносителя на входе и выходе, соответственно;
T(t) температура (перемешанного) теплоносителя в камере смешения $T(t) T_{ВХ}(t)$ .

Условие стационара когда левая часть уравнения равна нулю:

$\frac{dT(t)}{dt} =0 \Rightarrow T_{ВХ}=T_{ВХ} =T_0 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.2)}$

Введем новые переменные:

$\tilde{T}_{ВХ} = \frac{T_{ВХ}(t)-{T}_{ВХ}(0)}{{T}_{ВХ}(0)}=\frac{T_{ВХ}(t)-T_0}{T_0}; \Rightarrow T_{ВХ}(t)= T_0 \left[1+ \tilde{T}_{ВХ}\right];\\ \tilde{T}=\tilde{T}_{ВХ} = \frac{T_{ВХ}(t)-{T}_{0}}{{T}_{0}}; \Rightarrow T_{ВХ}(t)= T_0 \left[1+ \tilde{T}_{ВХ}\right]=T(t);$

Подставляя эти соотношения в (3.3.1), получаем:

$\rho \cdot C_p \cdot V \cdot T_0 \cdot \frac{d\tilde{T} }{dt} = G \cdot C_P \left[ T_0+T_0 \cdot \tilde{T}_{ВХ}(t) - T_0 - T_0 \cdot \tilde{T}(t)\right] = \\ =G \cdot C_P \cdot T_0 \left[ \tilde{T}_{ВХ} - \tilde{T}(t)\right];$

Сокращая на T_0 и C_p , получаем:

$\rho \cdot V \cdot \frac{d\tilde{T} }{dt} = G \cdot \left[ \tilde{T}_{ВХ}(t) - \tilde{T}(t)\right] \Rightarrow \\ \frac{\rho \cdot V}{G} \cdot \frac{d\tilde{T} }{dt}+ \tilde{T}(t) = \tilde{T}_{ВХ}(t)$

Введем новую переменную $\tau$ - постоянная времени:

$\tau = \frac{\rho \cdot V}{G}$ $\tau \cdot \frac{d\tilde{T}(t)}{dt} +\tilde{T}(t) = \tilde{T}_{ВХ}(t) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.3)}$

Таким образом получили линейное дифференциальное уравнение, причем переменные ${T}_{ВХ}(t)$ и $\tilde{T}(t)$ - нормализованные, что обеспечивает равенство их нулю при t 0

$\tau$ постоянная времени;
$\frac{d\tilde{T}(t)}{dt}$ аналог y(t);
$\tilde{T}(t)$ аналог y(t);
$\tilde{T}_{ВХ}(t)$ аналог x(t);

Уравнение (3.3.3) соответствует типовому апериодическому звену 1-го порядка, в котором коэффициент K = 1. В общем случае уравнение динамики апериодического звена 1-го порядка имеет вид:

$T \cdot y'(t)+y(t) = K \cdot x(t) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.4)}$

Если начальные условия нулевые, томожно перевести в изображения:

$y(t) \rightarrow Y(s) \\ y'(t) \rightarrow s \cdot Y(s) \\ x(t) \rightarrow X(s)$

Уравнение динамики в изображениях:

$[ T \cdot s +1 ] \cdot Y(s) = K \cdot X(s) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.5)}$

Уравнение динамики в изображениях:

$W(s) = \frac{Y(s)}{X(s)} = \frac{K}{T \cdot s+1}\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.6)}$

Найдем выражение для АФЧХ:

$s = i \cdot \omega \Rightarrow W(i \cdot \omega) = W(s)\mid_{s = i \cdot w} = \frac{K}{T \cdot i \cdot \omega+1} \ \ \ \ \ \ \mathbf{(3.3.7)}$

Умножим на комплексно сопряженное значение $(1 - i \cdot T \cdot \omega)$ :

$W(i \cdot \omega) =\frac{K \cdot(1- i\cdot T \cdot \omega)} {(1+ i \cdot T \cdot \omega)(1 - i \cdot T \cdot \omega)} = \underbrace {\frac{K}{1+T^2 \cdot \omega^2}}_{Re =u(\omega)} - i \cdot \underbrace {\frac{K\cdot T \cdot \omega}{1+T^2 \cdot \omega^2}}_{Im =v(\omega)}\Rightarrow$ $u(\omega) = \frac{K}{1+T^2 \cdot \omega ^2} \ \ \ \ \ \mathbf{(3.3.8.a)}\\ v(\omega)= -\frac{K \cdot T \cdot \omega}{1+ T^2 \cdot \omega^2}\ \ \ \ \ \mathbf{(3.3.8.b)}$

Анализируя поведение u() и v() при $\omega \rightarrow 0$ и при $\omega \rightarrow \infty$ , получаем:

$\omega \rightarrow 0 \Rightarrow \left \{ \begin{gathered} u(\omega) \rightarrow K \\ v(\omega) \rightarrow 0\ \end{gathered} \right.$ $\omega \rightarrow \infty \Rightarrow \left \{ \begin{gathered} u(\omega) \rightarrow 0 \\ v(\omega) \rightarrow 0\ \end{gathered} \right.$

Подставляя в формулы (3.3.8) различные значения частоты , найдем соответствующие значенияu() иv(). Построим эти вектора на комплексной плоскости:

Рисунок 3.3.2 Годограф АФЧХ апериодического звена 1-го порядка

Анализ показывает, что годограф АФЧХ полукруг радиусомK/2. Формулы для дейстивительной части вектора $u(\omega)$ и мнимой части вектора $v(\omega)$ , позволяют вычислить частоту, на которой вектор находится в нижней точке окружности $\omega_3$ (см. рис. 3.3.2).

$\omega_3 = \frac{1}{T} \Rightarrow \left \{ \begin{gathered} u(\omega_3) = \frac{K}{2} \\ v(\omega_3) = - \frac{K}{2} \ \end{gathered} \right.$

Угол сдвига фазы при данной частоте: $\phi_3 = \phi(\omega_3)=\frac{\pi}{2}$

Найдем зависимость амплитуды от частоты:

$A(\omega) = \sqrt{ \left( \frac{K}{1+T^2 \cdot \omega^2} \right)^2+\left( \frac{K\cdot T \cdot \omega}{1+T^2 \cdot \omega^2} \right)^2} = \frac{K}{\sqrt{1+T^2\cdot \omega^2}}\ \ \ \ \mathbf{(3.3.9)}$

Учитывая, что годограф АФЧХ находится вIV-ой квадранте:

$\phi(\omega)= - arctg \frac{v(\omega)}{u(\omega)} =-arctg\frac{K \cdot T\cdot \omega \cdot(1+T^2\cdot \omega^2)}{K \cdot(1+T^2 \cdot \omega^2)} \Rightarrow\\\phi(\omega) =-arctg(T \cdot\omega) \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{(3.3.10)}$

Рисунок 3.3.3 АЧХ апериодического звена 1-го порядка

Рисунок 3.3.4 ФЧХ апериодического звена 1-го порядка

Логарифмическая амплитудная характеристика (ЛАХ) и фазочастотная характеристика (ФЧХ).

$Lm(\omega) = 20\cdot lg (A(\omega))=20 \cdot lg \frac{K}{\sqrt{1+T^2\cdot \omega^2}} \Rightarrow \\Lm(\omega)=20\cdot lg(K) - 20 \cdot lg \sqrt{1+T^2 \cdot \omega^2} \ \ \ \ \ \ \ \ \ \ \ \ \ \mathbf{3.3.11}$

Рисунок 3.3.5 ЛАХ и ЛФЧХ апериодического звена 1-го порядка

Анализируя частотные свойства данного звена, видим, что

при << $\frac{1}{T}$ свойства звена приблизительно совпадают со свойствами идеального усилительного звена, т.е. $W(i\cdot \omega) \ \approx K \Rightarrow W(s) \approx K$ K=> W(s) K.
при >> $\frac{1}{T}$ свойства звена приблизительно совпадают со свойствами идеального интегрирующего звена, т.е. $W(i\cdot \omega) \ \approx \frac{K}{i \cdot \omega \cdot T} \Rightarrow W(s) \approx \frac{K}{T \cdot s}$ .
при $\approx \frac{1}{T}$ на свойства звена оказывают примерно равное влияние свойства идеального усилительного и идеального интегрирующего звена.

Принято называть частоту, при которой происходит излом ЛАХ

$\omega_{сопр} = \frac{1}{T}$ сопрягающей частотой,

причем не трудно показать, что при_сопр величина амплитуды А(_сопр) меньше амплитуды при нулевой частоте A(0) = Kв $\sqrt{2}$ раз:

$A(\omega_{сопр}) = \frac{K}{\sqrt{2}}$

Частотой среза_срназывают такое значение частоты, при которой модуль (амплитуда) выходного сигнала (воздействия) равна 1.

$A(\omega_{ср})=\frac{K}{\sqrt{1+T^2 \cdot \omega_{ср} ^2}}=1 \Rightarrow\\ \omega_{ср} =\frac{\sqrt{K^2-1}}{T}$

Если K>>1 , то частота среза $\omega_{ср} = \frac{K}{T}$

Если , то частоты среза не существует !

Найдем переходную функцию звена (реакция на единичное ступенчатое воздействие):

$h(t) = L^{-1} \left[ H(s)\right] = L^{-1} \left[ \frac{ W(s)}{h}\right] = L^{-1} \left[ \frac{K}{s \cdot (T\cdot s+1)}\right]$

Используя обратное преобразования Лапласа (см. пример в разделе 2) получим:

$h(t) = K \cdot \left[ 1- e^{-\frac{t}{T}}\right]$

Тогда, дифференцируя по времени, получаем весовую функцию(t):

$w(t) = \frac{K}{T} \cdot e^{-t/T} \cdot1(t)$

Множитель 1(t) обеспечивает равенство нулю приt 0

Рис.3.3.6 Переходная функция апериодического звена 1-го порядка

Рис.3.3.7 Весовая функция апериодического звена 1-го порядка

Постоянная времени Т характеризует инерционность переходных процессов в звене. Чем больше Т, тем инерционнее звено (т.е. медленнее идет переходной процесс).

Примерами апериодического звена 1- го порядка являются:

1) пассивныеRLилиRCцепочки (см. рисунок 3.3.8);

Рисунок 3.3.8 Примеры апериодических звеньев 1-го порядка

2) упрощенная модель гидротурбины, гдеx(t) - приводной момент;y(t) скорость вращения ротора турбины;

3) электродвигатель (постоянного тока или асинхронный) с учетом инерционности якоря (ротора), гдеx(t) напряжение в обмотке возбуждения, аy(t) скорость вращения якоря (ротора) выходного вала;

4) тепловые датчики, например, термопара, где:x(t) температура одного (горячего) спая, аy(t) термо Э.Д.С.

5) выходная камера смешения в реакторе (приближенно)

6) различные элементы реактора, описываемые в рамках точеных моделей (например, активная зона или ядерное горючее) с использованиемзакона Фурье:

$c \frac{dT(t)}{dt} = N_{out}(t)-\alpha_{v}[T(t)-T_*]$

где: T(t) температура топлива;

$\alpha_v$ объемный коэффициент теплоотдачи;

$N_{out}$ выделяющаяся энергия;

T_* температура кипения теплоносителя.

Пример

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

Рассмотрим расчет характеристик камеры смешения, в которую подается вода при температуре 20 С и атмосферном давлении.

В качестве единичного воздействия будем считать изменение температуры на 1 C.

Свойства воды при 20 градусах и атмосферном давлении:

теплоёмкость:= 4183 $\frac{Дж}{кг \cdot град}$ ;
плотность: $\rho$ = 998.2 $\frac{кг}{м^3}$ .

Параметры системы:

объем камеры смешения:V= 0.1 ;
массовый расход воды: G = 50 $\frac{кг}{с}$ .

Решим задачу в двух приближениях:

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

Параметры блока Инерционное звено первого порядка задаем с помощью скриптового языка при инициализации проекта, где рассчитывается постоянная времени. (см. рис. 3.3.9). В качестве входного воздействия задаем ступеньку на пятой секунде расчета величиной 0.05, что соответствует повышению на 1 C от начальных 20 C .

На схеме присутствует также блок Построение частотных характеристик, обеспечивающий расчет ЛАХ и ФЧХ в заданном диапазоне 0.1 1000 1/с.

Расчетная схема и результаты расчета приведены на рисунке 3.3.9:

Рисунок 3.3.9 Частотный анализ модели камеры смешения в виде стандартного апериодического звена

Видно, что расчетные характеристики в модели совпадают с теоретическими:

1)Постоянная времениT= 1.996

2)Сопрягающая частотаw_сп= 1/T= 0,5009

Годограф звена, построенный с помощью Гармонического анализатора, представлен на рисунке 3.3.10, Видно, что получена полуокружность с центром в точке(0, 0.5) и диаметром К = 1, как и предсказано в теоретической части.

Рисунок 3.3.10 Годограф модели камеры смешения в виде Инерционного звена первого порядка.

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

Блок Подпитка обеспечивает подачу теплоносителя с заданными параметрами и заданным расходом. В нашем случае это вода при атмосферном давлении и температурой 20 C.
Блок Внутренний узел (Node_1), - модель камеры смешения.
Блок Канал общего вида моделирует обобщенно каналы отвода теплоносителя от камеры смешения (состоит из 10 участков).
Блок Граничный узел задает температуру и давление на выходе из каналов. В нашем случае атмосферное давление и температуру.

Общий вид модели приведен на рисунке 3.3.11 Цветовая шкала показывает распределение давления в канале, который идет после камеры смешения. Исходя из уравнений физики, система рассчитывает перепад давления, соответствующий заданному расходу по каналу (50 кг/с) с учетом его геометрии, свойств жидкости, шероховатости и т.п.

Рисунок 3.3.11 Модель камеры смешения в коде НS.

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

Рисунок 3.3.12 Температура в узле в начальный период расчета.

Все дело в том, что система у нас динамическая, и распределение расхода и температур по узлам модели в начале расчёта не соответствует стационарному состоянию. И некоторое время происходят колебания расходов и, соответственно, температур до достижения равновесия.

Чтобы в расчётах не учитывать данные колебания, и не заставлять пользователя задавать вручную состояние каждой точки системы, используется специальный инструмент Файл рестарта. В этот файл сохраняются состояния системы в конце расчета или с заданным шагом.И эти состояния можно загрузить при старте системы. Если сохранить состояние системы, находящейся в стационаре один раз, то потом можно использовать его для начала расчёта, тем самым избегая колебаний системы. Для этого необходимо:

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

Рисунок 3.3.13 Настройка файлов рестартов.

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

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

гидравлическая модель в коде НS;
модель виде одного звена.

Обмен данными будет идти через базу данных сигналов. Передадим результаты расчета из гидравлического кода в модель с одним звеном и выполним сравнение результатов. Вид пакета представлен на рисунке 6.

В главном скрипте гидравлической схемы пропишем переменнуюT_input температуру на входе в камеру, на 5 секунде расчёта увеличим эту температуру на C. А температуру в узле будем записывать в базу данных сигналов в категориюnodе_HS, переменнаяT_out.

В модели общего вида прочитаем значение сигнала в базе данныхnodе_HS_T_out.

Сравним с выходом из апериодического звена (модель камеры смешения) и выведем на один график.

Рисунок 3.3.13 Пакет для сравнения моделей узла смешения.

Результаты совместного расчета представлены на рисунке 3.3.14

Если на общем графике в масштабе 20 21 C графики практически совпадают, то анализ графика сравнения показывает наличие расхождения в момент ступенчатого изменения температуры. Причем максимальное расхождение 0.0085 C отмечено именно в момент переключения, а потом происходит выравнивание температуры (см. рис. 3.3.14).

Рисунок 3.3.14 Сравнение переходного процесса для разных моделей камеры смешения.

Разница связанна как раз с более сложной и детализированной моделью в тепло-гидравлическом коде НS. Дело в том, что в реальности и плотность и теплоёмкость воды не являются постоянными, а зависят от параметров давления и температуры, и даже изменение температуры на один градус ведет к изменению подведения.

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

Рисунок 3.3.15 Колебания давления и расхода при ступенчатом изменении температуры.

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

Проведем исследования с помощью блока "Гармонический анализатор". Создадим пакет проектов, состоящий из:

тепло-гидравлической модели (см. рис. 3.3.11);
модели частотного анализа. (см. рис. 3.3.16).

Рисунок 3.3.16 Модель частотного анализа внешней системы.

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

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

А в конце процесса частота 1000 Гц, и нам нужно сократить шаг интегрирования, чтобы получить достаточное количество точек в синусоидальном сигнале при высокой частоте.

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

Рисунок 3.3.17 Скрипт гидравлической модели.

Как работает этот скрипт?

Начальное значение температуры 20 C.

Если частота воздействия больше 100, то минимальный шаг модели 0.00001, иначе (при частоте воздействия меньше 100) минимальный шаг модели 0.0001.

Температура в блоке подпиткиT_inputрассчитывается как сумма начальной температуры 20C и величины воздействияnode_inputиз базы данных сигналов, которое формирует блок гармонического анализатора в диапазоне -1 +1 C.

Температура в узле передаётся в базу данных для гармонического анализатора.

Результат длительного расчёта представлен на рисунке 3.3.18.

Рисунок 3.3.18. Результаты анализа частотного анализа гидравлической модели.

Мы видим, что несмотря на различия в математических моделях, частотные характеристики камеры смешения в тепло-гидравлическом коде отлично совпадают в диапазоне частот 0.001 до 50 Гц. Сравни с рисунком 3.3.9

Однако на частотах выше 70 ФЧХ ведет себя не так, как в идеальном апериодическом звене. Если открыть график давления в камере смешения и график массового расхода в канале, можно наблюдать увеличение амплитуды колебаний с ростом частоты воздействия (см. рис. 3.3.19).

Рисунок 3.3.19 Давление в узле и расход в выходном канале с ростом частоты воздействия по температуре.

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

Выводы.

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

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

Примеры моделей из лекции для самостоятельного изучения.

Предыдущая лекция.

Ссылки по теме моделирования систем:

Цифровой двойник системы кондиционирования воздуха (СКВ) самолета
Модельно ориентированное проектирование. Создание достоверной модели, на примере авиационного теплообменника
Конечные автоматы в среде динамического моделирования SimInTech
Модельно-ориентированное проектирование. Построение активного выпрямителя (на основе математической модели)
Технология получения уравнений динамики ТАУ. И почему System Identification is sucks, а рулит честная физика
Модельно ориентированное проектирование. Электропривод с бесколлекторным двигателем постоянного тока
Ведение в моделирование динамики квадро-, гекса- и октокоптеров

Подробнее..

Категории: Анализ и проектирование систем , Matlab , Математика , Тау , Simintech , Промышленное программирование , Моделирование предметной области , Графические оболочки , Ачх , Сау , Частотные характеристики , Simulation , Апериодическое звено , Тепло-гидравлика

Деятельность, документы и семантика

07.07.2020 16:22:26 |

Автор: admin

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

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

При решении задачи мы имеем дело с несколькими сущностями

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

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

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

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

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

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

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

Итак, идейную основу предложенного решения составляет представление о необходимости совмещения в одной цифровой модели деятельности: (1) алгоритма действий, (2) документа, определяющего юридическую обусловленность этих действий, (3) актора действий, и (4) самой деятельности, которая, по сути, полностью переходит в цифровое пространство.

Технологический базис решения составляют стандартные на сегодняшний день технологии:

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

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

См. еще Семантика и деятельность

Подробнее..

Категории: Криптография , Бизнес-модели , Семантика , Моделирование предметной области , Блокчейн , Электронная документация , Смарт-контракты , Семантическая разметка

	Русский
	English

Моделирование предметной области

UML. Взгляд со стороны или Как UML удерживает аналитиков в прошлом

Аспекты представления

Уровни представления

Сервис-ориентированная подход

Человек и Магазин

Парадигмы

Человек и Собака

Вместо заключения

3. Частотные характеристики систем автоматического управления. ч. 3.3 Апериодическое звено 1го порядка

3.3. Апериодическое звено 1го порядка (инерционное звено)

Пример

Деятельность, документы и семантика

Категории

Последние комментарии