#
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example v0.3.6\n"
"Report-Msgid-Bugs-To: mail@modelica.co.kr\n"
"POT-Creation-Date: 2023-01-28 22:37+0000\n"
"PO-Revision-Date: 2023-03-12 22:37+0000\n"
"Last-Translator: Baek Youngjin, mail@modelica.co.kr / Ha HyeonSu, <iloveyou934671@gmail.com>\n"
"Language-Team: modelica.co.kr <mail@modelica.co.k>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.6.0\n"


#: ../../source/behavior/functions/controller.rst:4
msgid "Software-in-the-Loop Controller"
msgstr ""
"software-in-the-Loop 제어기(Software-in-the-Loop Controller)"

#: ../../source/behavior/functions/controller.rst:6
msgid ""
"In the previous :ref:`interpolation` example, we saw external C functions"
" could be used to manage and interpolate data.  In this section, we will "
"explore how to integrate C code for an embedded controller into a "
"Modelica model."
msgstr ""
"이전 :ref:`interpolation` 예제에서 외부 C 함수를 사용하여 데이터를 관리하고 보간할 수 있음을 확인했으며,"
"이 섹션에서는 임베디드 컨트롤러용 C 코드를 모델리카 모델에 통합하는 방법을 살펴보겠습니다."


#: ../../source/behavior/functions/controller.rst:11
msgid ""
"When building mathematical models of physical systems in Modelica, it is "
"sometimes useful to integrate (external) control strategies into these "
"models.  In many cases, these strategies exist as C code generated for "
"use with an embedded controller.  This example revisits the topic of "
":ref:`hysteresis`, but with an interesting twist.  Instead of "
"implementing the hysteresis behavior in Modelica using discrete states, "
"we will implement it in an external C function.  Although this example is"
" extremely simple, it demonstrates all the essential steps necessary to "
"integrate external control strategies."
msgstr ""
"(외부) 제어를 위한 동작 방법(strategies)을 통합하여 물리적 시스템의 수학적 모델을 모델리카로 구현하는 것이 때때로 유용합니다."
"왜냐하면, 대부분의 경우 이러한 동작 방법은 임베디드 컨트롤러와 함께 사용하기 위해 생성된 C 코드로 존재하기 때문 입니다."
"이 예제는 이전에 다룬 :ref:`hysteresis` 주제를 다시 살펴보겠지만, "
"불연속 상태를 사용하여 모델리카에서 히스테리시스 동작을 구현하는 대신 외부 C 함수에서 구현하겠습니다."
"이 예제는 매우 간단하지만 외부 제어를 위한 동작 방법을 통합하는 데 필요한 모든 필수적인 과정을 보여줍니다."


#: ../../source/behavior/functions/controller.rst:22
msgid "Physical Model"
msgstr ""
"물리적 모델(Physical Model)"

#: ../../source/behavior/functions/controller.rst:24
msgid ""
"Let's start by looking at our \"physical model\".  In this case, it is "
"essentially just a reimplementation of the model we created previously "
"during our discussion on :ref:`hysteresis`.  Our revised implementation "
"looks like this:"
msgstr ""
"이전에 보여줬던 "물리적 모델"부터 살펴보겠습니다."
"이 경우, 본질적으로 :ref:`hysteresis` 에 대해 논의하는 동안 이전에 생성한 모델을 다시 구현한 것과 같습니다."
"수정된 구현은 다음과 같습니다."


#: ../../source/behavior/functions/controller.rst:33
msgid "Let's take a closer look at the ``equation`` section:"
msgstr ""
"``equation`` 섹션을 자세히 살펴보겠습니다."

#: ../../source/behavior/functions/controller.rst:39
msgid ""
"The function ``computeHeat`` is called every 10 milliseconds to determine"
" the amount of heat to be used.  As we will see in a moment, the "
"controller implements a \"bang-bang\" control strategy.  That means it "
"flips between zero heat generation and full heat generation.  As we saw "
"in our previous discussion on :ref:`hysteresis`, this kind of approach "
"can lead to \"chattering\".  For that reason, we put the calculation of "
"``Q`` inside a ``when`` statement that is executed every 10 milliseconds."
"  This 10 millisecond interval is essentially implementing the behavior "
"of what is normally called a \"scheduler\" which decides when different "
"control strategies are executed."
msgstr ""
"``computeHeat`` 함수는 사용할 열의 양을 결정하기 위해 10밀리초마다 호출됩니다. "
"잠시 후에 살펴보겠지만 "bang-bang" 제어 방법, 즉 발열 이 없는 상태(제로)와 완전 발열 사이를 전환하도록 컨트롤러를 구현합니다."
":ref:`hysteresis` 에 대한 이전 논의에서 보았듯이 이러한 종류의 접근 방식은 "채터링"으로 이어질 수 있습니다."
"그런 이유로  10밀리초마다 실행되는 ``when`` 문 안에 ``Q`` 계산을 넣습니다. "
"이 10밀리초 간격은 본질적으로 다른 제어 상태에대한 절환 시점을 결정하는 (일반적으로 "스케줄러"라고 하는) 동작을 구현합니다."


#: ../../source/behavior/functions/controller.rst:51
msgid "Embedded Control Strategy"
msgstr ""
"임베디드 제어 구현 방법(Embedded Control Strategy)"

#: ../../source/behavior/functions/controller.rst:53
msgid ""
"The Modelica function ``computeHeat`` used to determine how much heat "
"should be applied to the system at any given time is implemented as:"
msgstr ""
"주어진 시간 동안 시스템에 열을 얼마나 적용해야 하는지 결정하는 모델리카 함수인 ``computeHeat`` 는 다음과 같이 구현합니다."

#: ../../source/behavior/functions/controller.rst:60
msgid ""
"Note the presence of the ``external`` keyword.  This time, however, we "
"don't see the name of the external C function like we did in the previous"
" examples.  This means that the external C function has exactly the same "
"name and arguments as its Modelica counterpart. Looking at the source "
"code for the C function, we see that is the case:"
msgstr ""
"이번에는 이전 예제에서와 같이 외부 C 함수의 이름이 ``external`` 키워드 부분에 없는데,"
"이것은 외부 C 함수가 모델리카 대응 함수와 정확히 동일한 이름과 인수를 가짐을 의미합니다. "
"C 함수의 소스 코드를 보면 다음과 같은 경우임을 알 수 있습니다."


#: ../../source/behavior/functions/controller.rst:70
msgid ""
"In other words, we can save ourselves the trouble of specifying how the "
"input and output arguments of our Modelica function map to those of the "
"underlying C function by defining them in such a way that no mapping is "
"truly necessary."
msgstr ""
"즉, 매핑이 실제로 필요하지 않은 방식으로 정의함으로써 모델리카 함수의 입력 및 출력 인수가 기본 C 함수의 인수에 매핑되는 방식을 지정하는 수고를 덜 수 있습니다."

#: ../../source/behavior/functions/controller.rst:75
msgid ""
"Note the presence of the ``static`` variable ``state`` in the C "
"implementation of ``computeHeat``.  The use of the ``static`` keyword "
"here indicates that the value of the variable ``state`` is preserved from"
" one invocation of ``computeHeat`` to another.  This kind of variable is "
"quite common in embedded control strategies because they need to preserve"
" information from one invocation of the scheduler to the next (*e.g.,* to"
" implement hysteresis control, as we see here)."
msgstr ""
"``computeHeat`` 의 C 구현에 ``static`` 변수 ``state`` 가 있는데,"
"여기에서 ``static`` 키워드를 사용한다는 것은 ``state`` 변수의 값이 ``computeHeat`` 호출에서 다음 호출로 유지된다는 것을 나타냅니다. "
"이러한 종류의 변수는 스케줄러의 한 호출에서 다음 호출까지 정보를 보존해야 하기 때문에 임베디드 제어 방법에서 매우 일반적으로 사용합니다.(*예:* 여기에서 볼 수 있듯이 히스테리시스 제어를 구현하기 위해)."


#: ../../source/behavior/functions/controller.rst:85
msgid ""
"The presence of this ``static`` variable is a significant problem because"
" it means that the function ``computeHeat`` can return **different "
"results for the same input arguments**.  Mathematically speaking, this is"
" not a true mathematical function since a mathematical function can only "
"depend on its input arguments.  In computer science, we say such a "
"function is \"impure\".  This means that each invocation of the function "
"changes some internal memory or variable which affects that value "
"returned by the function."
msgstr ""
"이 ``static`` 변수의 존재는 ``computeHeat`` 함수가 **동일한 입력 인수에 대해 다른 결과** 를 반환할 수 있음을 의미하기 때문에 중요한 문제입니다."
"함수가 입력 인수에만 의존 하는 것은 수학적으로 표현할 수 있는데, 이것은 진정한 의미에서 수학 함수가 아닙니다."
"컴퓨터 과학에서는 그러한 함수를 "순수하지 않다(impure)"고 말합니다. 즉, 함수를 호출할 때마다 일부 내부 메모리 또는 함수가 반환하는 값에 영향을 주는 변수가 변경되는 것 입니다."


#: ../../source/behavior/functions/controller.rst:94
msgid ""
"Given that such impurity is implemented in embedded control strategies "
"**by design**, we need to be careful when using them in a mathematically "
"oriented environment like Modelica.  This is because the Modelica "
"compiler assumes, by default, that all functions are pure and side effect"
" free and the presence of impurity or side effects can result in very "
"inefficient simulations, at best, or completely erroneous results, at "
"worst."
msgstr ""
"**설계에 따라** 임베디드 제어 방법을 구현하기 위해 이렇게 순수하지 않은 것도 사용해야 할 때, 모델리카와 같은 수학 지향 환경에서는 주의해야 합니다. "
"모델리카 컴파일러는 기본적으로 모든 함수가 순수하고 다른 영향(side effect)이 없다고 가정하고 있습니다. "
"만약 순수하지 않은 것이나 다른 영향을 줄 수 있는 것의 경우 매우 비효율적인 시뮬레이션 또는 최악의 경우 완전히 잘못된 결과를 초래할 수 있다고 가정하기 때문입니다."


#: ../../source/behavior/functions/controller.rst:102
msgid ""
"These problems occur because the underlying solvers must compute many "
"\"candidate\" solutions before they compute the \"real\" solution.  If "
"generating candidate solutions requires the solver to invoke functions "
"with side effects, the solver will be unable to anticipate the effects "
"triggered by the changes to variables it is not aware of."
msgstr ""
"이러한 문제는 기본 솔버가 "실제" 해를 계산하기 전에 많은 "후보(candidate)" 해를 계산해야 하기 때문에 발생합니다. "
"후보 해를 생성하기 위해 솔버가 다른 영향이 있는 함수를 호출해야 하는 경우 솔버는 예상하지 못하는 변수의 변경으로 인해 트리거되는 효과를 예상할 수 없습니다."


#: ../../source/behavior/functions/controller.rst:108
msgid ""
"It is for precisely this reason that the ``impure`` qualifier is applied "
"to the definition of ``computeHeat``:"
msgstr ""
"``computeHeat`` 정의에 ``impure`` 한정자가 적용되는 것은 바로 이러한 이유 때문입니다."

#: ../../source/behavior/functions/controller.rst:115
msgid ""
"This informs the Modelica compiler that this function **has side effects "
"or returns a result that depends on something other than its inputs** and"
" that it **should not** be invoked when generating candidate solutions.  "
"At first, this seems like it would completely prohibit calling the "
"function, but that isn't the case.  Recall our integration of the control"
" strategy:"
msgstr ""
"이것은 이 함수에 **다른 영향을 주는 부분이 있거나 입력 이외의 항목에 의존하는 결과를 반환** 하면 안되고, 후보 해를 생성할 때에 **호출해서는 안 됨** 을 모델리카 컴파일러에게 알립니다."
"처음에는 함수 호출을 완전히 금지하는 것처럼 보이겠지만 그렇지 않습니다."
"제어 방법을 구현하는 것을 다시한번 생각해 보겠습니다."


#: ../../source/behavior/functions/controller.rst:125
msgid ""
"In particular, note that ``computeHeat`` is invoked only within the "
"``when`` statement and not as part of a \"continuous\" equation.  As a "
"result, we can be certain that ``computeHeat`` will only be invoked in "
"response to an event but not when evaluating candidate solutions for the "
"continuous variables."
msgstr ""
"특히 ``computeHeat`` 는 ``when`` 문 내에서만 호출되며 "연속" 방정식의 일부로는 호출되지 않습니다."
"결과적으로 ``computeHeat`` 가 이벤트에 대한 응답으로만 호출되고 연속 변수에 대한 후보 해를 해석할 때는 호출되지 않는다는 것을 확신할 수 있습니다."
 
#: ../../source/behavior/functions/controller.rst:132
msgid "Results"
msgstr ""
"결과(Results)"

#: ../../source/behavior/functions/controller.rst:134
msgid ""
"In the C function ``computeHeat``, we see that these two statements "
"implement a +/- 2 degree deadband around the setpoint:"
msgstr ""
"C 함수 ``computeHeat`` 에서 아래 두 문장이 설정 온도 주위에 +/- 2도만큼 감지되지 않는 영역을 구현한 것을 알 수 있습니다."

#: ../../source/behavior/functions/controller.rst:141
msgid ""
"It is this functionality that prevents chattering and which can be "
"clearly observed in the simulated results for our example:"
msgstr ""
"예제의 시뮬레이션 결과를 통해 채터링을 방지했다는 것을 명확히 알 수 있습니다."

#~ msgid ""
#~ "In particular, note that ``computeHeat`` "
#~ "is invoked only within the ``when`` "
#~ "statement and not as part of a "
#~ "\"continuous\" equation.  As a result, "
#~ "we can be certain that ``computeHeat``"
#~ " will only be invoked in response "
#~ "to an event and in evaluating "
#~ "candidate solutions for the continuous "
#~ "variables."
#~ msgstr ""

#~ msgid "side effects"
#~ msgstr ""

