Management of Multiple Instances of LPT State Machines

[pasetti]

This ticket formalizes the discussion held during the teleconference with Christian and Markus on 29 November. The issue at stake is the management of the multiple instances of the LPT State Machine: an application must instantiate LPT_N_BUF LPT State Machines (because there is one LPT State Machine for each LPT Buffer). The value of LPT_N_BUF is application-specific. Each LPT State Machine has its own data structures.

The solution which I would like to propose is the same that has been used in the CORDET Framework where there are several components which must be instantiated multiple times by applications. In order to illustrate the solution adopted by the framework, I will use the example of the InManager but the same pattern has also been applied to the other components (InStream, OutManager, OutStream, etc).

The number of InManager instances in an application is CR_FW_NOF_INMANAGER. The InStream is defined in module CrFwInStream. Each InStream instance has an identifier which an integer in the range: [0, (CR_FW_NOF_INMANAGER-1)].

The CrFwInManager module offers operation CrFwInManagerMake(i) where i is the InManager identifier. This is a factory function which retrieves the i-th InManager State Machine instance. The first time this function is called with a certain value of the argument i, it creates the i-th InManager State Machine instance. Subsequent calls return the same instance. This function is therefore used by the application whenever it needs to access the i-th InManager instance.

Inside the CrFwInManager, the following data structure is defined:

    /** The descriptors of the InManager State Machines. */
    static FwSmDesc_t inManagerDesc[CR_FW_NOF_INMANAGER];

This is the array which holds the CR_FW_NOF_INMANAGER instances of InManagers. Note that all CORDET components conform to the "CORDET Component Model" described in section 5 of the CORDET User Manual. This means that, when a component instance is created, it is assigned an instance identifier which uniquely identifies a component instance within the set of components of a certain type. The first instance to be created by a factory function is assigned the instance identifier of 0. The second instance is assigned the instance identifier 1. And so on. The instance identifier can be accessed with function CrFwCmpGetInstanceId.

In the case of the InManager, this means that each InManager knows its own identity and its functions can use this information to perform the "right" action. For instance, each InManager needs to know the size of its own PCRL. This is held in array inManagerPcrlSize[CR_FW_NOF_INMANAGER] which is declared in the CrFwInManager module. The implementation of the actions and guards associated to each InManger contains the following code:

  CrFwCmpData_t* inManagerDataLocal = (CrFwCmpData_t*)FwPrGetData(prDesc);
   CrFwInManagerData_t* inManagerCSData = (CrFwInManagerData_t*)inManagerDataLocal->cmpSpecificData;
   CrFwInstanceId_t id = inManagerDataLocal->instanceId;

This code gives access to the instance identifier of the InManager instance and allows the action or guard to access the PCRL size corresponding to the InManager instance.