하위 시스템 인터페이스(Subsystem Interface)¶

이 장에서는 구성 요소 모델을 재사용 가능한 하위 시스템으로 구성하는 방법에 중점을 두었는데, 수많은 예제에서 보았듯이 나타나는 공통 패턴이 있습니다. 이 패턴을 더 잘 이해하기 위해 하위 시스템 모델의 다양한 측면을 검토해 보겠습니다.

파라미터(Parameters)¶

일반적으로 하위 시스템의 파라미터는 public 이어야 하고,일반적으로 model 또는 block 정의의 모든 선언은 protected 키워드 뒤에 오지 않는 한 공개됩니다. 만약 protected 키워드 뒤에 오는 경우라고 해도, public 키워드를 추가하고 그 뒤에 선언을 배치하여 무언가를 public 으로 선언할 수 있습니다.다시 말해서 아래와 같이 표현 가능 합니다.

model PublicAndProtected
  Real x; // This is public (because that is the default)
protected
  Real y1; // This is protected
  Real y2; // This is *also* protected
public
  Real z1; // This is public
  Real z2; // This is *also* public
equation
  // ...
end PublicAndProtected;

이 장의 예제에서는 정의의 시작 부분(여기서 기본적으로 public 임) 또는 명시적으로 public 으로 표시된 선언 모음에서 파라미터를 보는 것이 일반적이었습니다.

분명히 파라미터는 공개되어 하위 시스템의 사용자가 액세스할 수 있습니다. 수정(Modifications) 및 전파(Propagation) 에 대해 뒤에서 논의 할 때 파라미터의 값이 어떻게 하위 수준 구성요소로 캐스케이드되어야 하는지 알게 될 것입니다. 그러나 지금은 파라미터 선언이 하위 시스템 패턴의 일부임을 이해 하는 것이 중요합니다.

커넥터(Connectors)¶

어떤 의미에서 커넥터는 하위 시스템과 시스템 모델을 구분하는 것입니다.시스템 모델은 완전하고 시뮬레이트할 준비가 된 것이므로 외부의 영향을 받지 않기 때문에 커넥터가 없습니다.하위 시스템은 구성 요소(및 궁극적으로 방정식)의 대규모 계층 구조를 캡슐화할 수 있습니다.그러나 커넥터가 포함되어 있다는 사실은 실제로 일부 더 큰 시스템의 일부로 사용하기 위한 것임을 나타냅니다.또한 이 장의 예제에서 보았듯이 이러한 커넥터는 연결 대상이므로 public 이어야 합니다.

계층적 결합(Hierarchical Connections)¶

하위 시스템은 일반적으로 구성 요소 또는 다른 하위 시스템으로만 구성되기 때문에 해당 하위 시스템과의 모든 물리적 상호 작용은 일반적으로 일부 중첩된 구성 요소 또는 하위 시스템으로 리디렉션됩니다.이 장에서 하위 시스템 경계에 있는 커넥터가 실제로 내부 커넥터에 대한 "프록시" 역할을 하는 패턴을 여러 번 보았습니다. 이에 대한 간단한 예제는 GearWithBacklash 모델에서 볼 수 있습니다:

  connect(flange_a, inertia_a.flange_a)

이 connect 문은 서브시스템에 속한 커넥터 인스턴스인 flange_a 와 하위 구성요소인 inertia_a 에 속한 커넥터 인스턴스인 inertia_a.flange_a 를 연결합니다. 이는 서브시스템 모델의 일반적인 패턴이며 connect 문에 명명된 커넥터 중 하나는 "." 을 포함하고 다른 하나는 포함하지 않기 때문에 쉽게 인식할 수 있습니다.내부 구성 요소를 다른 내부 구성 요소에 직접 연결하는 모든 "내부" 연결은 connect 문에서 명명된 커넥터 모두에 대해 "."를 갖습니다. 예를 들면 아래와 같습니다.

  connect(idealGear.flange_b, inertia_b.flange_a)

계층적 연결을 위한 방정식 생성(Equation Generation for Hierarchical Connections)¶

예를 들어 이전에 다루었던 비인과적 커넥터(Acausal Connections) 에서 다룬 것 처럼, 이 책에서 flow 변수에 대한 부호 규약은 양수 값인 flow 변수가 구성 요소 또는 하위 시스템으로의 흐름을 나타냅니다. 동시에 system-connections이 0으로 설정된 연결에서 해당하는 모든 flow 변수를 합산하는 방정식을 생성한다는 점도 지적했습니다.

그러나 계층적 하위 시스템 정의를 처리할 때 이 규칙이 수정됩니다. 하위 시스템의 경우 flow 변수에 대한 부호 규칙은 그대로 유지됩니다. 따라서 커넥터의 flow 변수에 대한 양수 값은 여전히 해당 구성 요소로의 보존된 양의 흐름을 나타냅니다.그리고 여전히 연결 집합의 각 flow 변수에 대해 보존 방정식이 생성됩니다. 그러나 그 보존 방정식에서 내부 구성 요소에 속한 커넥터의 flow 변수에 대한 부호는 하위 시스템 자체에 속한 커넥터의 flow 변수와 반대 부호를 갖습니다.

이것이 의미하는 바를 이해하기 위해 GearWithBacklash 모델의 다음 두 connect 문을 살펴보겠습니다.

  connect(flange_a, inertia_a.flange_a)
    annotation ...
  connect(idealGear.flange_b, inertia_b.flange_a)
    annotation ...

이 방정식에서 다음 두 연결 세트를 얻습니다.

연결 세트 #1: flange_a, inertia_a.flange_a

연결 세트 #2: idealGear.flange_b, inertia_b.flange_a

이러한 각 연결 세트에는 flow 변수인 tau 가 있습니다.앞에서 설명한 연결(Connections) 에 대한 규칙을 사용하면 이러한 커넥터의 flow 변수에 대해 다음 두 방정식이 생성될 것으로 예상할 수 있습니다.

flange_a.tau + inertia_a.flange_a.tau = 0;
idealGear.flange_b.tau + inertia_b.flange_a = 0;

그러나 시스템 연결에 대한 이전 논의에서 모든 구성 요소는 동일한 계층적 수준(즉, idealGear.flange_b 및 inertia_b.flange_a )에 있었는데, 하위 시스템 모델의 경우 항상 그런 것은 아닙니다. 그리고 조금 전에 설명한 것처럼 연결이 서로 다른 수준에 있는 경우 서로 다른 수준에서 기여도에 대한 부호 차이를 도입해야 하는 것 입니다. 이를 고려하여 생성될 실제 방정식 은 다음과 같습니다.

-flange_a.tau + inertia_a.flange_a.tau = 0;
idealGear.flange_b.tau + inertia_b.flange_a = 0;

flange_a.tau 앞에 있는 빼기 기호에 유의 해야 합니다.``flange_a`` 는 inertia_a.flange_a 의 프록시 역할을 한다는 것을 기억해보면, flange_a.tau 의 부호를 변경하여 위의 첫 번째 방정식을 다음과 같이 변환할 수 있습니다.

inertia_a.flange_a.tau = flange_a.tau;

즉, flange_a.tau 에 부호 변경을 도입함으로써 flange_a 를 통해 유입되는 모든 보존된 양 또한 inertia_a.flange_a 로 유입됩니다. 이것이 바로 이러한 종류의 "프록시" 관계에서 기대하는 것입니다.

구현(Implementation)¶

하위 시스템 모델은 일반적으로 구성 요소 모음을 둘러싼 래퍼입니다. 이 섹션에서 이미 논의한 것처럼 하위 시스템의 사용자가 상호 작용하는 방식이기 때문에 하위 시스템에 의해 노출된 파라미터와 커넥터는 public 입니다.

서브시스템의 실제 내부 세부사항은 서브시스템의 구현을 나타냅니다. 이 구현은 일반적으로 하위 시스템의 커넥터에 연결된 하나 이상의 커넥터와 함께 연결된 구성 요소 및 기타 하위 시스템의 모음입니다.

일반적으로 이러한 구현 세부 정보는 하위 시스템의 최종 사용자에게 가장 잘 숨겨집니다. 이를 달성하기 위해 하위 시스템의 모든 비 parameter 선언은 일반적으로 protected 으로 표시됩니다.이렇게 하는 데는 두 가지 주요 이유가 있습니다. 첫째, 하위 시스템 모델 사용자에게 구현 세부 정보를 숨깁니다. 이는 인터페이스를 파라미터 및 커넥터로 단순화하는 효과가 있으며 사용자가 실제로 알아야 할 사항과 알 필요가 없는(또는 알 필요가 없는) 사항이 혼합되는 것을 방지합니다. 구현 세부 사항을 protected 하는 또 다른 이유는 향후 구현을 개선하거나 리팩토링할 수 있는 연성을 제공하기 위해서입니다. 사용자가 구현 세부 정보를 참조하도록 허용되면 이는 사용자가 (의도하지 않게) 해당 구현 세부 정보에 의존 하게 됨을 의미합니다. 결과적으로 나중에 의도하지 않게 변경되면 최종 사용자의 모델이 손상됩니다.