Simulation

A model to be simulated consists of components connected to each other and a time reference. The time reference is used to sample the continuous-time signals flowing through the connections of the model and to trigger the components. The simulation is performed by triggering the components with pulses generated by the time reference at simulation sampling time intervals. Having been triggered, the components evolve themselves, compute their outputs, and writes them to their output ports.

The simulation stages are shown in the flow chart in the figure above. Performing, inspecting, and reporting of all the stages of the simulation is carried out automatically without requiring any user intervention.

In the first stage, the model is inspected to see if there are connections having any unconnected terminals. If a connection having an unconnected terminal is detected, the simulation is terminated at this stage. Another case where the model is not suitable for simulation is when algebraic loops exist. For example, almost every feedback system model includes algebraic loops. An algebraic loop is a closed-loop consisting of one or more components whose outputs are directly dependent on their inputs. The simulation does not continue because none of the components in the loop can generate output to break the loop. Such a problem can be broken by rearranging the model without algebraic loops, solving the feed-forward algebraic equation of the loop, or inserting a memory component with a certain initial condition anywhere in the loop. Causal provides all these loop-breaking solutions. During the inspection stage, in case they are detected, all the loops are broken. Otherwise, a report is printed to notify the user to insert memory components to break the loops.

In case the inspection phase results positive, the putter and taker tasks are launched in order to ensure the data flow through the model connections. At this point, a putter and a taker task are bound to each connection. For example, in the figure below(on the left) is given an example model section consisting of components B1, B and the connections L1, L2, L3. When triggered, the B1 reads data from L1 calculates its output and writes to L2. Similarly, when triggered B2 reads data from the L2, calculates its output, and writes to the L3. The tasks that are bounded to L1, L2, and L3 corresponding to B1 and B2 are shown in the figure below(on the right). Since B1 reads the data from L1 and writes data to L2, a taker task is bounded to L1 and a putter task is bounded L2. Similarly, since B2 reads the data from L2 and writes data to L3, a taker task is bounded to L2 and a putter task is bounded L3. Since both a putter and a taker task are bound to the L2, data can flow from B1 to B2 through L2. A task manager is constructed to check whether the tasks launched during the initialization stage are active or not throughout the simulation and to report the error in case an error occurs.

The initialization stage is followed by the run the stage. The tasks that are launched corresponding to the components during the initialization stage expect the components to be triggered through their trigger pins. These triggers are generated in the sampling intervals of the simulation by the model clock during the run stage. It is possible to sample the signals of flowing through the connections at equal or independent time intervals. The generated triggers are put into the trigger pins of the components. The task corresponding to a triggered component is defined as reading data from the input of the component, calculating the output of the component, and writing to the output port.

When the run stage is completed, the tasks launched at the initialization stage are closed and the simulation is ended.