Posts Tagged simulated time base

Interacting Functions, Temporal Approach

Up to now, time was not an issue, neither for the timely distance of the stimulating calls to a component, nor for the timely distance between a stimulating call to a component and the resulting call to another component. However, it could be an important test to check if such a resulting call happens “fast enough” after a stimulating call, i.e. within a given time frame.

To be able to test the temporal behavior of a component in a simulated environment, a simulated time base needs to be available. This means, a certain function inside the component is called in known equidistant times (e.g. every 10 ms). This is usually the case if the component is executed under the control of a Real-time Operating System (RTOS) with time-slicing, e.g. OSEK. But also a simple self-made interrupt-driven application usually conforms to this requirement.

The calls to this function represent the “heartbeat” of the component. They provide a time reference for the testing of the temporal behavior of the component. (The heartbeat function is usually called “handler function” or “work task” or simply “tick”).

If a heartbeat function exists, timely behavior can be tested.

If a heartbeat function exists, timely behavior can be tested.

Tessy allows very comfortable (drag&drop) to generate scenarios (i.e. component test cases) with references to (simulated) time.

Scenario with temporal reference

A scenario with temporal reference (with results)

In the above scenario initially the component function init() is called to initialize the component. At 20 ms simulated time, the component function set_sensor_door() is called with its parameter set to “closed”. Resulting from this stimulus, the external function LightOn() is called at 30 ms simulated time. This has happened as expected what is indicated by the green tick mark. At 60 ms simulated time, the variable sensor_ignition (a global variable of the component) is set to “on”. At 80 ms simulated time, at the end of the scenario, the value of the variable state_light (also a global variable of the component) is checked. The value is “off”, what is as expected.

, , , , , , , , ,

No Comments