User documentation: "timed event" replaced by "time event", except in source code quotes

plugins/org.yakindu.sct.doc.user/help/03_getting_started/getting_started.textile

@@ -228,7 +228,7 @@ table(scedit).
 
 h2. Simulating the light switch model
 
-Simulating a model means to execute it, raise events manually, have timed and run cycle-based events being triggered automatically, and observe its behaviour.
+Simulating a model means to execute it, raise events manually, have time events and run cycle-based events being triggered automatically, and observe its behaviour.
 
 Start the simulation by right-clicking on the _LightSwitch.sct_ file in the project explorer and selecting _Run As → Statechart Simulation_:
 

plugins/org.yakindu.sct.doc.user/help/04_code_generation/code_generation.textile

@@ -96,7 +96,7 @@ A statechart reference may contain various configuration features. You will lear
 
 h2. Enhancing the generator model by timing capabilities
 
-However, the default generator model is insufficient yet. The _CallHandling_ statechart model uses _after_ and _every_ expressions. That is, it is dealing with *timed events*, requiring a timer service to trigger them. We can instruct the code generator to provide us with a default timer service implementation by adding the following feature to the generator model:
+However, the default generator model is insufficient yet. The _CallHandling_ statechart model uses _after_ and _every_ expressions. That is, it is dealing with *time events*, requiring a timer service to trigger them. We can instruct the code generator to provide us with a default timer service implementation by adding the following feature to the generator model:
 
 bc(prettyprint). 
 feature GeneralFeatures {
@@ -176,7 +176,7 @@ bc(prettyprint linenums)..
 p. Let's have a detailed look at this client code:
 
 * First, this program creates a new instance of the state machine by calling the default constructor of @CallHandlingStatemachine@ (line 9).
-* Since we are using timed events, the statechart implementation requires an implementation of the @ITimer@ interface. Since we added the @TimerService@ feature to the generator model, the code generator creates a default implementation @org.yakindu.scr.TimerService@ that uses the @java.util.Timer@ class. A new instance of the default @TimerService@ is created and set to the state machine (line 10).
+* Since we are using time events, the statechart implementation requires an implementation of the @ITimer@ interface. Since we added the @TimerService@ feature to the generator model, the code generator creates a default implementation @org.yakindu.scr.TimerService@ that uses the @java.util.Timer@ class. A new instance of the default @TimerService@ is created and set to the state machine (line 10).
 * In line 13, @sm.enter()@ enters the state machine and – via its initial state – activates its *Idle* state.
 * For each interface in the statechart definition block a getter method has been generated, here @getSCIPhone()@ and @getSCIUser()@. You can access all incoming events and all variables via these interfaces. In line 16, the _incoming_call_ event is raised, activating the *Incoming Call* state after the next run cycle has been executed (line 17).
 * In line 20, we raise the _accept_call_ event via the _User_ interface. It activates the *Active Call* state after the next run cycle has been performed (line 21).

plugins/org.yakindu.sct.doc.user/help/05_reference/reference.textile

@@ -1546,7 +1546,7 @@ h5. Variable and event access
 
 The getters and setters for each variable and event are also contained in the header file. The method names are matching the following pattern: _statechart_name_<code>Iface</code>_interface_name_@_@[ <code>set</code> | <code>get</code> | <code>raise</code> ]@_@[ _variable_name_ | _event_name_ ]. For example, the getter of the _red_ variable of the _pedestrian_ interface is named @trafficLightWaitingIfacePedestrian_get_red(TrafficLightWaiting* handle)@.
 
-h4. Timed state machines
+h4. Time-controlled state machines
 
 If a statechart uses timing functionality or external operations, an additional header file is generated. Its name matches the pattern _statechart_name_@Required.h@. This header file defines method hooks the client code has to implement externally.
 
@@ -1820,7 +1820,7 @@ The @StatemachineInterface@ interface specifies the four functions @init()@, @en
 
 ==<!-- The getters and setters for each variable and event are also contained in the header file. The method names are matching the following pattern: _statechart_name_<code>Iface</code>_interface_name_@_@[ <code>set</code> | <code>get</code> | <code>raise</code> ]@_@[ _variable_name_ | _event_name_ ]. For example, the getter of the variable _red_ of the _pedestrian_ interface is named @trafficLightWaitingIfacePedestrian_get_red(TrafficLightWaiting* handle)@. -->==
 
-h4. Timed state machines
+h4. Time-controlled state machines
 
 If a statechart uses timing functionality, additional classes are generated.