1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/junruoyu-zheng-ligral

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
signature.md 7 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 29.11.2024 02:01 6be31cf

Интерфейс подписи

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

Синтаксис

Синтаксис определения интерфейса подписи выглядит следующим образом:

signature SignatureName(inputs; outputs);

Он похож на синтаксис атрибутов маршрутизации, но имеет три отличия:

  • Ключевое слово — signature вместо route.
  • Нельзя объявлять подпись для подписи.
  • Не нужно указывать список параметров.

Кроме того, поскольку нет основной части, оператор объявления интерфейса подписи заканчивается символом «;». Подписи не могут быть объявлены для других подписей, так как подпись уже полностью определяет все интерфейсы узла, и объявление подписи для узла не приведёт к изменению его функциональности. Параметры не являются частью интерфейса, поэтому их определение не входит в обязанности подписи. Следовательно, экземпляры должны создаваться на уровне маршрутизации, а не для интерфейса подписи.

Использование

Как упоминалось в предыдущем разделе, использование подписи включает в себя определение оператора и два места в определении маршрутизации:

route Route:NodeSignature (...) ...

Это означает, что маршрутизация Route объявляет подпись NodeSignature. Другое место — это список параметров маршрутизации:

route Route2 (param:NodeSignature, ...; ...) ...

Здесь маршрутизация Route2 имеет параметр param, который является узлом с подписью NodeSignature. Таким образом, при создании экземпляра Route2 можно написать:

Route2{param:Route, ...};

Обратите внимание, что символ «:» здесь не указывает, что param объявляет Route. Во-первых, Route является экземпляром узла, а не подписью, которую нельзя объявить. Во-вторых, символ «:» действует аналогично двоеточию в JSON или может быть интерпретирован как присвоение значения Route идентификатору param, подобно использованию необязательных параметров в C#.

Пример

Пример контроллера PIDController был представлен в более ранних документах, а пример системы пружинного демпфера MassSpringDamper представлен в разделе быстрого старта. Предположим, необходимо создать замкнутую модель, соединив эти два модуля.

MassSpringDamper[sys]{m:0.1, k:10, d:0.3, x0:1, v0: 0};
PIDController[controller]{Kp:1, Ki:0.1, Kd:4);
sys:x -> controller -> sys;

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

route ClosedLoopMSD(m, k, d, x0, v0, Kp, Ki=0, Kd=0, tau=0.01; F; x, v)
    MassSpringDamper[sys]{m:m, k:k, d:d, x0:x0, v0:v0};
    PIDController[controller]{Kp:Kp, Ki:Ki, Kd:Kd, tau:tau);
    (sys:x -> controller) + F -> sys -> (x, v);
end

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

Используя синтаксис подписи ligral, можно устранить эти проблемы и сохранить лаконичный синтаксис. Определите две подписи:

signature MSDSignature(F; x, v);
signature CTRSignature(x; u);

Они определяют интерфейс пружинного демпфера и интерфейс контроллера соответственно. Затем в определении замкнутой модели:

route ClosedLoopMSD(sys:MSDSignature, controller:CTRSignature; F; x, v)
    (sys:x -> controller) + F -> sys -> (x, v);
end

Наконец, перед созданием экземпляра ClosedLoopMSD определите экземпляры sys и controller и передайте их:

MassSpringDamber[sys]{m:0.1, k:10, d:0.3, x0:1, v0: 0};
PIDController[controller]{Kp:1, Ki:0.1, Kd:4);
ClosedLoopMSD{sys:sys, controller:controller};
F -> ClosedLoopMSD:x -> Scope;

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

route SMC:CTRSignature(...; x; u)
    ...
end

Вы можете легко заменить:

SMC[smc]{...};
ClosedLoopMSD{sys:sys, controller:smc};

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/junruoyu-zheng-ligral.git
git@api.gitlife.ru:oschina-mirror/junruoyu-zheng-ligral.git
oschina-mirror
junruoyu-zheng-ligral
junruoyu-zheng-ligral
dev