Decomposition Language: Activity Chart Implementation : Sub-Activities Code

Sub-Activities Code

Assuming both A111 and A112 are basic Activities, the basic activity can be defined in one of three activation modes:

Reactive controlled

For Reactive controlled and Reactive self modes, the code body of the Activity will look like the following code frame:

void

cgActivity_A111(void)

{

… Body implementation

}

 

 

While for the Procedure like mode, the code body of the Activity will look like the following code frame:

void
cgActivity_A112(void)
{
if ((cgActiveActivities1 & BITAC_A112) != 0) {
… Body implementation
stop_activity(A112);
}
}
 
 

The differences between the three will be found in the activation rules for each mode. Reactive controlled and Reactive self modes will perform a step, while they are active, each time the TASK containing them is running. Usually, a TASK will perform a run to stable run (also called a super step), that might require few steps (also called micro steps). Those using Reactive controlled and Reactive self modes will participate in each of the steps.

Procedure like mode performs only a single step each time the TASK containing it is running. At the beginning of the TASK, the relevant Activity active bit will be set. Then the Activity body will unset that bit after it ran, calling stop_activity.

Another difference, between Reactive controlled, Reactive self and Procedure like, is in the allowed syntax of the Mini-Spec which is described later.

Adding the controller A11_CTRL to A11 will make the code look like:

void
cgActivity_A11acy1(void)
{
cgActivity_A111();
cgActivity_A112();
cgActivity_A11_CTRLcnt1();
}
 
 

With the controller function, cgActivity_A11_CTRLcnt1(), like:

void
cgActivity_A11_CTRLcnt1(void)
{
cgDo_A11_CTRLcnt1();
}
 
 

The implementation of cgDo_A11_CTRLcnt1() depends on whether A11_CTRL is implemented as a Statechart or as a Flowchart. In this discussion we will only show a brief descriptions of each; a more detailed description is given later in the appropriate sections.

For a Statechart implementation:

void
cgDo_A11_CTRLcnt1(void)
{
StateInfo_A11_CTRLcnt1 nextState_A11_CTRLcnt1 = 0;
if (currentState_A11_CTRLcnt1 == 0) {
nextState_A11_CTRLcnt1 = FS_A11_CTRLst2;
}
else
{
… Rest of the Statechart logic
}
if (nextState_A11_CTRLcnt1 != 0) {
if (currentState_A11_CTRLcnt1 !=
nextState_A11_CTRLcnt1)
cgGlobalFlags |= BITSUPERSTEP_TASK1;
currentState_A11_CTRLcnt1 = nextState_A11_CTRLcnt1;
}
}
 
 

For a Flowchart implementation:

void

cgDo_A11_CTRLcnt1(void)

{

… The Flowchart logic

}

Activities within a certain TASK can communicate with each other using various method. Within a single TASK/ISR boundary, the Activity Chart Graphical Language of MicroC shares most of the semantics used in the Activity Chart Graphical Language of Rational Statemate. However, there are few discrepancies between those languages that should be noticed, and will be mentioned shortly below. The interaction between TASK/ISR and communication between Activities not residing in the same TASK/ISR has nothing equivalent in the language of Rational Statemate, and should only use the services provided by the run time OS, also described below. Activities defined to be TASK/ISR have already been discussed, but it must be remembered that such Activities are not fully compatible with the Activities that can be defined in Rational Statemate.

Discrepancies between MicroC Regular (i.e., not a TASK nor ISR) Activities running under the same TASK/ISR and Rational Statemate Activities that should be noticed include the following:

Status sensing – stopped/started
Note: We do not include here those language features that are only temporarily not supported, but will be supported in coming release of the product. Instead, we are focusing our discussions on those aspects that are not expected to change.