 |
|
 |
|
|
Richtlinie für die Entwicklung sicherheitsgerichteter Software |
This collection of guidelines is not specific to one programming language. All guidelines can be used, adapted to a language or unchanged, for all traditional languages (Pascal, Modula, PL/M, "C"). Also for assembly languages these guidelines can be used.
The guidelines are divided into the chapters organisation, programming and test.
The advantage of these guidelines is:
* programs are clear and can be grasped easily
* the expenditure for the test can be reduced by the use of tools for analysis and test of the programs
* errors in design and coding are avoided
* changes in software can be limited to modules and can be tested easier.
Using high level languages the modules of a language are named as follows:
PASCAL, MODULA: Procedure, Function
PL/M: Procedure
C: Function
Assembler: subroutine
In the following the term procedure is used for all these constructs.
1. Organisational Guidelines
- Use a document administration system.
- For each document (specification, flowchart, program source,
etc.) date, author, revision history and version of the document shall
be placed at the beginning. On each page must appear: title of the
document, document number, version, date, page number, amount of pages.
- Make your own programming guideline. You may use some of the guidelines presented in chapter 2.
- Use tools for design (e.g. SA Tools) and documentation (cross-reference, PROCREF, CFLOW etc.).
-
Take measures to ensure, that all developed programs are in coincidence with a standard (e.g. ANSI).
-
Use compilers, which are proven in operation (many installations,
longer than one year on the market, list of known errors).
-
Use only one version of a compiler and linker. Avoid a change of
a compiler or a linker revision during a development process.
- Make backups periodically of your code and of your development environment.
2. Programming guidelines
-
Use only standard elements of a programming language.
-
Use a programming style, which is easy to grasp. In general no "tricks" are needed to reach the aim.
-
All checks, which are provided by a compiler, must be used.
-
For each module (procedure, function, subprogram ...) there shall be only one entry and one exit.
-
Use only elements of structured programming (FOR, REPEAT UNTIL, DO WHILE, CASE, no GOTOs).
-
Cover all possible cases in a CASE-instruction. Typically this is done by the instructions ELSE, OTHERWISE.
- Use all runtime checks provided by your compiler: boundaries of
arrays, integer and real overflow, division by zero, memory protection
errors, stack supervision, etc.
-
Implement test routines for the online operation for all elements (RAM, ROM, functional elements).
-
Use time program supervision (e.g. watchdog) as well as logical program supervision.
-
Modularise your software (abstract data, information hiding). One
file should not exceed 500 lines of code, one procedure should not
exceed 30 to 80 statements (one page).
-
Choose meaningful and unambiguous names of files, procedures, variables, constants and types.
-
Names of formal parameters shall not be identical to global names
or parameters. Wherever possible one should choose long names for a
variable.
-
Avoid recursion. There is the danger of stack overflow. If you
use recursions, however, limit the maximum number of recursions.
-
Use slim parameter interfaces (not more than 7 parameters) for your procedures.
- Implement the data interface to procedures by parameters only.
Use only few global variables. The parameters should be passed,
whenever possible, by the method "call by value". Procedures shall be
defined by means of "Prototyping".
-
Don't use one variable within a procedure call for several
reference parameter. Unpredictable results will occur, if these
variables are changed on different places within the routine.
- Don't change input variables within procedures.
-
Don't use procedures as parameter to other procedures.
-
Use no pointers and dynamic constructs on the "heap". The
creation and destruction of "heap" variables can hardly be traced.
There is the risk of nonsense pointers and the slow consumption of
memory resources. Also the tool support for pointers is not as good as
for other constructs. In the case, pointer constructs can not be
avoided, there have to be special tests and online measures to ensure
the integrity of the pointers. Memory areas have to be allocated and
released in an orderly manner.
-
Use batchfiles (make, commandfiles) to build libraries and
programs. Otherwise there is no unambiguous production of the binaries.
-
Constants shall be global and kept in a separate file.
- Avoid variant records (lack of type checking). In the case you
must use variant records because of space considerations, use selectors
within the variant records.
-
Try to reach a low complexity of your program. The cyclomatic
number of the individual program parts should not exceed 10. In most
cases the cyclomatic number is calculated by addition of DO..WHILE,
IF..THEN..ELSE, REPEAT..UNTIL and CASE constructs.
-
Combine often used sequences in macros or procedures.
-
Don't access one memory cell with different names (no ALIASING).
-
Fill holes in the code and unused ROM cells with "Reset"
instructions. Instructions for fix allocation of addresses (e.g. "ORG")
should be used seldom, because they produce undefined memory areas.
3. Test Guidelines
-
All tests should be done by an automated procedure.
-
Each module shall have its own test environment. This environment
shall be coupled to the actual module (e.g. by conditional
compilation). In the test environment at minimum the following cases
shall be covered: minimum and maximum values, typical values, check of
plausibility checks. Also the robustness using wrong parameters must be
checked.
-
Each test shall be documented (date, result, ...). Often a "Print Screen" is sufficient.
-
Tests must be reproducible.
-
After each change of a source all tests must be repeated.
|
|
|
 |
|
 |
Produkte und Systeme