Sections of the BAF Specification that have received significant coding and testing to date:
1) Pattern Aggregation (Section 3.1)
2) Instance Aggregation (Section 3.2)
3) Connect to Resource Library (Section 4.1)
4) BOM Library Methods (Section 4.2)
5) Data Logging Support (Section 5.1)
6) Exercise Support (Section 5.3)
Status:
1) Pattern Aggregation – All methods as described in the BAF specification have been coded and tested locally. Since this was the first section coded and there have been changes to the BOM specification it was updated with the latest changes and retested.
2) Instance Aggregation – All methods but one (LoadEntityAgg) have been coded, and tested with a single BOM aggregation. It will need to be modified to allow for aggregation of instance data that use different BOM types. The code is setup to incorporate this functionality with the current design.
3) Connect to Resource Libraries – There has been minimal discussion of this method since it appeared in the BAF specification as to what its actual functionality is. Of note, there have been several discussions in which the actual need for this method was discussed. However, I include it here since this is the only method that will return a library_id, which is a required parameter for all BOM Library Methods. We need to determine the requirements for this method, the library_id and its need in general.
4) BOM Library Methods – There are a number of outstanding questions regarding the methods in this section that need to be addressed and a number of assumptions that were made when this section was coded that will be addressed here.
a) Every method in this section requires a library_id, as discussed above the only method within the BAF specification that returns a library_id is the Connect to Resource Libraries method and we don’t have a clear definition of what there requirements are. In order to code these methods an assumption regarding library_id had to be made. The assumption that I made was that library_id would not be a parameter in the final specification.
b) I currently have BASS setup to manage the BOMs in a library structure that would exist at the server level. My reasoning was that BASS will need to have access to the libraries in order to manage the files. If the files are stored at the client level then BASS would not be able to perform some of the functionality as described in the BAF specification.
All BOM Library Methods have been coded using these assumptions plus the additional assumptions made at the method level as described below.
a) Method GetAvailableBOMs will return a comma delimited string of the BOM names that exist in the BOM library. The BOM library will contain all registered BOMs from Exercise Support and Pattern Aggregation. No flyweight BOMs exist in this library since they are only maintained on a temporary basis, during the life of the Federate.
b) Method SearchForCandidateBOMs will return a list of BOMs that match the search criteria. This is a significant change from the specification. The specification states that a model name will be passed to search on and if there is a match on the model name that a value of 1 will be returned and if there isn’t a match then a value of 0 will be returned. This type of search can be accomplished with method FetchBOMs which will return a BOM on a match to the model name or a null string if there isn’t a match. Instead this method was modified to search the BOMs metadata of the BOMs in the library. A final list of node values to search will need to be established but currently the system is setup to search certain fields on the BOM for a match on the data string sent to match on. The BOM names of BOMs that have a match to this search data are returned to the caller as a comma delimited string.
c) Method AddUseHistoryMetadataToBOMs makes the following assumptions: New use history will be added to the BOM above existing use history. This is consistent with BOMworks.
5) Data Logging Support – The majority of these methods have been coded and tested and were part of the demo. The only methods yet to be coded are as follows:
a) Method fetchLogHistory – Need to determined final requirements.
b) Method loggerSettings – Need to determine what settings will be allowed and then the parameters. We know that we will need to include in the settings the amount of instance data to review for instance aggregation. This may include a time limit, a number of instance records limit or some combination.
6) Exercise Support – All of these methods have been coded and tested according to the specification and the additional comments below.
In addition to the BAF Specification sections coded as mentioned above Publish Instance data, a section not mentioned in the specification has been coded. This is a method that monitors and captures entity instance data in a file that can be used for instance aggregation.