1 / 14

Edward Bach (CAPTEC) comments on the SSD, IFSI/OBS/SP/2002-001, Issue 4.1.

Edward Bach (CAPTEC) comments on the SSD, IFSI/OBS/SP/2002-001, Issue 4.1. Table 3-1 differs from the V3.5 code in that the sim_science task is listed in the code (with priority 10) but not in the SSD, and the VM_MON task is listed in the SSD but not in the code.

farhani
Download Presentation

Edward Bach (CAPTEC) comments on the SSD, IFSI/OBS/SP/2002-001, Issue 4.1.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Edward Bach (CAPTEC) comments on the SSD, IFSI/OBS/SP/2002-001, Issue 4.1. • Table 3-1 differs from the V3.5 code in that the sim_science task is listed in the code (with priority 10) but not in the SSD, and the VM_MON task is listed in the SSD but not in the code. • All referred items are applicable to OBS 3.6 architecture, which differs from 3.5. In the Document the reference OBS version WILL BE SPECIFIED. • Table 3-2 differs from the V3.5 code in that the VM_REQ event is defined in the SSD but not the code.a task and an interrupt service; See point 1 • In Table 3-2, how does the HS_Event trigger the hs1 task? It seems to be signalled during a fifo flush and results in the hs0 task not blocking after completion of the fifo flush. To be corrected,To be corrected See fig. 3.3 • In Table 3-2, how does the MEAS_Event trigger the ls_hdl task?End of transaction Event (mechanism to be better described in LS section) • In Table 3-2, what is meant by the TUNING task and how does it or VM signal the HS_FLUSH_EVENT (in V3.5 code this is signalled by hs0)?TUNING=HS_HDL • In Table 3-3, why is it stated that the LS_SEMA is raised by various tasks? From the V3.5 code it appears that this semaphore is signalled by push_lp_queue, which is only called from the hk_ask task. • Also in push_hp_queue, used everywhere • Table 3-3, are the HS_HDL_WAIT_SEMA and LS_HDL_WAIT_SEMA also raised by Virtuoso timers? NO • In Table 3-4, the SD_TM_QUEUE is also received by the res_chk task and hs_hdl task (the latter for abort). This is unusual design and requires clarification. To be corrected

  2. Edward Bach (CAPTEC) comments on the SSD, IFSI/OBS/SP/2002-001, Issue 4.1. • In Table 3-4, the SD_TM_QUEUE seems to be sent by the DATA_HDL task, not the HS task. • To be corrected • In Table 3-4, the HK_TM_QUEUE is also received by the res_chk task. This is unusual design and requires clarification.To be corrected • In Table 3-4, the HK_TM_QUEUE seems to be sent by various other tasks (also via call to generate_report), i.e., DATA_HDL,CMD_SEQ, HS_HDL, LS_HDL.To be corrected • In Table 3-4, what is meant by the ERR_HDL task?Such task doesn’t exist any more. To be corrected • In Table 3-4, the LS_HP_QUEUE is also sent by the Single_HK task.To be corrected • In Table 3-4, the LS_HDL_QUEUE is also received by the LS_HDL task. This is unusual design and requires clarification.To be corrected • In Table 3-4, the SD_PKT_QUEUE is also sent by the HS_HDL task (via nested call to deliver_sd_sim_packet). To be corrected • In Table 3-4, the HS_HDL_QUEUE is also sent by the HS_HDL task.To be corrected • General. There are no requirements covering the on-board data memory write-read check and the PM sum check performed at ground request.To be corrected

  3. SUM Comments

  4. A. de Jonge (SRON) comments on the SUM, IFSI/OBS/MA/2005-001, Issue 4.1 • 0. Overall a very useable document in terms of scope and depth. • The document does not clearly in the intro refer to the OBS version(s) it applies to. • This is hidden in the change log. OK. reference to be added • 2. Section 2.2. refers to OBS version 1.2 and an appendix A that is actually appendix A2. To be corrected • 3. Appendix A2 OK. reference to be added • The files should in their contents (by comment lines) and their file name/location • make clear for which OBS version and/or hardware they are intended. • Actually, for some full configuration control may be required. • 4. Section 2 describes how to compile the OBS but an overview of the required files/directory structure (content of the 'OBS distribution') is missing. It is in the CIDL. The doc. will be added to AD. • 5. The mentioning of files that 'should never be deleted' in section 2.5 suggests • a strange structure of the OBS distribution package. I would have expected • that installing the distribution would place them in a protected place. • You are right. It will be corrected. • 6. There is no overall instruction on how the OBS package is distributed and how/where it can be installed and run. What do you mean?

  5. A. de Jonge (SRON) comments on the SUM, IFSI/OBS/MA/2005-001, Issue 4.1 7. Section 3 - loading the OBS into the ICU should have a separate (placeholder) section for procedures to be used in flight. OK 8. Section 3.2 uses external tools. I expected a complete overview of tools required and provided - including the setup with e.g. router, cdsm simulator etc. in the CIDL 9. In view of the structure of the EGSE router CDMS setup, it is clear that there is some hidden configuration required to be able to run the ObswLoader tool of section 3.2.3 ??? 10. Section 4 suggests that physical power-on should occur before notification of the OBS. Operationally, this can not be 100 % guaranteed, what if not? Similar for section 5 switch-off, even worse - a subsystem may be switched off without plan (e.g. power system malfunction). Consequences to be specified?? 11 Section 3.2 refers to OBS version 3.2 and an 'appendix A‘ To be corrected 12. From the desription of 'pagefile.txt' in section 3.2.1 and the content given in appendix A2 it looks as if pages 1-10 should be avoided during TC generation. Why is that? Was necessary with AVM1 EEPROM.To be confirmed for FM by CGS. 13. The flow diagrams in appendix A4 still indicate that the OBS will correct illegal ground-provided parameter values. This is not conform the agreed error handling strategey. We check this parameters in OBS, before calling the VM, but wedidn’t modify the VM code.

  6. A. de Jonge (SRON) comments on the SUM, IFSI/OBS/MA/2005-001, Issue 4.1 14. The function of appendix A3.3 is unclear. It would be helpful if a paragraph describing the purpose of each table was added. I could not directly find reference to the tables in the main text. To be checked 15. The limit checking on HK generated by the OBS itself, as implied by appendix A3.1 and A3.2, should give the actions to be taken if the limits are exceeded. To be added when necessary 16. Table A3.2 should give or refer to the required calibration of the digital values. OK for FM 17. It should be made explicit what constitutes the various levels of 'functional test', i.e., what can or must be verified after power on and boot to ensure that the ICU and OBS operate successfully. The current description in section 4 is too vague. Example?

  7. Edward Bach (CAPTEC) comments on the SUM, IFSI/OBS/MA/2005-001, Issue 4.1 • 1. table 6-10. The following FID are missing from table 6-10 (see • cmd_seq.h) • TC_FUNMAN_LIMCK_FID 4 // limit checking FID 4 AID 0 • TC_FUNMAN_LCU_FID 8 // Local oscillator FID 8 • TC_FUNMAN_CALIB_FID 10 • TC_FUNMAN_CFSSYS_NEW_FID 12 // Configure Subsystem: alternative • (simplified) implementation • TC_FUNMAN_PEAKUP_FID 13 // FID for peakup • TC_FUNMAN_SPCTRSM_AID 127 // Simulated Spectroscopy FID 16 AID 127 • These are all described in the following sections except for FID 13. All To Be added • 2. table 6-10. • FID 11 is #defined twice in the code (as TC_FUNMAN_SPECTSPY_FID and TC_FUNMAN_ABRT_SP_FID). To be clarified • HIFI_non_periodic_hk_FCU (AID 3) is missing for FID 3. It is there • AID 11-25 are missing for FID 5. To be clarified • AID 2-3 are missing for FID 7. To be added • AID 7 is missing in the table and in section 6.5.11 for FID 16. • This is a software-specific function so should be described. To be added • AID 2,3,4 and 17 are missing for FID 11. To be added • Should frequency switch be described in 6.5.10? NO. Add sentence to slow chop • AID 1,3,4,5,6 and 127 are missing for FID 16. To be added

  8. Edward Bach (CAPTEC) comments on the SUM, IFSI/OBS/MA/2005-001, Issue 4.1 • 6.5.10. The code is confusing regarding the AID for configure spectroscopy. Will the code be updated to remove the #define for FID11, AID YES • 6.5.11. The start_VM (AID 1) is not described for FID 16. This is a software-specific function so should be described. OK • 6.5.17. Please add reference to FID 127 in this section. OK • table 6-19. The standard PSICD NOK error codes 0-5 are not included here or in Table 6-20. To be added • table 6-19.SUM refers to OBS V3.6 • Error codes 0107-010a, 0507, 5002 and 5003 seem to be absent from V3.5. Is this correct? • Error codes 0902, 0919, b002-b007 are defined in V3.5 code but not here. • Error code 0608 is defined in V3.5 code but not here. • table 6-20. SUM refers to OBS V3.6 • Error code 062a is defined in V3.5 code for NOK but not EXF (the table has two definitions). • Error codes 0903, 0933-0939, 1300, 2003 are defined here but not in V3.5 code.

  9. Test Procedures Comments

  10. A. de Jonge (SRON) comments on the HIFI ICU OBS IFSI Test Procedures, IFSI/OBS/PR/2006-001, Issue 1, 10/05/06. 0. Overall impression. As this document copies a lot of very detailed information from other documents, it is to be expected that it will be very difficult to keep up to date. In that context, either it becomes doubtful if tests will be executed according to the correct up-to-date procedure, or doing the tests will become very time-consuming because the document has to be updated for minor changes in the OBS. ?? 1. The AD2 refers to issue 2.1 whereas issue 4.1 is in the data package. More errors n the AD list. AD1 title is SSD but should (?) be SVVVP, cf. section 1.1. Check the whole list. OK 2. Cross-reference of each procedure to the SVVP misses. It cannot be verified if procedures are available for all tests that should be executed. I could not get hold of a copy of the SVVP (not found on HIFI project site) Many of my remarks may be irrelevant because covered in SVVP correpondence one-to-one of TPs with SVVP test CAses. 3. At least in the switch-on tests, I would have expected tests for prime/redundant operation The idea with FM is to replicate the full procedure on both sections.

  11. A. de Jonge (SRON) comments on the HIFI ICU OBS IFSI Test Procedures, IFSI/OBS/PR/2006-001, Issue 1, 10/05/06. 4. Not sufficient tests are visible verifying the correct generation of events OBS runtime errors. I have to assume this is mostly covered by unit test - which would be more logical in any case. But somewhere a test is expected for each potential runtime error (or event) Whenever possible execution failures have to be tested with CDMS “Local Commands”. Some of the runtime errors can be triggered by wrong input params. 5. No tests are visible covering malfunction of a subsystem. Supposedly the rationale for non-existence of these tests is covered in the SVVP. What do you mean ? 6. The footer of the appendix pages is incorrect. To be corrected.

  12. Edward Bach (CAPTEC) comments on the HIFI ICU OBS IFSI Test Procedures, • IFSI/OBS/PR/2006-001, Issue 1, 10/05/06. • 1. General. Why is SVVP not updated, i.e., are there any tests to confirm • (a) changes to specification (SCR) and • (b) correctness of modifications to resolve software problems (SPR/NCR) identified by higher-level testing? • Yes, there are. SW req. in SSD and SVVP to be updated • 2. General: It is not clear how the expected results in Appendix 1 relate to particular tests or test steps.In the test steps there is an indication of the reference section of Appendix 1 • 3. Gen. Section 3.2 and the "observed reaction" column in individual testsseem to be deliberately blank to use as the basis for a test report. Consider adding an explanatory note in the introduction.OK • 4. Gen. What is the coverage of the SVVP in terms of test cases, i.e., are there any modifications or incompleteness with respect to the SVVP? • For the described and completed procedures the coverage is full. • 5. Gen. What is the coverage of the SSD in terms of requirements, i.e., are there any modifications or incompleteness with respect to the SVVP? • The coverage of SSD is checked in SVVP. In the hypothesis that the TPs at the end will have a full coverage of the test cases in SVVP, we don’t need to redefine a cross reference matrix. • 6. Gen. What is the coverage of the specification in terms of commands and TM packets, i.e., are there any modifications or incompleteness with respect to the SVVP?Yes, there are still missing TP. • Has Appendix A2 of the SVVP been completed??NO.

  13. Edward Bach (CAPTEC) comments on the HIFI ICU OBS IFSI Test Procedures, IFSI/OBS/PR/2006-001, Issue 1, 10/05/06. 7. Gen. What are the preconditions for the individual test procedures, i.e., what state is necessary for the OBS, the HW and the test environment? The pre condition of TP1 is described. All other procedures start where the preceding procedure finishes. 8. Gen. What are the final actions necessary at the end of test to stop the OBS and restore the test environment to a known state?To Be Added 9. Gen. Are there any inter-procedure dependencies or constraints? For instance, it seems necessary for TP1 to execute successfully before other tests may be executed..Yes. ?? 10. Gen. Please provide list of open areas, i.e., TBC, TBD, TBW and provide status at DRB.OK 11. Gen. Where are the suspension and resumption criteria and problem reporting procedures defined? What do you mean for suspension/resumption criteria? Standard SPR processing 12. Gen. Consider adding general monitors, e.g., no unspecified ICU resets, all error reports and NACK to be explained, no cyclic tasks overrun, no TC/TM packets lost, no incomplete or incorrectly formatted TM, all commands from OBS to S/S to be valid, etc. To be discussed 13. Gen. How is regression testing to be determined, i.e., do you plan to run all tests each time the OBS is modified? Depends on modifications.

  14. Edward Bach (CAPTEC) comments on the HIFI ICU OBS IFSI Test Procedures, • IFSI/OBS/PR/2006-001, Issue 1, 10/05/06. • 14. Applicable documents: • AD.1 should be called SVVP not SSD. OK • The PSICD is now at issue 5.OK • The issues for the specification seem out-of date (AD.8-AD.11)OK • When will the reference to AD.17 be written?AD 17 will disappear • 15. Confirm that CDMS simulator version 2.5 is necessary.No • 16. What is meant by "HW test equipment" in point 7 of section 2.3?To be added • 17. What version of the ICU is used? Where are the corresponding PA procedures and monitoring defined (this applies especially if the FM ICU is used)?To be added (?) • 18. When will TBD be resolved?ICU FM CGS EIDP • 19. Should TP4 be expanded to test PM checksum and periodic DM write/read check failures? If not, where are these features tested?Check PM is already there. Check DM is difficult to check with end to end tests

More Related