When implementing the elements (= modules) and test cases for the application or library, mind all restrictions when using logi.CAD 3 . See the article "Restrictions for the application" of the " logi.µSRTS safety manual" and the article "List of unsupported and restricted elements" of the documentation "Safety instructions on working with the IDE " .

Perform a static code analysis for all application elements in the context of the →resource (in the case of an application) or for all library elements in the context of each library (in the case of a library). This means that you need to execute a static code analysis relating to the →instance or the library. Details: See logi.CAD 3 user documentation, "Validating objects" – section "Validation relating to the instance" or "Validation relating to the library".
The static code analysis is executed according to the rules that are activated for the resource (in the case of an application) or the →project (in the case of a library). Contact the system integrator for information on the minimum set of the activated rules.

The generated MRC-report (a report with the file extension .mrclog) contains information about the executed static code analysis.

Example for MRC-report

Check the 1st and 2nd pieces of the following information in this MRC-report:

1. the number of errors, warnings and information
   Make sure that no errors are reported. If errors are listed, fix them and repeat the static code analysis. In the case that there are only warnings and/or infos, contact the system integrator and clarify the necessary course of events.

2. the rules and their activation/configuration state
   Make sure that the required rules have been activated with the appropriate severity (ERROR, WARNING or INFO). Make sure that there are no occurrences of rule violations. If yes, fix them and repeat the static code analysis.

3. the names and the →fingerprints of each application element
   There is no need to check these pieces of the following information in this phase but they are needed later on. Reason: In the phase "Checking the build report", you will need to compare the names and fingerprints of the elements in this MRC-report with the information contained in the build report.

Keep this MRC-report of the static code analysis because the names and fingerprints of the elements in this MRC-report will need to be compared with the information contained in the build report.

In the case of a library only: The static code analysis for the library is automatically triggered when the logi.CAD 3 library is generated (see Warning 9). Keep the MRC-report of the final static code analysis when the library is generated because the names and fingerprints of the elements in this MRC-report will need to be compared with the information contained in the build report .

When testing the application/library elements (→SIL-test and →PIL-test), SiL-/PiL-test reports are generated. The information in the SiL-/PiL-test reports must be checked as specified in the " logi.µSRTS safety manual" (e.g. the result of the tests). In particular, the following checks are required in this workflow phase:

• In the case of the SiL-test, you must check for each →POU that the achieved coverage (test coverage incl. covered branches, coverage of requirements) is meeting your expectations that are based on the test specification for the POU.

• You must check for each POU which tests have been executed during the SiL-test and PIL-test.

  • It is mandatory that the same tests will be executed during the SiL-test and the PiL-test.

  • The number of the executed tests must correspond to the expectations that are based on the test specification for the POU.

Keep these SiL-/PiL-test reports as well because the names and fingerprints of the elements in this SiL-/PiL-test report will need to be compared with the information contained in the build report.

Only qualified code must be used when developing a library.
Qualified code means that the code is tested in the context of block tests. See the workflow phase about testing (SIL-test, PIL-test) in the " logi.µSRTS safety manual".

Before loading the application onto the PLC, m ake sure that only tested versions of POUs are used in the safety-relevant application . This must be solved by organisational measures .

One possibility to ensure that only tested versions of POUs are used is the usage of only POUs that are provided within a versioned library after the POUs have been tested (a SiL-test, a PiL-test and a static code analysis must have been performed for them) and they have been released as well. Details on creating a library with POUs: See logi.CAD 3 user documentation, "Creating custom library with user blocks".

After the application has been built and loaded onto the PLC (for executing the integration and system tests), the loaded application must be checked as specified in the " logi.µSRTS safety manual". In particular, the following checks are required in this workflow phase:

• Check the execution state in the Instances view. See the " logi.µSRTS safety manual" for the possible execution states and which execution state must be displayed when building and loading the application.

• Check the Problems and Error Log views or separate windows for messages. If errors are reported, fix them and repeat all workflow phases (as required by the change of the application). In the case that there are only warnings and/or infos, contact the system integrator and clarify the necessary course of events.

• Make sure that the fingerprint for the application in logi.CAD 3 matches the fingerprint for the application loaded onto the PLC (both are displayed in the Instances view of logi.CAD 3). Continue with the workflow only if the fingerprints do match. If they do not match, do not go on. See the " logi.µSRTS safety manual for details which fingerprints in the Instances view are to be checked.

• Make sure that the safety-relevant application contains only the correct →programs (= program →instances listed in the Instances view) as they are intended to be used in the safety-relevant application.

After the application has been built and loaded on the PLC, open the generated build report from within this Build Log view by clicking on the provided link in the field Report. This build report contains information about the built application and its elements.

Example for build report

Check the following information in this build report:

1. the build infrastructure – in particular the version numbers and checksums
   Make sure that these pieces of information match the information provided by the system integrator to guarantee that the variant/version of logi.CAD 3 has been released by the system integrator for the usage of developing a safety-relevant application and/or libraries for them.

2. the →resource information – in particular the code identification (= fingerprint of the application)
   Make sure that this piece of information matches the fingerprint for the application loaded onto the PLC as displayed in the Instances view of logi.CAD 3. If they do not match, do not go on to validate and/or release the application.

3. the remaining program structure – in particular the names and the fingerprints of each application element
   Make sure that these pieces of information match the names and fingerprints recorded in the MRC-report and in the SiL-/PiL-test reports. If they do not match, do not go on to validate and/or release the application.

4. errors, warnings and infos
   Make sure that no errors are reported. If errors are listed, fix them and repeat all workflow phases (as required by the change of the application). In the case that there are only warnings and/or infos, contact the system integrator and clarify the necessary course of events.

Keep all reports (MRC-report, SiL-/PiL-test reports and the build report). Observe that the build report is in particular required to clearly identify the built/loaded application.

After the library has been generated, open the generated library generation report . This library generation report contains information about the built library, its elements and their test coverage.

Example for library generation report

Check the following information in this library generation report:

1. the version number of logi.CAD 3
   Make sure that a version has been used that has been released by the system integrator for the usage of a developing safety-relevant application and/or libraries for them.

2. errors and warnings
   Make sure that no errors are reported. If errors are listed, fix them and repeat the generation of the library. In the case that there are only warnings, contact the system integrator and clarify the necessary course of events.

3. the library elements – in particular the names and the fingerprints of each library element
   Make sure that these pieces of information match the names and fingerprints recorded in the MRC-report and in the SiL-/PiL-test reports. If they do not match, do not go on to release the library.
   If you are using manually written C-/H-code for a library element, also make sure that the names and fingerprints for the relevant C-/H-files (under the section "Source File") match with the ones recorded in the other reports.

4. reports for SiL-tests and PiL-tests (not depicted in the above illustration)
   Make sure that necessary Sil-/PiL- tests have been executed with the required coverage (100% branch coverage). Use the names and fingerprints of the tested elements to identify the associated tests.

Keep the library generation report to be able to clearly identify the generated library.

When validating the application running on the PLC, observe the unsupported elements of logi.CAD 3 as well (as listed in the article "List of unsupported and restricted elements") – in particular, the testing/debugging features.

When releasing the application or a library, make sure that all instructions have been executed as specified in the above safety instructions and that the verification and validation stages of the " logi.µSRTS safety manual" have successfully passed. As a consequence, the following reports must exist and their contents must have been checked:

• MRC-report

• SiL-test reports

• PiL-test reports

• build report (in the case of an application) or the library generation report (in the case of an library)

Before a custom library is installed in a project to be used for developing safety-relevant applications, this custom library must be released – in particular, by a qualified person.
The release process is an organizational measure that needs to be done by qualified persons as specified under the article "Requirements for use".

If a custom library should not be used any longer, delete this custom library from the library provider (see logi.CAD 3 user documentation, "Library provider and library cache") and clean the library cache as described in the reference documentation (see logi.CAD 3 user documentation, "Cleaning the library cache") so that obsolete libraries cannot be installed from the library cache by mistake.