시스템 모델(System Models)¶

연결(Connections)¶

이 장에서 구성 요소와 하위 시스템 모델 사이에서 본 한 가지 차이점은 하위 시스템 모델에는 connect 문이 포함된다는 것입니다. connect 문이 어떻게 작동하는지 알아보기 위해 열 제어(Thermal Control) 에 대한 논의에서 MultiDomainControl 예제를 다시 살펴보겠습니다.모든 주석을 제거하면(곧 논의할 예정임) 다음과 같은 모델을 얻게 됩니다.

within ModelicaByExample.Components.BlockDiagrams.Examples;
model MultiDomainControl
  "Mixing thermal components with blocks for sensing, actuation and control"

  import Modelica.SIunits.Conversions.from_degC;

  parameter Real h = 0.7 "Convection coefficient";
  parameter Real m = 0.1 "Thermal maass";
  parameter Real c_p = 1.2 "Specific heat";
  parameter Real T_inf = from_degC(25) "Ambient temperature";
  parameter Real T_bar = from_degC(30.0) "Desired temperature";
  parameter Real k = 2.0 "Controller gain";

  Components.Constant setpoint(k=T_bar);
  Components.Feedback feedback;
  Components.Gain controller_gain(k=k);
  HeatTransfer.ThermalCapacitance cap(C=m*c_p, T0 = from_degC(90));
  HeatTransfer.Convection convection2(h=h);
  HeatTransfer.AmbientCondition amb(T_amb(displayUnit="K") = T_inf);
  Components.IdealTemperatureSensor sensor;
  Components.HeatSource heatSource;
equation
  connect(setpoint.y, feedback.u1);
  connect(feedback.y, controller_gain.u);
  connect(convection2.port_a, cap.node);
  connect(amb.node, convection2.port_b);
  connect(sensor.y, feedback.u2);
  connect(heatSource.node, cap.node);
  connect(controller_gain.y, heatSource.u);
  connect(sensor.node, cap.node);
end MultiDomainControl;

비인과적 모델링(Acausal Modeling) 에 대한 이전 논의에서 커넥터의 인과적 변수를 생성하는 방정식에 대해 이야기했습니다.그러나 connect 문의 영향은 연결되는 변수의 특성에 따라 다릅니다.``MultiDomainControl`` 모델은 비인과적 연결에 제한되지 않기 때문에 유용합니다.

MultiDomainControl 모델의 특정 연결을 고려하기 전에 먼저 connect 문이 실제로 수행하는 작업에 대해 자세히 설명하겠습니다. 발생하는 몇 가지 복잡한 경우가 있지만 단순한것을 다루기 위해서 그리고, 교육적인 목적을 위해 여기서는 기본적인 경우만 논의 하겠습니다.

connect 문은 정확히 두 개의 커넥터를 연결합니다.그런 다음 이름별로 각 커넥터에서 변수를 "쌍으로 만듭니다".즉, 한 커넥터에서 각 변수를 가져와서 다른 커넥터에 있는 같은 이름의 변수와 쌍을 이룹니다.

각 쌍에 대해 컴파일러는 먼저 두 개의 해당 변수가 동일한 자료형(예: Real, Integer)인지 확인합니다.그러나 생성되는 방정식과 존재하는 추가 제한 사항은 변수에 적용된 한정자에 따라 다릅니다.다음 목록은 모든 필수 사례를 다룹니다.

• Through variables - flow 한정자가 있는 변수입니다. 인과적 모델링에 대한 이전 논의에서 다룬 것처럼 연결 집합의 모든 변수에 대해 보존 방정식이 생성됩니다.

• Parameters - parameter 한정자를 포함하는 변수는 방정식을 생성하지 않습니다. "대신 두 변수 사이의 값이 동일한지 확인하는 assert 호출을 생성합니다. 커넥터 가 커넥터의 배열 크기를 지정하는 정수 파라미터를 포함할 때 유용합니다.예를들어 배열이 같은 크기인지 확인하고 경고를 보냅니다.

• input - 입력 한정자가 있는 변수는 입력 또는 출력 한정자가 있는 변수와만 쌍을 이룰 수 있습니다. 이 요구 사항이 충족된다고 가정하면 이 두 변수를 동일시하는 방정식이 생성됩니다.

• output - output 한정자가 있는 변수는 input 한정자가 있는 변수와만 쌍을 이룰 수 있습니다(즉, 두 개의 출력은 연결할 수 없음). 입력 변수의 경우와 마찬가지로 이러한 연결에 대해 등식관계가 생성됩니다.

• Across variables - 이전 사례와 달리 한정자가 없는 변수입니다. 인과 모델링'에 대한 이전 논의에서 다루었듯이 일련의 방정식이 연결 세트의 모든 교차 변수를 동일시하여 생성됩니다.

블록 다이어그램 구성요소(Block Diagram Components) 에 대한 논의에서 input 및 output 한정자를 "causal"로 설명합니다. 실제로 input 및 output 한정자는 실제로 계산이 수행되는 순서를 지정하지 않습니다. 위에서 설명한 것처럼 변수를 연결할 수 있는 방법에 대한 제한을 적용할 뿐입니다. 이미 언급한 제한 사항 외에도 연결 세트 내에서 하나의 "출력" 신호만 있을 수 있다는 추가 제한 사항이 있습니다(명백한 이유로).

MultiDomainControl 모델에서 이러한 사례 중 몇 가지를 볼 수 있습니다. 예를 들어,

connect(setpoint.y, feedback.u1);

여기에서 output 신호인 setpoint.y 는 input 신호인 feedback.u1 에 연결됩니다.따라서 이것은 인과적 신호만을 포함하는 연결입니다. 반면에 다음과 같은 연결이 있습니다.

connect(heatSource.node, cap.node);

이것은 보존 방정식의 자료형으로 이어질 것입니다.

요약하면, connect 문은 복잡한 작업(예: 보존 및 연속 방정식 생성)을 자동으로 관리하는 방정식을 생성하는 동시에 연결이 의미가 있는지 확인하는 방법입니다(예: ., 변수가 동일한 자료형을 가짐).

다이어그램(Diagrams)¶

이 장에서는 모델리카 하위 시스템 모델을 그래픽으로 표시하는 방법을 보여 주었습니다. 예:

이러한 다이어그램을 생성하는 데 필요한 모든 정보는 모델리카 모델에 포함되어 있습니다.이 정보는 이 장의 일부 모델리카 코드 목록에서 볼 수 있지만 실제로 어떤 정보가 어디에 저장되는지 논의하지 않았습니다.

하위 시스템 다이어그램을 그려보기 위해서는 세 가지 정보가 필요합니다.

• 각 구성 요소를 나타내는 데 사용할 아이콘

• 각 구성 요소의 위치.

• 각 연결 경로

  Convection convection(h=0.7, A=1.0)
    annotation (Placement(transformation(extent={{10,-10},{30,10}})));

record Placement
  Boolean visible = true;
  Transformation transformation "Placement in the diagram layer";
  Transformation iconTransformation "Placement in the icon layer";
end Placement;

record Transformation
  Point origin = {0, 0};
  Extent extent;
  Real rotation(quantity="angle", unit="deg")=0;
end Transformation;

  connect(controller_gain.y, heatSource.u) annotation ...