온도 제어(Thermal Control)¶

초기 접근(Initial Approach)¶

아키텍쳐(Architecture)¶

다음 아키텍처부터 시작하겠습니다.

여기서 이전 섹션에서 보았던 것과 동일한 기본 부품, 즉 즉 , 플랜트 모델, 센서, 컨트롤러 및 액추에이터를 볼 수 있습니다. 사실 이것은 꽤 전형적인 아키텍처입니다. 경우에 따라 사람들은 플랜트 모델을 몇 개의 하위 시스템으로 분해하거나 여러 컨트롤러 및 제어 루프를 포함할 수 있습니다. 그러나 많은 폐쇄 루프의 시스템 제어 문제는 이와 동일한 기본 구조를 따릅니다.

애플리케이션에서 애플리케이션으로 변경되는 경향이 있는 것은 이러한 부분 간에 교환되는 특정 신호입니다. 이 경우 아키텍처 도식에서 인터페이스 정의가 다음과 같이 되어 있음을 알 수 있습니다.

• 액추에이터는 명령된 온도를 수신한 다음 플랜트에 열 연결을 통해 열을 주입합니다.

• 센서 모델에는 (플랜트에 대한) 열 커넥터와 측정된 온도를 포함하는 출력 신호도 있습니다.

• 플랜트에는 두 개의 열 연결부가 있습니다. 하나는 퍼니스 열이 시스템에 추가되는 위치를 나타내고 다른 하나는 센서가 있는 위치를 나타냅니다.

• 컨트롤러는 (센서에서) 측정된 온도를 입력으로 받아 명령된 열 출력을 (액추에이터로) 출력합니다.

앞서 설명한 기본 시스템의 모델리카 코드는 다음과 같습니다.

within ModelicaByExample.Architectures.ThermalControl.Architectures;
partial model BaseArchitecture "A basic thermal architecture"
  replaceable Interfaces.PlantModel plant
    annotation ...
  replaceable Interfaces.ControlSystem controller
    annotation ...
  replaceable Interfaces.Sensor sensor
    annotation ...
  replaceable Interfaces.Actuator actuator
    annotation ...
equation
  connect(plant.room, sensor.room) annotation ...
  connect(sensor.temperature, controller.temperature) annotation ...
  connect(actuator.furnace, plant.furnace) annotation ...
  connect(controller.heat, actuator.heat) annotation ...
end BaseArchitecture;

앞서 설명한 기본 시스템의 모델리카 코드는 다음과 같습니다.¶

플랜트(Plant)¶

우리 플랜트 모델은 다음과 같습니다.

여기서 온도가 다른 구역에서 측정되는 동안 한 구역에 보일러의 열이 추가되는 것을 볼 수 있습니다.또한 액추에이터와 센서 영역 사이에 추가 영역이 있습니다. 보일러 모델 자체는 간단한 열원입니다.

이 액추에이터는 명령된 열 수준을 입력으로 받은 다음 연결된 영역에 해당 양의 열을 주입합니다.

센서도 마찬가지로 간단합니다.

이 센서는 아티팩트를 발생시키지 않습니다.대신 연속 출력 신호로 구역의 정확한 온도를 제공합니다.

다음은 PI 컨트롤러를 사용하여 온도를 제어합니다.

초기 결과(Initial Results)¶

이러한 구현으로 아키텍처를 채우면 이제 모델이 다음과 같이 보입니다.

다양한 하위 시스템의 아이콘이 어떻게 변경되었는지 확인하십시오. 이는 redeclare 를 수행할 때 해당 하위 시스템과 관련된 새 자료형의 아이콘이 사용되기 때문입니다. 이 시스템의 모델리카 코드는 다음과 같습니다.

within ModelicaByExample.Architectures.ThermalControl.Examples;
model BaseModel "Base model using a conventional architecture"
  extends Architectures.BaseArchitecture(
    redeclare Implementations.ThreeZonePlantModel plant(
      C=2, G=1, h=2, T_ambient=278.15),
    redeclare
      ModelicaByExample.Architectures.ThermalControl.Implementations.ConventionalPIControl
      controller(setpoint=300, T=1, k=20),
    redeclare Implementations.ConventionalActuator actuator,
    redeclare Implementations.ConventionalSensor sensor);
end BaseModel;

이 시스템을 시뮬레이션하면 다음과 같은 결과를 얻습니다.

보시다시피 이 접근 방식은 매우 잘 작동합니다. 이 정도의 제어를 달성하는 데 필요한 보일러의 열은 다음과 같습니다.

뱅 뱅 제어(Bang Bang Control)¶

지금까지 이 접근 방식은 꽤 성공적이었던 것 같습니다. 다양한 액추에이터, 센서, 컨트롤러 또는 플랜트 모델을 고려하는 데 사용할 수 있는 멋진 아키텍처가 되었고,개발한 제어 시스템은 우리 플랜트를 상당히 잘 제어하는 것 같습니다.

그러나 주목할 가치가 있는 한 가지는 이 경우에 필요한 보일러 열이 연속적이라는 것입니다.그러나 가정 난방 시스템은 일반적으로 이러한 형태의 제어 방법을 사용하지 않습니다.대신에 그들은 보일러가 "꺼짐" 또는 "켜짐"인 "뱅뱅" 컨트롤을 사용하는 경향이 있습니다.

이 유연한 아키텍처를 가지고 있으므로 아마도 이 상황을 해결하기 위해 컨트롤러 명령이 용광로의 켜짐 또는 꺼짐 여부를 나타내는 부울 값을 가지는 컨트롤러 및 액추에이터 모델의 구현을 생성해야 합니다.그러나 이 프로세스를 시작하면 다음과 같은 문제가 바로 발생합니다.

컨트롤러의 출력은 Boolean 값이지만 ControlSystem 인터페이스에서 명령된 heat 신호에는 Real 값이 필요합니다.액추에이터 쪽에도 동일한 문제가 있습니다

인터페이스는 실제 값인 액추에이터를 제공하지만 보일러가 "켜짐" 또는 "꺼짐" 명령을 예상하는 경우 불일치가 있음을 다시 확인 할 수 있습니다.

따라서 질문은 서로 다른 하위 시스템을 선택하기 위해 서로 다른 인터페이스가 필요한 상황 을 어떻게 처리할 수 있는가 하는 것입니다.

확장된 접근(Expandable Approach)¶

이 문제에 대한 해결책은 확장 가능한 커넥터 정의입니다. 이 접근 방식을 사용하면 제어 전략이 Boolean 또는 Real 을 생성하는지 여부에 관계없이 하위 시스템 인터페이스가 동일합니다. 변경되는 것은 connector 인스턴스의 내용입니다.

이러한 확장형 커넥터가 작동하는 방식을 이해하기 위해 확장형 커넥터를 포함하도록 아키텍처를 재구성한 다음 이러한 커넥터가 연속 및 "뱅뱅" 접근 방식 모두에 어떻게 사용될 수 있는지 살펴보겠습니다.

확장가능한 커넥터(Expandable Connectors)¶

보다 유연한 아키텍처를 만들 수 있게 해주는 핵심 기능은 확장 가능한 커넥터 입니다. 예를 들어 이전에 Actuator 인터페이스를 다음과 같이 정의했습니다.

within ModelicaByExample.Architectures.ThermalControl.Interfaces;
partial model Actuator "Actuator subsystem interface"

  Modelica.Blocks.Interfaces.RealInput heat "Heating command" annotation ...

  Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_b furnace
    "Connection point for the furnace"
    annotation ...
end Actuator;

이 인터페이스에는 heat 커넥터와 furnace 커넥터의 두 커넥터가 있습니다. furnace 커넥터는 로가 플랜트와 열적으로 상호 작용할 수 있도록 하는 열 커넥터입니다. heat 커넥터는 컨트롤러에서 나오는 Real 값 입력 신호이며 원하는 열 출력 수준을 지정합니다. 이것이 Real 값 신호라는 사실은 Boolean 신호가 필요한 제어 자료형으로 전환하려고 할 때 문제였습니다. 이 문제를 해결하기 위해 액추에이터에 대해 다음 인터페이스 정의를 사용합니다.

within ModelicaByExample.Architectures.ThermalControl.Interfaces;
partial model Actuator_WithExpandableBus
  "Actuator subsystem interface with an expandable bus"

  ExpandableBus bus
    annotation ...

  Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_b furnace
    "Connection point for the furnace"
    annotation ...
end Actuator_WithExpandableBus;

여기에서 furnace 커넥터가 여전히 존재하는 것을 볼 수 있습니다. 하지만 열 커넥터가 사라졌습니다.대신 ExpandableBus 자료형의 새로운 커넥터 인스턴스인 bus 로 대체되었습니다. ExpandableBus 에 대한 커넥터 정의는 다음과 같습니다.

within ModelicaByExample.Architectures.ThermalControl.Interfaces;
expandable connector ExpandableBus "An example of an expandable bus connector"
end ExpandableBus;

즉 다른말로 하면, 비어 있습니다. 그러나 중요한 것은 expandable 한정어의 존재이다.지정된 버스가 항상 특정 신호를 가져야 하는 경우 커넥터 정의 내에 나열되어야 합니다.그러나 ExpandableBus 클래스에 나열된 변수나 하위 커넥터가 없다는 사실은 정보가 버스에 전달되기 위한 최소 요구 사항이 없음을 의미합니다.그러나 추가 정보를 포함하도록 버스를 확장 할 수 있습니다.

모델리카에는 "버스"에 대한 공식적인 정의가 없습니다. 이 용어는 이러한 맥락에서 여러 정보를 전달하는 커넥터를 의미하는 데 자주 사용합니다.

확장 가능한 커넥터는 특별한 방식으로 작동합니다. 확장 가능한 버스의 신호는 연결 자체에 의해 결정됩니다. 확장 가능한 버스에 무언가를 연결하면 신호가 암시적으로 해당 커넥터에 추가됩니다. 그런 다음 모델리카 컴파일러는 연결 세트의 모든 커넥터를 보고 일치하도록 각 커넥터를 확장합니다.논의할 구현 모델이 있는 시점에 이르면 이 프로세스에 대해 자세히 설명하겠습니다.

플랜트 모델의 인터페이스는 확장 가능한 커넥터의 사용에 영향을 받지 않지만(이러한 확장 가능한 커넥터는 플랜트 모델과 연결되어 있지 않기 때문에) 센서 및 컨트롤러의 인터페이스는 다음과 같이 변경됩니다.

within ModelicaByExample.Architectures.ThermalControl.Interfaces;
partial model Sensor_WithExpandableBus
  "Sensor subsystem interface using an expandable bus"

  Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_a room
    "Thermal connection to room"
    annotation ...

  ModelicaByExample.Architectures.ThermalControl.Interfaces.ExpandableBus bus
             annotation ...
end Sensor_WithExpandableBus;

within ModelicaByExample.Architectures.ThermalControl.Interfaces;
partial model ControlSystem_WithExpandableBus
  "Control system interface using an expandable bus connector"
  ExpandableBus bus annotation ...
end ControlSystem_WithExpandableBus;

컨트롤러 인터페이스가 얼마나 단순해졌는지 확인해 보십시오.``확장형`` 커넥터를 사용하면 센서에서 수신한 온도 측정값과 액추에이터로 보낸 열 명령을 동일한 버스 에 둘 수 있기 때문입니다.따라서 하나의 커넥터만 필요합니다. 개발자는 단순히 신호를 구성하거나 물리적 분할을 더 잘 나타내도록 하거나 혼동을 피하기 위해 여러 버스를 사용하도록 선택할 수 있습니다.여기서는 단일 커넥터를 사용하여 이것이 이제 가능함을 보여줍니다.

확장 가능한 커넥터를 사용하여 다음과 같은 수정된 아키텍처를 만들 수 있습니다.

확장된 구현(Expandable Implementations)¶

이 보다 유연한 아키텍처를 사용하여 먼저 연속 제어 시스템으로 원래 구성을 다시 생성해 보겠습니다.

이 시스템의 결과를 선도로 표현하면 다음 응답을 얻습니다.

측정된 온도는 신호 controller.bus.temp 에 해당하며 여기서 bus 는 확장 가능한 커넥터의 인스턴스가 되었습니다.더 나아가 ExpandableBus 정의에 온도 라는 신호가 포함되지 않았다는 점을 기억해야 합니다.그래서 문제는 그것이 어떻게 커넥터에 닿았느냐 하는 것입니다.답은 센서 모델의 구현에 있습니다.센서 모델의 다이어그램은 다음과 같습니다

해당 모델리카 코드는 다음과 같습니다.

within ModelicaByExample.Architectures.ThermalControl.Implementations;
model TemperatureSensor "Temperature sensor using an expandable bus"
  extends Interfaces.Sensor_WithExpandableBus;
protected
  Modelica.Thermal.HeatTransfer.Sensors.TemperatureSensor sensor
    annotation ...
equation
  connect(sensor.T, bus.temperature) annotation (Line(
      points={{10,0},{100,0}},
      color={0,0,127},
      smooth=Smooth.None));
  connect(room, sensor.port) annotation ...
end TemperatureSensor;

특히 중요한 것은 강조 표시된 줄입니다.

다이어그램에서 온도 센서 구성 요소의 출력 신호가 버스에 연결되어 있음을 알 수 있습니다.그러나 connect 문을 보면 단순히 버스에 연결하는 것 이상입니다. 그것은 버스 내부의 온도 라는 무언가와 연결되어 있다는 것을 나타냅니다.이 온도 커넥터는 ExpandableBus 정의에 존재하지 않습니다. 대신 connect 명령문 자체 에 의해 생성됩니다! 이것이 바로 expandable 한정자가 허용하는 것입니다.

일반적으로 모든 커넥터가 확장 이 되는 것을 원하지 않습니다.*선험적으로* 모든 신호의 이름과 자료형을 알고 있는 경우 명시적으로 나열하는 것이 좋습니다. 이를 통해 모델리카 컴파일러는 모델의 정확성을 보장하기 위해 몇 가지 중요한 검사를 수행할 수 있습니다.커넥터에 expandable 한정자를 추가하면 실수로 의도하지 않은 신호 (예: 타이핑 오류의 결과)를 생성할 위험이 컴파일러에 의해 포착될 가능성이 있다는 점은 주목할 가치가 있습니다.

재설정(Reconfiguration)¶

이제 시스템의 연속 제어 버전을 모델링하기 위해 확장 가능한 접근 방식을 사용하는 방법을 보여주었으므로 "bang-bang" 버전으로 관심을 돌려 보겠습니다.

이미 확장형 커넥터와 함께 작동하도록 구성된 온도 센서 하위 시스템을 보았습니다. 남은 것은 컨트롤러와 액추에이터 모델입니다. 액추에이터 모델 다이어그램은 다음과 같습니다.

모델리카 코드를 살펴보는 것은 bus 커넥터의 신호가 어떻게 참조되는지 확인하는 데 중요합니다.

within ModelicaByExample.Architectures.ThermalControl.Implementations;
model OnOffActuator "On-off actuator implemented with an expandable bus"
  extends Interfaces.Actuator_WithExpandableBus;
  parameter Real heating_capacity "Heating capacity of actuator";
protected
  Modelica.Thermal.HeatTransfer.Sources.PrescribedHeatFlow heater
    annotation ...
  Modelica.Blocks.Math.BooleanToReal command(realTrue=heating_capacity,
      realFalse=0)
    annotation ...
equation
  connect(heater.port, furnace) annotation ...
  connect(command.y, heater.Q_flow) annotation ...
  connect(command.u, bus.heat_command) annotation (Line(
      points={{-62,0},{-100,0}}, color={255,0,255},
      smooth=Smooth.None));
end OnOffActuator;

다시 한 번 강조된 줄에 유의하십시오. 버스 커넥터에서 heat_command 라는 것을 참조합니다.다시 말하지만, 해당 신호는 ExpandableBus 정의에 존재하지 않지만 강조 표시된 connect 문에서 참조되기 때문에 암시적으로 생성됩니다.

센서 모델에서 측정된 값이 온도 라는 실제 신호로 버스 커넥터에 추가되는 것을 볼 수 있습니다. 액추에이터 모델에서 컨트롤러에서 액추에이터가 기대하는 명령이 heat_command 라는 부울 신호임을 알 수 있습니다. 따라서 컨트롤러 모델에서 사용하는 이 두 신호를 모두 볼 수 있어야 합니다. 컨트롤러 다이어그램은 다음과 같습니다.

그러나 다이어그램에는 버스 커넥터에서 참조되는 신호의 정확한 이름을 알기에 충분한 세부 정보가 포함되어 있지 않습니다.이를 위해서는 실제 소스 코드를 살펴봐야 합니다.

within ModelicaByExample.Architectures.ThermalControl.Implementations;
model ExpandablePIControl "PI controller implemented with an expandable bus"
  extends Interfaces.ControlSystem_WithExpandableBus;
  parameter Real setpoint "Desired temperature";
  parameter Real k=1 "Gain";
  parameter Modelica.SIunits.Time T "Time Constant (T>0 required)";
protected
  Modelica.Blocks.Sources.Trapezoid setpoint_signal(
    amplitude=5, final offset=setpoint, rising=1,
    width=10, falling=1, period=20)
    annotation ...
  Modelica.Blocks.Math.Feedback feedback
    annotation ...
  Modelica.Blocks.Continuous.PI PI(final T=T, final k=-k)
    annotation ...
equation
  connect(setpoint_signal.y, feedback.u2)
    annotation ...
  connect(PI.u,feedback. y) annotation ...
  connect(bus.temperature, feedback.u1) annotation (Line(
      points={{0,-100},{60,-100},{60,0},{28,0}},
      color={0,0,0}, smooth=Smooth.None));
  connect(PI.y, bus.heat) annotation (Line(
      points={{-31,0},{-60,0},{-60,-100},{0,-100}},
      color={0,0,127}, smooth=Smooth.None));
end ExpandablePIControl;

강조 표시된 줄을 다시 확인해보겠습니다.이러한 connect 문은 암시적으로 heat 및 temperature 신호를 bus 커넥터에 추가할 뿐만 아니라 이 이름이 센서 및 액추에이터 모델에서 예상하는 이름과 일치 합니다.

이러한 모든 하위 시스템을 함께 가져오면 시스템에 대한 다음 다이어그램을 얻을 수 있습니다.

시스템 모델의 소스 코드는 매우 간단합니다.

within ModelicaByExample.Architectures.ThermalControl.Examples;
model OnOffVariant "Variation with on-off control"
  extends ExpandableModel(
    redeclare replaceable
      Implementations.OnOffActuator actuator(heating_capacity=500),
    redeclare replaceable
      Implementations.OnOffControl controller(setpoint=300));
end OnOffVariant;

그러나 이러한 모델에는 여전히 한 가지 문제가 남아 있으며, 용광로의 듀티 사이클을 보면 더 명확하게 볼 수 있습니다.

이것은 이전 섹션에서 설명했던 히스테리시스와 정확히 동일한 문제입니다. 용광로가 지속적으로 켜지고 꺼지는 것을 보는 것은 제어 전략에 히스테리시스가 없다는 사실입니다.히스테리시스를 추가하면 컨트롤러 모델은 다음과 같습니다.

다른 것은 변경되지 않았습니다.동일한 센서 및 액추에이터 모델을 사용할 것이며, 이것이 여전히 뱅뱅 컨트롤러이기 때문에 동일한 버스 신호를 사용합니다.따라서 시스템 수준 모델(OnOffVariant 모델과 비교하여)의 유일한 변경 사항은 다른 컨트롤러 모델을 사용하는 것입니다.보시다시피 모델리카의 이러한 구성 관리 기능은 시스템 수준 모델에서 구성 선택을 전달하는 훌륭한 작업을 수행합니다.

within ModelicaByExample.Architectures.ThermalControl.Examples;
model HysteresisVariant "Using on-off controller with hysteresis"
  extends OnOffVariant(redeclare Implementations.OnOffControl_WithHysteresis
      controller(setpoint=300, bandwidth=1));
end HysteresisVariant;

히스테리시스 제어를 사용하여 시뮬레이션한 결과는 다음과 같습니다.

그러나 가장 중요한 차이점은 히스테리시스가 이전 뱅뱅 컨트롤러에서 본 것과 같은 종류의 채터링으로 이어지지 않는다는 사실입니다.

결론(Conclusion)¶

이것은 모델리카의 구성 관리 기능을 사용하여 시스템 모델 구축에 아키텍처 기반 접근 방식을 취하는 방법에 대한 두 번째 예입니다.이 아키텍처 접근 방식은 분석이 필요한 동일한 아키텍처의 변형이 많을 때 매우 유용합니다.``redeclare`` 기능을 사용하면 각 하위 시스템에 대한 대체 설계를 쉽게 대체하거나 주어진 엔지니어링 분석에 필요한 대로 주어진 하위 시스템에서 더 많거나 적은 세부 사항을 고려할 수 있습니다.

이 특정 예제에서 확장형 커넥터가 표준 커넥터보다 더 큰 유연성을 제공할 수 있는 방법을 보았습니다.그러나 모델리카컴파일러가 일반적으로 수행하는 자료형 검사가 덜 엄격하기 때문에 약간의 위험도 따릅니다.