Deterministic Realtime Reaction

Obviously, when you program a tm( 10 ) in your UML model, you want this timout event to occur after 10 msec, so you must understand and maybe modify the relation between the timer interrupt frequency and the scheduling of timeout events..

Your target will impose some limits, some processors have a smaller interrupt latency than others:

when, in a statechart, you write tm( 1 ) you would expect Rhapsody to take the transition after a 1ms delay. Alas, this is not always true. It depends on the possible granularity of the timer. On a Windows system the timer granularity is set to 100ms because a PC is simply not capable of reacting much faster (*1). This means that it does not matter if you write tm( 1 ), tm( 2 ), .... or tm( 100 ), they will all give you a 100ms delay.
in most 16-bit CPU's, setting the timer very fast results in a performance degradation. On a 10 Mhz CPU, serving an interrupt every 1ms is a heavy burden on the system. If you want faster or more precise timers, use hardware timers, mask them with objects and then you can be as fast as you want.

In an RXF using an RTOS, the heartbeat and timer are taken from the RTOS.

Tick Timer Granularity

If we have a system tick of say 20ms and we ask for a timeout of 65ms, then the resulting timeout will actually be between 80ms and 100ms, depending on when the timeout is started relative to the system tick.

If precise timeouts are required, then it is recommended to use a hardware timer in combination with triggered operations.

You need to verify the timer configuration in your RTOS configuration like WSTRTOS.c and RIC_MS_PER_TICK in WSTRTOS.h