Verification of Application Logic designed with Radiy Platform Configuration Tool

Verification of Application Logic designed with Radiy Platform Configuration Tool

An important part of Instrumentation & Control System (I&CS) verification is verification of system-specific Application Logic (AL). This post of our blog discusses verification tasks specific to the AL for RadICS Platform based I&CS. Let’s briefly describe the subject of verification.

AL as a subject of verification

The RadICS platform is composed of multiple types of modules, based on the use of FPGA chips as computational, processing, and system-internal control engines for each of the modules. In terms of its high level functionality and flexibility, the RadICS Platform is essentially a safety PLC, except that the internal logic is performed by FPGAs instead of microprocessors.

The functionality of each module is driven by the generic Platform Logic (PL) is developed with an FPGA-specific IDE and implemented with Hardware Description Languages (VHDL is used for the RadICS platform implementation). Developers of a RadICS Platform based I&CS are not able to influence the PL, therefore, the verification of the PL is not their concern. The PL of the RadICS platform was throw verified by the platform vendor – RPC Radiy.

The AL for I&CS is developed with a specialized IDE – Radiy Platform Configuration Tool (RPCT). RPCT provides means to manage large complex I&CS projects. The AL is implemented with a graphical application-specific language that is very similar to Functional Block Diagram Language specified by IEC 61131-3. Figure 1 below shows a fragment of the AL designed in RPCT.

Figure 1 – Fragment of Application Logic Designed in RPCT

Basic components of the AL are Application Functional Blocks (AFB). Each AFB allows the user to select and use within AL projects particular functions: logical, mathematical, timing etc. Each “graphical” AFB in RPCT is bind to the hardware-implemented AFB omponent within FPGA-based Logic Module (LM) of the platform, this component executes the specified function. During the compilation, RPCT converts a graphical representation of the AL into the AL Code that is uploaded to the LM and executed during operation.

Mainly the AL Code consists of the following software instructions:

  • Reading data from the dedicated memory cells and putting it to a particular AFB.
  • Execution of the AFB function.
  • Writing results of the AFB function execution to the dedicated memory cells.

By the data structure, the AL Сode is a hex byte code of Radiy’s proprietary assembler for FPGA-based LM. The AL Сode also includes a human – readable part that is not uploaded into the LM and created to informative purpose only. Figure 2 shows fragments of both the parts.

a) Human readable part

b) Hex byte code

Figure 2 – Fragments of Application Logic Code

The AL and AL Сode are subjects of the verification process that we consider further.

Regulatory requirements that impact AL verification

The U.S. NRC regulations as well as IEEE and IEC standards provide requirements for software related activities and supporting processes in the Software Safety Lifecycle (SLC) of computer-based I&CS of nuclear power plants. These standards define various types of safety-related software and requirements for the SLC of each software type. The SLC framework for developing software using application-oriented languages is the most suitable for design and verification of the AL with RPCT. The following figure is adapted from Figure 3 in IEC 60880 and illustrates activities of the AL Verification and Validation (V&V).

Figure 3 – Activities of the Application Logic Verification & Validation

As it was said before, the design of the AL does not affect the PL, therefore for a particular project of I&CS only the AL requires to be verified and validated.

The top-level activities of the AL V&V such as requirements and design verification, system integration and acceptance testing practically do not imply strong specificity determined by the RadICS platform. In order to perform these top-level activities, the development organization should follow relevant requirements on V&V activities for a computer-based I&CS.

Verification of the AL implementation is tightly bound to the language and design environment used. Therefore this activity requires the usage of specific tools and approaches.

Verification of the AL implementation might combine different verification tasks e.g. analysis, reviews, tests or audits (depending on the regulatory body requirements). The review of the AL can be considered as the lowest scope of the verification efforts, as a rule, it could be enough for non-safety applications. The combination of the AL Review and AL Testing can be considered as a sufficient scope for the most safety-related applications.

Application Logic Review

The AL Review provides an objective assessment of the AL Code. The AL Review determines whether the AL Code completely and correctly implements the AL design specified in the design documentation. The AL Review should be carried out as a systematic software inspection.

In order to facilitate the AL Review, RadICS verification department uses the dedicated tool – RPCT Outputs Verification Tool (ROVT).

The AL Сode consists of 2 parts: a binary part to be uploaded to the FSC LM and a text part which is human-readable; both are in JSON format (see Figure 2). The binary part of the AL Code is not human-readable, so no credit is given to the direct human review of this part of AL. ROVT was independently designed by RadICS verification department to convert the binary part of the AL Code into the human-readable visualization that represents the design intent and to compare both parts to confirm their equivalency.

ROVT provides the following key features:

  • ROVT can be used as a mitigation tool that allows the designer (or verifier) of the AL to verify the compiler correctness (i.e. that the binary files correctly implement graphically based logic design).
  • ROVT provides the capability to compare AL projects and to highlight the difference ininput/output signals and AFBs usage, this feature can be used to do the change evaluation during the AL test planning.
  • ROVT is able to generate a data path tree backwardly from the selected output to all inputs, this feature can be used to do the impact analysis during the AL test planning.
  • ROVT performs static analysis of the AL. Static analysis checks are executed in automatic mode against user-adjustable safety rules.

Application Logic Testing

The purpose of the AL Testing is to ensure that requirements on the AL are verified by the execution of software functional tests. The AL Testing is performed with tool-driven behaviour simulation.

Currently, RadICS verification department uses UAL Controller Test Framework (UCTF) for the purpose of AL Testing. UCTF contains templates to generate test inputs for AL tests, a test bench to execute AL within the simulated environment, and templates to define expected outputs and to evaluate expected and actual outputs. UCTF is implemented in VHDL for the ModelSim simulation tool. Therefore the verification team personal have to have skills and knowledge in VHDL design and simulation.

For further usage, Radiy is developing the dedicated tool within the RPCT toolset – Simulator. Simulator executes (i.e., simulate) the AL according to user-specified scenarios. Simulator is able to simulate user-defined parts of the AL or all of the AL.

Simulator will allow the verifier to define test scenarios directly within RPCT graphically based representation of the AL. Simulator will also support test automation with script languages and provide interfaces for integration with external systems (e.g., customer plant simulation systems).

Conclusion

In conclusion, Radiy and RadICS provide the set of verification tools that allow performing a credible and creditable verification of the AL designed with RPCT.

Oleksiy Striuk, PhD – Verification Lead Engineer RPC Radics LLC
Viacheslav Shamanskyi – Senior Verification Engineer RPC Radics LLC

BLOG BLOG