EN 
DE 1. Introduction
Functional safety standards require the development of a safety-critical product to be done according to the V-model of system development. Fig. 1 shows this V-model in the form that underlies the autoConform® methodology and software.
Fig. 1: System development V-model of the autoConform® methodology and software
Parameters are typically included in all documents of the V-model, on the left and right sides of the V, and on all product architecture levels. Parameters are not limited to software parameters in the form of either software configuration data or software calibration data. Configuration and calibration parameters are also present at the system and hardware levels.
The correct handling of all system, hardware and software parameters is a prerequisite for the correct management of product variants.
Section 2 makes a proposal as to how parameters can be handled advantageously in the V-model documents. Section 3 explains the benefits of this proposal.
2. Handling of parameters in the V-Modell documents
The proposal for handling parameters in the V-Model documents consists of four sub-proposals, subsequently referred to as (A), (B), (C) and (D).
(A) It is proposed that all parameters be specified in a central parameter document. Instead of one parameter document, two parameter documents can be created, one for system and hardware parameters and the other for software parameters.
Such parameter documents are identical in structure to interface documents in which generalized signals are specified: Parameter and interface documents each consist of only one document sheet which contains all parameter or signal attributes. The attributes which characterize a parameter are nearly the same as the attributes which characterize a signal.
(B) It is proposed that all parameter names be chosen in such a way that it is obvious from the name that it is a parameter name. One way to accomplish this is to let each parameter name start with a string that is used exclusively in parameter names.
Examples:
- “PARAM_” or
- “PAR_” or
- “P__”.
(C) All attribute values (such as the default value of a parameter) are specified in the central parameter document according to (A). To make the rest of the documents in which a specific parameter occurs more readable, it is proposed that the default value of the parameter is specified in parentheses after the parameter name.
Example:
PAR_Spring1Stiffness_Npm(4.7N/m)
Note: If the parameter name already contains the unit of the parameter value, then the unit information does not have to be repeated in parentheses after the parameter name.
If further parameter attribute values are required for the readability of a text passage, it is suggested to extend the information provided in parentheses after the parameter name such that all required parameter attribute names followed by the corresponding parameter attribute value are listed in the parentheses after the parameter name: (Parameterattribut_#1 name: Parameterattribut_#1 value, Parameterattribut_#2 name: Parameterattribut_#2 value, ...).
Example:
PAR_Spring1Stiffness_Npm(DEFAULT: 4.7N/m, MINIMUM: 4.4N/m, MAXIMUM: 5.0N/m).
(D) Finally, it is proposed that every numerical value which is referred to in more than one V-model document does not appear as "naked" number, but as a parameter in every V-model document.
Example: Instead of entering "500ms" as the Fault Tolerant Time Interval (FTTI) for the safety goal #1 (SG1) in the HARA and other documents, "PAR_FTTI_SG1_ms(500ms)" or "PAR_FTTI_SG1_ms(500)" is entered instead.
3. Benefits of the Parameter Handling Proposal
Proposal (A), the specification of each parameter in a central parameter document, ensures that the parameter names are unique and consistent across all V-model documents.
Suggestions (B), (C) and (D) ensure that all numerical values that occur repeatedly in the V-model documents can be updated automatically, which in turn is a practical prerequisite for keeping all parameter values consistent and correct.
