# 
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example 0.2.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-04-14 10:14-0400\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../../source/components/architectures/sensor_comparison_ad.rst:4
msgid "Architecture Driven Approach"
msgstr "架构驱动方法"

#: ../../source/components/architectures/sensor_comparison_ad.rst:6
msgid ""
"So far in this section, we started with a flat approach and gradually "
"adapted it to use the architectural features of Modelica.  Let's start to "
"build out our system from the top down using an architectural approach where"
" we define the structure of our system first and then add specific subsystem"
" implementations after that."
msgstr ""
"到目前为止，我们从扁平结构的建模方法为起点，逐渐在模型里使用Modelica的架构特性。\ "
"我们会开始从上往下地用架构方法去建立系统。\ "
"我们首先定义系统的结构，然后添加特定的子系统实现。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:13
msgid "Interfaces"
msgstr "接口"

#: ../../source/components/architectures/sensor_comparison_ad.rst:15
msgid ""
"We'd like to start by building our top level architecture model that "
"describes the subsystems we have and how they are connected.  However, we "
"need **something** to put into this architecture to represent our "
"subsystems.  We don't (yet) want to get down to the job of creating "
"implementations for all of our subsystem models.  So where do we start?"
msgstr ""
"我们希望首先建立顶层的架构模型，从而描述存在的子系统以及它们之间的连接。\ "
"但是，我们需要把\\ **一些内容**\\ "
"放入这个架构以表示我们的子系统。\ "
"我们（暂时）不要直接为所有的子系统模型的建立实现。\ "
"所以，我们从哪里开始？"

#: ../../source/components/architectures/sensor_comparison_ad.rst:22
msgid ""
"The answer is that we start by describing the interfaces of our subsystems."
"  Remember, from earlier in this section, that redeclarations depend on a "
"constraining type and that all implementations must conform to that "
"constraining type?  Well an interface is essentially a formal definition of "
"the constraining type (*i.e.,* the expected public interface) but without "
"any implementation details.  Since it has no implementation details (*i.e.,*"
" no equations or sub-components), it will end up being a ``partial`` model."
"  But that's fine for our purposes."
msgstr ""
"答案是，我们会首先描述子系统的接口模型。\ "
"还记得么?从本节前面里，重声明取决于约束类型，而且所有的实现必须和该约束类型具有一致性。\ "
"其实接口模型基本上是约束类型的正式定义（即预期的公有接口）。\ "
"不过接口模型并不包括实现细节。\ "
"既然如此（即没有公式或子组件），因此接口模型是\\"
" ``partial``\\ 模型。\ "
"但是，对于我们的目的这足够了。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:32
msgid ""
"Let's start by considering the interface for our ``sensor`` subsystem.  We "
"have already discussed the public interface in detail. Here is a Modelica "
"definition and icon for that interface:"
msgstr "让我们开始考虑\\ ``sensor``\\ 子系统的接口模型。\ "
"我们已经详细讨论了公共接口。\ "
"这是接口模型的Modelica定义以及图标："

#: ../../source/components/architectures/sensor_comparison_ad.rst:44
msgid ""
"A few things to note about this ``model`` definition.  The first is, as we "
"mentioned a moment ago, that this model is ``partial``.  This is because it "
"has connectors but no equations to help solve for the variables on those "
"connectors.  Another thing worth noting is the fact that it contains "
"annotations.  The annotations associated with the connector declarations "
"specify how those connectors should be rendered.  These annotations will be "
"inherited by any model that ``extends`` from this one.  So it is important "
"to choose locations that will make sense across all implementations.  It "
"also includes an ``Icon`` annotation.  This essentially defines a "
"\"backdrop\" for the final implementations icon.  In other words, any model "
"that extends from this model will be able to draw **additional** graphics on"
" top of what is defined by the ``Sensor`` model."
msgstr ""
"这个\\ ``model``\\ 定义有几点需要注意。\ "
"首先，正如我们刚才也提到，这种模型是\\ ``partial``\\  "
"。\ "
"这是因为这种模型仅具有连接器，但没有方程去帮助求解对这些连接器内的变量。\ "
"另外值得注意的一点是，这些模型包含了批注。\ "
"与连接器声明相关的标注说明这些连接器应该以如何形式表现。\ "
"任何从这个\\"
" ``extends``\\ 的模型会继承这些标注。\ "
"所以，连接器的位置必须在所有的实现里都有效。\ "
"It also includes an ``Icon``"
" annotation.模型还包括一个\\ ``Icon``\\ 标注。\ "
"这实际上定义了最终实现的图标的“背景”。\ "
"换句话说，从此模型扩展的模型可以在\\ "
"``Sensor``\\ 模型图标的基础上中定义\\ **额外**\\ 的图形。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:58
msgid ""
"The interface definition for the actuator model is almost identical except "
"that it includes two rotational connectors, one to apply the commanded "
"torque to and the other that handles the reaction torque. If, for example, "
"our actuator model were an electric motor, the former would be the connector"
" for the rotor and the latter would be the connector for the stator.  "
"Otherwise, it is very similar to our ``Sensor`` definition:"
msgstr ""
"而执行器模型的接口定义唯一不同之处在于，它包括了两个旋转连接器。\ "
"其中一个用以施加指令转矩，另一个则用以处理反作用转矩。\ "
"倘若例如我们的执行器模型为电动马达，前者就是在转子的连接器，而后者是定子的连接器。\ "
"除此以外，此模型非常类似于我们\\"
" ``Sensor``\\ 定义："

#: ../../source/components/architectures/sensor_comparison_ad.rst:74
msgid ""
"The ``Plant`` interface has three rotational connectors.  One for the "
"\"input\" side (where the actuator will be connected), one for the "
"\"output\" side (where the sensor will be connected) and the last one for "
"the \"support\" side (so it can be \"mounted\" to something):"
msgstr ""
"\\ ``Plant``\\ "
"接口有三个旋转连接器。\ "
"一个在“输入”侧（与执行器相连接）。\ "
"一个在“输出”侧（与传感器相连接）。\ "
"而最后一个用于“支持”侧（用以“固定”在其他物体上）："

#: ../../source/components/architectures/sensor_comparison_ad.rst:87
msgid "Finally, we have the ``Controller`` interface definition:"
msgstr "最后，我们有\\ ``Controller``\\ 接口定义："

#: ../../source/components/architectures/sensor_comparison_ad.rst:98
msgid ""
"Regardless of how it is implemented (*e.g.,* proportional control, PID "
"control), the ``Controller`` will require an input connector for the desired"
" setpoint, ``setpoint``, another input connector for the measured speed, "
"``measured`` and an output connector to send the commanded torque, "
"``command`` to the actuator."
msgstr ""
"无论控制器是如何实现的（如比例控制， PID控制），\\ ``Controller``\\ 必须有目标值\\ ``setpoint``\\ "
"的输入连接器、另一个用于测速的输入连接器\\ ``measured``\\ 和用以发送指令转矩\\ ``command``\\ 到执行器的输出连接器。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:105
msgid "Architecture"
msgstr "架构"

#: ../../source/components/architectures/sensor_comparison_ad.rst:107
msgid ""
"With the interfaces specified, our architecture model can be written as "
"follows:"
msgstr "指定了接口后，我们的架构模型可以写成如下形式："

#: ../../source/components/architectures/sensor_comparison_ad.rst:113
msgid ""
"We can see from the Modelica code that our architecture consists of four "
"``replaceable`` subsystems: ``plant``, ``actuator``, ``sensor`` and "
"``setpoint``.  Each of these declarations includes only one type. As we "
"learned earlier in this section, that type will be used as both the default "
"type and the constraining type (which is what we want). This model also "
"includes all the connections between the subsystems. In this way, it is a "
"complete description of the subsystems and the connections between them.  "
"**All that is missing are the implementation choices for each subsystem**."
msgstr ""
"我们可以从上述Modelica代码看出，架构由四个\\ ``replaceable``\\ 子系统组成： \ "
"\\ ``plant``\\  ， \\ ``actuator``\\  ， \\ ``sensor``\\ 和\\ ``setpoint``\\  。\ "
"所有这些声明只包括一种类型。\ "
"正如我们先前在本节了解到的，该类型将（如我们所望地）同时用作默认类型以及约束类型。\ "
"此模型还包括子系统之间的所有连接。\ "
"这样一来，模型完整描述了子系统以及其之间的联系。\ "
"\\"
" **万事俱备，唯一缺少的就是去选择每个子系统的实现了**\\ 。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:123
msgid ""
"Note that our ``SystemArchitecture`` model is, itself, ``partial``. This is "
"precisely because the default types for all the subsystems are ``partial`` "
"and we have not yet specified implementations.  In other words, this model "
"has no implementation so it cannot (yet) be simulated.  We indicate this by "
"marking it as ``partial``."
msgstr ""
"请注意，\\ ``SystemArchitecture``\\ 模型本身是\\ ``partial``\\  。\ "
"这正是因为所有子系统的默认类型均为\\ "
"``partial``\\ ，而我们还没有指定模型的实现。\ "
"换句话说，模型不包含实现，因此（还）不能进行模拟。\ "
"为表明这一点，我们标记模型为\\ "
"``partial``\\ 。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:129
msgid ""
"Like our interface specifications, this model also contains graphical "
"annotations.  This is because, in addition to specifying the subsystems, we "
"are also specifying the locations of the subsystems and the paths of the "
"connections.  When rendered, our system architecture looks like this:"
msgstr "正如我们的接口模型，这个模型也包含图形标注。\ "
"这是因为我们不但指定了子系统，还指定了子系统的位置和连接的路径。\ "
"我们的系统架构显式的效果如下："

#: ../../source/components/architectures/sensor_comparison_ad.rst:141
msgid "Implementations"
msgstr "实现"

#: ../../source/components/architectures/sensor_comparison_ad.rst:143
msgid ""
"Now that we have the interfaces and the architecture, we need to create some"
" implementations that we can then \"inject\" into the architecture.  These "
"implementations can choose to either inherit from the existing interfaces "
"(thus avoiding redundant code) or simply ensure that the declarations in the"
" implementation make it plug-compatible with the interface.  Obviously, "
"inheriting from the interface is, in general, a much better approach.  But "
"we have included examples of both simply to demonstrate that it isn't "
"strictly required to inherit from the interface."
msgstr ""
"现在我们有了接口和架构，我们必须创建一些实现，用以“注入”到架构中。\ "
"这些实现可以选择从现有的接口继承（从而避免冗余代码），或是仅确保在实现内的声明与接口插件兼容。\ "
"显然在一般情况下从接口继承是一个更好的方法。\ "
"但我们同时介绍这两种方法的例子，用以证明从接口继承并非必须。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:153
msgid ""
"Here are some of the implementations we'll be using over the remainder of "
"this section.  It is important to keep in mind that although these models "
"include many lines of Modelica source code, they can be very quickly "
"implemented in a graphical Modelica environment (*i.e.,* one does not "
"normally type in such models by hand)."
msgstr ""
"这里有一些我们将在本节剩余部分使用的实现。\ "
"请注意，尽管这些模型包括了多行的Modelica源代码，代码可以在图形化的Modelica环境内迅速生成（即通常不会手工键入这种模型代码）。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:160
msgid "Plant Models"
msgstr "受控对象模型"

#: ../../source/components/architectures/sensor_comparison_ad.rst:167
msgid "Actuator Models"
msgstr "执行器模型"

#: ../../source/components/architectures/sensor_comparison_ad.rst:178
msgid "Controller Models"
msgstr "控制器模型"

#: ../../source/components/architectures/sensor_comparison_ad.rst:189
msgid "Sensor Models"
msgstr "传感器模型"

#: ../../source/components/architectures/sensor_comparison_ad.rst:200
msgid "Variations"
msgstr "变体"

#: ../../source/components/architectures/sensor_comparison_ad.rst:203
msgid "Baseline Configuration"
msgstr "基准配置"

#: ../../source/components/architectures/sensor_comparison_ad.rst:205
msgid ""
"With these implementations at hand, we can create a number of different "
"implementations of our complete system.  For example, to implement the "
"behavior of our original ``FlatSystem`` model, we simply extend from the "
"``SystemArchitecture`` model and redeclare each of the subsystems so that "
"the implementations match the subsystem implementations in ``FlatSystem``, "
"*i.e.,*"
msgstr ""
"有了这些实现，我们可以创建完整的系统的一些不同实现。\ "
"举个例子，为了实现我们最初的\\ ``FlatSystem``\\ 模型的行为，\ "
"我们可以直接扩展\\ ``SystemArchitecture``\\ 模型，\ "
"然后将每个子系统重新声明为与\\ ``FlatSystem``\\ 对应的子系统实现，\\ *即：*\\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:215
msgid ""
"Here we see the real power of Modelica for specifying configurations. Note "
"how each redeclaration includes the ``replaceable`` qualifier. By doing so, "
"we ensure that subsequent redeclarations are possible."
msgstr ""
"在这里，我们看到的Modelica指定配置的能力。\ "
"注意了每个重声明都包括了\\ ``replaceable``\\ 限定词。\ "
"这样做可以确保其他模型也可以继续重声明该部件。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:220
msgid ""
"If we had wanted our ``SystemArchitecture`` model to specify these "
"implementations as the default but still use the interfaces as the "
"constraining types, we could have declared the subsystems in "
"``SystemArchitecture`` as follows:"
msgstr ""
"如果我们希望\\ ``SystemArchitecture``\\ 模型使用上述部件作为默认实现，\ "
"但同时仍使用接口作为约束类型，我们可以将\\ ``SystemArchitecture``\\ 子系统声明如下："

#: ../../source/components/architectures/sensor_comparison_ad.rst:230
msgid "``Variation1``"
msgstr ""

#: ../../source/components/architectures/sensor_comparison_ad.rst:232
msgid ""
"If we wish to create a variation of the ``BaseSystem`` model, we can use "
"inheritance and modifiers to create them, *e.g.,*"
msgstr "如果我们希望创建\\ ``BaseSystem``\\ 模型的变体，可以用继承和修饰词来创建它们，如："

#: ../../source/components/architectures/sensor_comparison_ad.rst:238
msgid ""
"Note how this model extends from ``BaseSystem`` configuration but then "
"changes **only** the ``sensor`` model.  If we simulate this system, we see "
"that the performance matches that of our original :ref:`flat-sensor-system`."
msgstr ""
"请注意如何模型是如何在扩展\\ ``BaseSystem``\\ 配置后，\ "
"\\ **仅仅**\\ 改变\\ ``sensor``\\ 模型的。\ "
"若我们对这个系统进行仿真，性能相当于原来\\ :ref:`flat-sensor-system`\\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:246
msgid ""
"However, if we instead create a configuration with the longer hold time, we "
"find that the system becomes unstable (exactly as it did in the :ref:`flat-"
"sensor-system` as well):"
msgstr ""
"但是，如果相反我们创建一个采样时间更长的配置，\ "
"我们会发现系统变得不稳定（和在\\ :ref:`flat-sensor-system`\\ 内的对应模型完全一样）："

#: ../../source/components/architectures/sensor_comparison_ad.rst:254
msgid "``Variation2``"
msgstr ""

#: ../../source/components/architectures/sensor_comparison_ad.rst:266
msgid "we will get the following simulation results:"
msgstr "我们会得到下面的仿真结果："

#: ../../source/components/architectures/sensor_comparison_ad.rst:277
msgid "Then, we will get even better simulation results:"
msgstr "那么，我们将得到更好的仿真结果："

#: ../../source/components/architectures/sensor_comparison_ad.rst:283
msgid "Conclusion"
msgstr "结论"

#: ../../source/components/architectures/sensor_comparison_ad.rst:285
msgid ""
"This concludes our discussion of this particular architecture.  The key "
"point in this example is that by using architectures, we make it very easy "
"to explore alternative configurations for our system.  But in addition to "
"being easier (in the sense that we are able to do these things very "
"quickly), we are also able to ensure a degree of correctness as well because"
" no additional connecting is required for each configuration.  Instead, the "
"user simply needs to specify which implementation they would like to use for"
" each subsystem and, even then, the Modelica compiler can check to make sure"
" that their choices are plug-compatible with the constraining types used to "
"specify the architecture."
msgstr ""
"我们就此完成了对上述架构的讨论。\ "
"这个例子的重点是，我们可以非常容易地通过用架构探索系统的备选配置。\ "
"但除了易用性外（意思是我们能很快完成这些事情），我们也能够确保一定程度的正确性，因为每个新配置都不需要增加连接。\ "
"相反，用户只需要指定在各个子系统里使用的实现。\ "
"而且在这时，Modelica编译器可以进行检查，以确保用户选择的实现插件兼容于指定架构的限制类型。\ "

#: ../../source/components/architectures/sensor_comparison_ad.rst:256
msgid ""
"Note how, even with an adequate sensor, the controller in our ``Variant1`` "
"configuration seems to be converging to the wrong steady state speed.  This "
"is because we are only using a proportional gain controller.  However, if we"
" extend from the ``Variant1`` model and add a PID controller and a more "
"realistic actuator with limitations on the amount of torque it can supply, "
"*i.e.*,"
msgstr ""
"请注意，即使装有性能足够的传感器，在\\ ``Variant1``\\ "
"配置里控制器似乎收敛到了错误的稳态速度。\ "
"这是因为我们只使用了比例增益控制器。\ "
"但是，如果我们扩展\\ ``Variant1``\\ "
"模型，并添加一个PID控制器和一个更真实的、最大提供转矩量有限的执行器，即："

#: ../../source/components/architectures/sensor_comparison_ad.rst:271
msgid ""
"Furthermore, if we take some time to tune the gains in the PID controller, "
"*i.e.,*"
msgstr "此外，如果用一段时间来调整PID调节器的增益，即："

