pasetti
commented
7 years ago There is indeed an error in the specification. This had been identified in GitHub Issue 77 (see "Mistake 1"). The relevant text from the issue is:
The HkRep report encapsulates a (3,25) or a (3,26) report. This report is created by a HkCreateCmd command and is deleted by a HkDeleteCmd command. While it is alive, is generated periodically if it is enabled or else it is remains pending and is not generated.
The Enable Check of the HkRep report is currently defined as: "The enable status is read from the isEnabled field of the Report Definition corresponding to the report's SID". This definition is wrong: the isEnabled field in the RDL is used by the Ready Check to decide whether the report should be generated in the current cycle.
The Enable Check of the HkRep report should be changed as follows: "The report is enabled if its SID is defined in the RDL". This definition ensures that the report remains alive until the HkDeleteCmd is received which removes its SID from the RDL.
I had forgotten to update the specification (or perhaps I updated it and forgot to upload it). I will now fix this.
reimers
Consider following case we tested:
0.) Precondition: one periodic (predefined) HK report with SID = 1 was running and it is arriving periodically as expected 1.) Disable HK with SID = 1 using TC(3,6), the isEnabled flag in RDL was set to disabled 2.) According to the Enable Check the report was unloaded from the OutLoader
Due to the action in 2. the HK report with SID = 1 can not be enabled again, because it is not loaded in the OutLoader. We can solve this, if the Enable Check checks not the isEnabled flag but if the SID is defined in the RDL. The Ready Check also checks if the isEnabled flag is set to become ready, therefore this solution works.