To develop a function block, the following steps shall be performed and documented:
Identify the need for a function block and specify it as a market requirement. Perform a hazard and risk analysis to identify the risks of the function block, as specified in 61508-1 clause 7.4.2.
Note especially reasonably forseeable misuse.
Note that since function blocks are part of an environment which is already verified for safety,
only the aspects of the function block itself should be considered in the risk analysis.
The following risks and hazards are applicable to all blocks and can, for brevity, be omitted from the risk analysis of each block.
These risks shall however be covered by the integration tests (specified later in this procedure):
Incorrect Function: The function block may not correctly perfrom its intended operation, leading to incorrect behavior.
Mitigation: Thorough testing and validation of the function blocks to ensure correct functionality.
Signal Propagation Delay: The function block may introduce unexpected delays.
Mitigation: Measure the propagation delay of the block using an oscilloscope or logic analyzer, or similar.
Misuse: Users may misuse the function block, which may lead to unsafe function.
Mitigation:
Limit the usage of the function so it can only be used in the intended way by limiting parameters and what can be connected to inputs and outputs, provide clear documentation and guidelines on the correct usage of the function in the safety manual, warn the user if the function is not used in the intended way.
From the hazard and risk analysis, specify any special safety requirements of the block and safety manual. Specify the function block specification that fulfils the safety requirements, and including at least:
a function description (with text and state- and timing-diagrams if helpful), list of all inputs, list of all outputs, list of all parameters including all possible values, for example a range [1,1000], or a list of values [“a”, “b”, “c”]).
From the function specified in (4), identify and specify the underlying compiler functions that are required. For any compiler function block identified in (5) that is not already implemented, specify the compiler function block specification, including at least:
a function description (with text and state- and timing-diagrams if helpful), list of all inputs, list of all outputs, list of all parameters (including all possible values, for example a range [1,1000], or a list of values [“a”, “b”, “c”]),
Specify integration tests to validate all aspects of the function block, and all aspects of any new compiler blocks, taking the risk analysis and safety requirements into account.
Preexisting underlying compiler blocks are already covered by other integration tests and do not need to be retested. However, the combination of the functions shall be tested.
All possible values of parameters shall be tested, unless a suitable subset is specified with an explanation of why that is enough.
Note
In general, it is not feasible to test all possible values of a parameter which has a valid range of thousands of values.
For such parameters, usually a minimum, a maximum, and some other intermediate values are enough to test.
If timing is critical, it should be verified with an oscilloscope, logic analyzer or similar.
How to prepare the test shall be clearly specified.
Note
Example (from an examlpe SR-latch function):
Compile two single input blocks connected to the S and R inputs of an SR Latch block, and the output connected to a single output block.
Download to a single unit and measure all inputs and outputs with an oscilloscope or logic analyzer.
The test procedure shall be clearly specified as a list of steps, where each step may have a single easily verifiable pass critera.
Note
An example of a test procedure with easily verifyable pass criteria (from an examlpe SR-latch function):
Verify that the output is LOW/OFF/0V. Apply a high signal pulse to the S input and verify that the output turns on within X ms of the high flank on the S input. Apply a high signal pulse to the R input and verify that the output turns off within X ms of the high flank on the R input. Apply a high signal to both the S and R inputs and verify that the output is off.
Specify module tests to verify the GUI function block. Module tests for GUI blocks are in general “code review” tests,
where the generated sl3 code is verified against the GUI defined logic, but may also incude other types of tests if applicable for the block.
The logic to be used shall be clearly specified, as a picture or as a file.
The test pass criteria shall be clearly specified as a list of easily verifyable conditions, and shall include at least the following:
All input signals to the block are in the correct place in the sl3 output, all attributes (constant values) are named correctly and have the correct value in the sl3 output, any other block specific logic is correct (such as inputs/outputs, memories, or other sl3 parameters).
Test results shall contain at least:
The date when the test was performed, who performed the test, the git commit hash and/or version number of the version of Simplifier Manager that was used to generate the sl3 code, all the relevant generated sl3 code as plain text, arguments how the generated sl3 code fulfills all the pass criteria.
Specify module tests for compiler blocks that test all aspects and parameters of the compiler function block.
Module tests for compiler blocks are in general “code review” tests, where the generated C code is verified
against the sl3 defined logic, but may also incude other types of tests if applicable.
If the test does not cover all variants of parameters, a suitable subset with explanation why that is enough shall be included in the test specification.
Module tests shall clearly specify the sl3-code to be compiled as plain text, or how to generate that code.
The pass criteria shall be clearly specified, and shall include at least the following:
All aspects of the compiler block specification are implemented in the generated C code, All attributes (constant values) are named correctly and have the correct value in the generated C code, all input signals to the block are in the correct place in the generated C code, any other block specific logic is correct (such as inputs/outputs, memories, defines, etc).
Test results shall contain at least:
The date when the test was performed, who performed the test, the git commit hash and/or version number of the compiler used to generate the C code, all the relevant generated C code as plain text, arguments how the generated C code fulfills all the pass criteria.
Develop the GUI block in Simplifier Manager Develop the compiler block or blocks in the compiler Integrate the safety aspects of the function block in the safety manual. Verify the module tests. Validate the integration tests.
|