Archives

  • 2018-07
  • 2019-08
  • 2019-09
  • 2019-10
  • 2019-11
  • 2019-12
  • 2020-01
  • 2020-02
  • 2020-03
  • 2020-04
  • 2020-05
  • 2020-06
  • 2020-07
  • 2020-08
  • 2020-09
  • 2020-10
  • 2020-11
  • 2020-12
  • 2021-01
  • 2021-02
  • 2021-03
  • 2021-04
  • 2021-05
  • 2021-06
  • 2021-07
  • 2021-08
  • 2021-09
  • 2021-10
  • 2021-11
  • 2021-12
  • 2022-01
  • 2022-02
  • 2022-03
  • 2022-04
  • 2022-05
  • 2022-06
  • 2022-07
  • 2022-08
  • 2022-09
  • 2022-10
  • 2022-11
  • 2022-12
  • 2023-01
  • 2023-02
  • 2023-03
  • 2023-04
  • 2023-05
  • 2023-06
  • 2023-08
  • 2023-09
  • 2023-10
  • 2023-11
  • 2023-12
  • 2024-01
  • 2024-02
  • 2024-03
  • 2024-04
  • 2024-05
  • The problem we now face is that the

    2020-07-30

    The problem we now face is that the reports/guidelines EPRI NP-5652/TR-106439 do not specifically incorporate the indirect COTS SW such as FPGA logic synthesis tools. They provide a well-defined process for dedication, but focus on commercial-grade (hardware) items, which directly compose safety-grade controllers. Even if an supplementary report EPRI TR-1025243 (2013) has recently been proposed to resolve the case of indirect software specifically, it still judges that these tools are not the subject of COTS SW dedication, contrary to expectations. The general consensus (SCC, Santhanam, 2002, Evaluation of Guidance for Tools, 2015) among the industry is that FPGA logic synthesis tools should be dedicated more strictly than other indirect COTS SW. This paper proposes an acceptance process and evaluation criteria, specialized for the dedication of indirect COTS SW as well as direct ones. (Step 1) It first recognizes an indirect COTS SW as a target of dedication, unlike EPRI NP-5652/TR-106439. (Step 2) It then determines the safety category of the target SW and identifies detailed evaluation criteria for acceptance. We adopted and modified those from US.NRC NUREG/CR-6421 (1996). (Step 3) Acceptance methods and specific V&V techniques which can satisfy the evaluation criteria successfully are selected. It also can provide an explicit cystamine from evaluation criteria identified in Step 2 to acceptance methods and V&V techniques selected in Step 3. The dedication with the acceptance methods then gets started. (Step 4) We can finally accept the target SW on the basis of the judgement whether the target SW satisfies its evaluation criteria or not, thorough various information and evidences which we can gather after getting through with the acceptance methods. We also performed a case study with a commercial FPGA logic synthesis tool – ‘Synopsys Synplify Pro’ which are being used to develop a prototype (Choi and Lee, 2012) of digital I&C in Korea. We tried to perform the COTS SW dedication according to the proposed evaluation criteria and acceptance process, and received positive response from the experts who have to prepare the COTS SW dedication before long. The paper is organized as follows: Section 2 introduces the FPGA development and verification processes as background. Section 3 explains and compares the relevant standards and reports. The evaluation criteria and acceptance process for COTS SW is proposed in Section 4. The case study with an indirect COTS software is introduced in Section 5, and Section 6 surveys related work and the state-of-the-art on the field of COTS SW dedication. Section 7 concludes the paper and provides remarks on future research extension and direction.
    FPGA development and V&V processes The development life-cycle of FPGA-based digital I&Cs follows IEC 61513 (2011) basically. An FPGA-based system, however, has a specific feature that the part of development life cycle using HDL (Hardware Description Languages) is classified into software, while after downloading to chip is classified into hardware. FPGA, therefore, should be developed to comply with both IEC 60880 (2006) in terms of software and IEC 60987 (2007) in terms of hardware. Fig. 1 depicts the V-shaped life-cycle of FPGA development explained in IEC 62566 (2012), consisting of software and hardware aspects. The software aspect also has a typical development life-cycle (NUREG/CR-7006, 1996) presented on the left-hand side of the figure.