diff --git a/docs/3____physical_signal_abstraction.adoc b/docs/3____physical_signal_abstraction.adoc
index a63d5a48..6bd154a8 100644
--- a/docs/3____physical_signal_abstraction.adoc
+++ b/docs/3____physical_signal_abstraction.adoc
@@ -41,13 +41,16 @@ In order to use FMU input and output variables as transport layer for networks,
 Such a clock is scheduled by the sending FMU to indicate the transmission of the corresponding frame or frames.
 
 The output clock type, `periodic` or `aperiodic`, is defined by the sending FMU.
-This allows the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:
+Depending on the bus type to simulate and further application-specific constraints, this may allow the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:
 
  - While `aperiodic` clocks allow very accurate network simulations, frequently entering `Event Mode` will reduce the network simulation speed.
  - Using `periodic` clocks reduces the number of `Event Modes` required and speeds up the simulation at the cost of simulation accuracy, because timing must be forced into a fixed grid and some intermediate values might not be transmitted.
  - One could use (structural) parameters to define the accuracy of `aperiodic` clocks, allowing control of the simulation accuracy and performance with the same FMU.
  - The input clocks shall be `triggered` clocks.
 
+As already mentioned above, this is not a general rule.
+The statement depends heavily on the bus type to be simulated and other application-specific parameters.
+
 The importer will then connect and merge output clock activations, even those of different clock types, and forwards them to the input clocks, as required by the network semantics.
 
 Signal variables belonging to frame `BusName::FrameName` are triggered by the clock `BusName::FrameName_Clock` and all these variables and their corresponding clock must share the same `causality` (`input` or `output`).