Recommendations for LVL-workflow

This article is about the LVL-workflow (see "→LVL - Limited Variability Language"). Observe the following:

If the complexity of the safety-relevant application is sufficiently low, no explicit module and integration test phase is required because the recommended measures for error prevention in these phases can be integrated in the application test (i.e., when the application is validated). See Warning 1.
See the illustration under "Workflow: Creating a safety-relevant application or library for this application" (box "optional for LVL") for details on which actions and associated work products can be omitted for the LVL-workflow.
When you are applying the LVL-workflow, the →FBD programming language must be used to integrate existing blocks into a specific application. See Warning 2.
Within FBD, branches can only be created using the EN input. There are no further elements which influence the control flow (e.g. loops, switches).
Comply with all recommendations for using FBD. See Warning 3.

If it is not possible to comply with all of the following warnings, apply the full →FVL workflow as illustrated under "Workflow: Creating a safety-relevant application or library for this application".

Warning 1

logi.CAD 3 must only be used for developing safety-relevant applications and libraries for them when using a full functional safety management (FSM) process and appropriate fault avoiding measures for the target SIL/ASIL.
This includes module tests with 100% branch coverage, integration and system test or other equally effective measures (see "Recommendations for LVL-workflow" when applying the LVL-workflow).

Regardless of the applied workflow, it is imperative to validate the application. The reason for this is that logi.CAD 3 is used on an unsafe PC. As a consequence, errors in the hardware or the system environment might lead to errors in the application.

Warning 2

If you want to apply the reduced LVL-workflow for developing safety-relevant applications , make sure that you only implement POUs that are created in →FBD.
If you implement POUs that are created in a different programming language (e.g. →ST ), you must apply the full workflow and its verification and validation stages (incl. SiL-test and PiL-test)

Warning 3

When applying the reduced LVL-workflow for developing safety-relevant applications , make sure that the logic is created in LVL, the logic is kept readable, the simplicity of the application is supported and consider the error handling in FBD.

To ensure these aspects for the POUs created in FBD, comply with the following points:

The application complexity must be reduced in such a way that the logic within a POU is comprehensible to the user.
Coding guidelines (e.g. the recommendations based on TC5 Safety Software (2.01)) must be defined and followed.
The POUs must be well layouted.
For example, avoid little space between the logic elements in the POU so that the line connections between the logic elements can be clearly traced.
Not connected in-/outputs of blocks must not be hidden. Details on this feature: See logi.CAD 3 user documentation, "Showing/hiding not connected in-/outputs"
In case of hidden, not connected in-/outputs, the user does not detect all in-/outputs of a block. Reason: A not connected in-/output is indicated by a connection point and this connection point is hidden for hidden, not connected in-/outputs.
The logic of the POU must be displayed in the visible area so that t he user notices which logic elements are actually affected by an edit/delete action.
Example 1: If all/several logic elements are selected and some of these logic elements are located outside the visible area, the next edit/delete action by the user might affect the elements outside the visible area as well.
Example 2: If not all logic elements are selected and some of these logic elements are located outside the visible area, the next edit/delete action by the user might not affect the elements outside the visible area (but the user expected to edit/delete these elements as well).
Complex →expressions must not be used in →value fields so that errors are not caused due to the complexity of expressions. Hence, restrict the usage of expressions in value fields to literals, constants or variables.
When performing a static code analysis, the rule The usage of expressions in value fields is restricted to literals, constants or variables might help to detect whether this point is violated.
The application logic itself must check the output ENO of called blocks so that the check of possibly hidden ENO outputs is not forgotten. Details on shown/hidden output ENO: See logi.CAD 3 user documentation, "Showing or hiding EN and ENO within the FBD-editor"
The autosave feature for the editors must be disabled. Details on this feature: See logi.CAD 3 user documentation, "Saving FBD-logic"
In case of the enabled autosave feature, the user does not recognize that an unwanted change is saved.
T he saving of the statement list must not be deactivated. This is done by using the configuration variable -Dlc3.fbdDeactivateStatementListSaving=true. Details on this configuration variable : See logi.CAD 3 user documentation, "Can I increase the performance when saving the FBD-editor?" - When the configuration variable is used as specified there, the saving of the statement list is deactivated causing that the comments on the evaluation of FBD-networks and their statements are no longer inserted in the textual editor.
If the saving of the statement list is deactivated, the safety-relevant application might behave wrongly due to a corrupted editor content.