Update from modelica/ssp-standard@efc224e

static/docs/main/index.html

@@ -4,7 +4,7 @@
 <meta charset="UTF-8">
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
-<meta name="generator" content="Asciidoctor 2.0.21">
+<meta name="generator" content="Asciidoctor 2.0.22">
 <title>System Structure and Parameterization</title>
 <style>
 /* Asciidoctor default stylesheet | MIT License | http://asciidoctor.org */
@@ -586,8 +586,8 @@
 <div id="header">
 <h1>System Structure and Parameterization</h1>
 <div class="details">
-<span id="revnumber">version 85b03df,</span>
-<span id="revdate">2024-03-16</span>
+<span id="revnumber">version efc224e,</span>
+<span id="revdate">2024-04-26</span>
 </div>
 <div id="toc" class="toc2">
 <div id="toctitle">Contents</div>
@@ -921,7 +921,7 @@ <h2 id="_overview">1. Overview</h2>
 <div class="paragraph">
 <p>SSP can be seen as an extension to the FMI (Functional Mockup Interface) standard [FMI20].
 FMI describes a tool independent standard to exchange single simulation models.
-Using SSP complete systems consisting of multiple interconnected simulation models can be defined with the desired signal flow and also with the wanted parameterization of each single model as well as the parameters for the complete system.
+Using SSP, complete systems consisting of multiple interconnected simulation models can be defined with the desired signal flow and also with the wanted parameterization of each single model as well as the parameters for the complete system.
 This system topology can include hierarchies of sub-systems for proper structuring of the overall system.
 Along the signal flow, unit definitions can be used for automatic unit conversion or unit checking.
 Parameters can be derived from other parameters to be able to introduce dependencies of parameters between different components or to assure consistent use of same values for multiple components where needed.
@@ -983,7 +983,7 @@ <h4 id="_designing_a_simulation_structure">1.2.1. Designing a simulation structu
 During the design phase of a system, a signal dictionary can be a good way to predefine the available signal connections.</p>
 </div>
 <div class="paragraph">
-<p>If the system has global parameters that shall be propagated to multipile components, the definition can also be made at system level.
+<p>If the system has global parameters that shall be propagated to multiple components, the definition can also be made at system level.
 The mapping to the parameters of the components can be realized either using connections or through parameter bindings that can include parameter mappings.</p>
 </div>
 </div>
@@ -998,7 +998,7 @@ <h4 id="_ssp_as_definition_of_component_interfaces_and_parameterization_as_templ
 <p>The implementor of the component can import this SSP file as a template in his authoring tool and directly code the behavior using the defined input signals and the definition of the parameters to calculate the defined output signals.</p>
 </div>
 <div class="paragraph">
-<p>After completion of the implementation the component can be returned as a running entity in an SSP package file for insertion into the complete system structure by the integrator.
+<p>After completion of the implementation, the component can be returned as a running entity in an SSP package file for insertion into the complete system structure by the integrator.
 The integrator can decide whether to merge the components from different sources into one file or use the components as references by using the appropriate mechanisms in SSP to just link to the original SSP files.
 The latter approach has the benefit that the components can be used “untouched” and any “warranty” given by the author of the component is not corrupted.
 Even traceability information can be retained this way.</p>
@@ -1021,7 +1021,7 @@ <h4 id="_ssp_as_particular_instances_of_ready_to_simulate_simulation_systems">1.
 <div class="paragraph">
 <p>After implementation of all components and provisioning of the parameter settings for a particular system everything is in place for running simulations.
 All these entities can be stored in one single SSP package, which can be imported by the executing system for running the simulation.
-Depending on the execution system it might be necessary to define additional settings for the solver or other execution algorithms.
+Depending on the execution system, it might be necessary to define additional settings for the solver or other execution algorithms.
 The core SSP standard does not include these execution-specific settings, but layered standards will be defined to include those settings.</p>
 </div>
 <div class="paragraph">