Dynamic initialization uses sequences of action language statements to create, relate and set attributes of preexisting instances. This form of initialization has been supported by MC-3020 since the first release (1.0).

Action language statements in initialization functions (or previously in init objects) are executed once when a system first starts. The action language statements perform create statements to create the preexisting instances. Relate statements execute to establish associations between these newly created instances. Action languages statements are executed which write the attribute values of the preexisting instances.

When all of the action language statements are complete for all init functions (tagged with TagInitializationFunction), then all preexisting instances are fully established and initialization is complete.

Advantages to dynamic initialization include:

Disadvantages to dynamic initialization include:

The basic building block for specifying preexisting instances is the initialization function. This approach provides the user with the ability to use the same set of preexisting instances for simulation with the BridgePoint Verifier as are used during the actual execution of the system on the target platform.

Initialization functions contain the action language that describes the set of preexisting instances for the subsystem or domain. Initialization functions are normal functions and can be invoked during normal system execution as well as at start-up.

The rules for constructing initialization functions are enumerated below.

Figure 8.1, “Autosampler Class Diagram” shows the xtUML class diagram for the autosampler example model. Note that the autosampler example model can be found in the examples directory of your MC-3020 installation. Figure 8.2, “Autosampler Init Function” shows the action language statements contained in the initialization function for the autosampler domain. The function is marked as an init function with the statement

TagInitializationFunction( "setup" )

in the domain.mark marking file. This init function executes creates, relates and attribute writes to establish all preexisting instances. The function runs once and only once at system start.

Figure 8.1. Autosampler Class Diagram

create object instance car of CAR;
car.carousel_ID=10;
car.current_position=10;
create object instance row of ROW;
relate row to car across R1;
row.radius=10;
row.current_sampling_position=0;
row.maximum_sampling_positions=20;
row.sampling_time=3000000;  // 3 seconds
row.needs_probe=false;
create object instance probe of SP;
probe.probe_ID=1;
probe.radial_position=20;
probe.theta_offset=40;
probe.current_position="up";
probe.available = true;
    

In systems with more than one domain, dynamic init is only slightly more complex. Initialization functions are written for each domain. These multiple init functions establish the preexisting instances (PEIs) for the multiple domains. The init functions are each marked with TagInitializationFunction in each domain's corresponding domain.mark marking file.

In some systems it is important that certain domains be initialized before other domains. Or, there may be requirements on the ordering of the initialization between domains. In these cases, a function in only one domain is tagged as an init function (using TagInitializationFunction). This function then invokes functions in the other domains, thus imposing the desired order on the initialization sequence.

To simulate the xtUML models with the same set of preexisting instances that are used on the target system, the analyst must invoke the initialization functions. BridgePoint Verifier provides a facility to do this very easily.