Misc grammar errors

README.md

@@ -44,7 +44,7 @@ A demo from tool vendors (Akkodis, Altair, AVL, Bosch, dSPACE, PMSF, SYNOPSYS) i
 
 ![AIC Announcemet Speakers FMI](landingpage/AIC_Announcemet_Speaker_Single_FMI.jpg)
 
-Looking forward to meet you in Munich!
+Looking forward to meeting you in Munich!
 More information on the conference: <https://www.asam.net/conferences-events/detail/asam-international-conference-2024/>
 
 ## Repository Structure

Release Checklist.md

@@ -13,11 +13,11 @@ Maintenance also takes place on the created release branch.
 ## Checklist
 The following checklist indicates which points must be taken into account when creating a release:
 
-* [ ] **Document Version:** The `revnumber` and `revdate` fields of the `index.adoc` (see https://github.com/modelica/fmi-ls-bus/blob/main/docs/index.adoc) file needs to be updated accordingly to the specified release version. 
+* [ ] **Document Version:** The `revnumber` and `revdate` fields of the `index.adoc` (see https://github.com/modelica/fmi-ls-bus/blob/main/docs/index.adoc) file needs to be updated accordingly to the specified release version.
 * [ ] **Manifest File Example:** The FMI-LS-BUS manifest file example version shall be updated to the specified release version (see https://github.com/modelica/fmi-ls-bus/blob/main/docs/examples/fmi_ls_bus_manifest_example.xml)
 * [ ] **Manifest Version:** Update fmi-ls-version of the chapter Layered Standard Manifest File to the respective release version.
 * [ ] **MIME Types** Adaptation of the MIME Types (version part), if relevant changes have occurred (see https://modelica.github.io/fmi-ls-bus/main/#low-cut-mime-types).
-An update is necessary if the operations has changed within the new target release.
+An update is necessary if the operations have changed within the new target release.
 * [ ] **Terminal File Examples:** The FMI-LS-BUS terminal file example MIME Type versions shall be updated corresponding to the specified release (see https://github.com/modelica/fmi-ls-bus/blob/main/docs/examples/) if required.
 * [ ] **Remove unsupported Bus Types:** All unsupported buses and MIME Types (see MIME Types chapter) of the respective version (see https://github.com/modelica/fmi-ls-bus/milestones) must be removed before creating the respective release.
 The removal takes place on the created side branch.

docs/1____introduction.adoc

@@ -2,7 +2,7 @@
 
 === Intent of This Document [[introduction-intent-of-this-document]]
 
-Automotive CAN, LIN, FlexRay, CAN FD, CAN XL and Ethernet are network technologies that have been applied successfully over many years by all automotive OEMs world wide.
+Automotive CAN, LIN, FlexRay, CAN FD, CAN XL and Ethernet are network technologies that have been applied successfully over many years by all automotive OEMs worldwide.
 Virtualizing electronic control units (ECUs) and then simulating multiple such virtual ECUs requires connecting them using a virtual version of these network technologies.
 
 This layered standard defines what input and output variables and which FMI 3.0 features are used and how to emulate a transport layer for such network traffic.
@@ -21,7 +21,7 @@ Since the network abstraction layer is protocol-independent, it can also be used
 
 So that this layered standard can be supported in a variety of FMU importers and other types of simulators three possible communication architectures for bus communication are specified:
 
-* Direct Communication: Limited to exactly two FMUs, a common FMU importer that not require any special features for simulating buses, apart from supporting FMI variables, Clocks and terminals can be use to emulate bus communication.
+* Direct Communication: Limited to exactly two FMUs, a common FMU importer that not require any special features for simulating buses, apart from supporting FMI variables, Clocks and terminals can be used to emulate bus communication.
 * Composition with dedicated Bus Simulation FMU: A separate Bus Simulation FMU is used to simulate the specific bus behavior.
 Other FMUs that want to emulate bus communication provide and relate network information via this Bus Simulation FMU.
 This communication architecture can be operated by a common FMU importer and allows complex and detailed bus simulations.

docs/2____common_concepts.adoc

@@ -11,9 +11,9 @@ _[FMUs providing both abstraction layers can deduce from the fmi3Set() and fmi3G
 
 Since network communication is not continuous but time discrete, FMI 3.0 Clocks are used to indicate when signals and/or frames are sent or received.
 All signal and frame variables are clocked variables.
- 
+
 FMI 3.0 terminal definitions in the `terminalsAndIcons.xml` are used to group related variables and present a comfortable opportunity to connect different FMUs between each other.
-Terminal definitions are used differently within the "high cut" and the "low cut":  
+Terminal definitions are used differently within the "high cut" and the "low cut":
 
 .Relations between Bus-, Frame- and PDU Terminals.
 [#figure-terminal-relations]
@@ -97,7 +97,7 @@ The total of three FMUs are executed on a common FMI 3.0 importer.
 image::architecture_bus_simulation_fmu.svg[width=50%, align="center"]
 
 This type of communication allows the simulation of all bus features, such as arbitration or the simulation of timing.
-The supported bus features cannot be specified explicitly in the case shown, but refers to a specific implementation of a Bus Simulation FMU and are depending on the requirements of the bus simulation.
+The supported bus features cannot be specified explicitly in the case shown, but refers to a specific implementation of a Bus Simulation FMU and depend on the requirements of the bus simulation.
 This communication architecture enables complex bus simulations to be implemented on lightweight FMU importers.
 An n:m bus communication of several FMUs is also permitted.
 Depending on the needs, it may be necessary to dynamically provision the Bus Simulation FMU so that it provides the appropriate number of inputs and outputs to allow all FMUs to be connected.
@@ -120,7 +120,7 @@ Besides the textual specification for FMUs with bus support, this layered standa
 The following header files are provided:
 
 * https://github.com/modelica/fmi-ls-bus/blob/main/headers/fmi3LsBus.h[fmi3LsBus.h] provides general macros, types and structures for common Bus Operations.
-These header file applies to all supported bus types of the layered standard.
+These header files apply to all supported bus types of the layered standard.
 * https://github.com/modelica/fmi-ls-bus/blob/main/headers/fmi3LsBusUtil.h[fmi3LsBusUtil.h] provides common utility macros and structures for all supported bus types.
 * https://github.com/modelica/fmi-ls-bus/blob/main/headers/fmi3LsBusCan.h[fmi3LsBusCan.h] provides macros, types and structures of Bus Operations for CAN, CAN FD and CAN XL.
 * https://github.com/modelica/fmi-ls-bus/blob/main/headers/fmi3LsBusUtilCan.h[fmi3LsBusUtilCan.h] provides CAN, CAN FD and CAN XL explicit utility macros.

docs/3____physical_signal_abstraction.adoc

@@ -53,7 +53,7 @@ Signal variables belonging to frame `BusName.FrameName` are triggered by the Clo
 Standardized <<high-cut-network-description-files,network description files>> may optionally be shipped with each FMU to describe properties of signals and frames, such as signal units, frame composition and trigger conditions.
 If these <<high-cut-network-description-files,network description files>> are shipped, they must be placed into the `/extra/org.fmi-standard.fmi-ls-bus` folder.
 DBC, LDF, Fibex and ARXML files are allowed, e.g., `Powertrain.dbc`.
-The case sensitive root name of the <<high-cut-network-description-files>> must be used as network identifier in the Bus Terminal type and prefix in the variable names.
+The case-sensitive root name of the <<high-cut-network-description-files>> must be used as network identifier in the Bus Terminal type and prefix in the variable names.
 
 Multiple files can be specified, each one defining one network used by the FMU.
 This standard does not support composing one network from multiple <<high-cut-network-description-files,network description files>>, even if using internal include mechanisms, it rather enforces the rule: one network - one file.