TÜV Rheinland Industrie Service GmbH
Automation - Software - Information Technology
The Global Centre of
Excellence for
Functional Safety
Start | Company | Jobs | Contact | Downloads | Schedule | Functional Safety
EnglishGerman formal - Sie
  Start - funktionale Sicherheit - functional safety locations functional safety management
IEC 61508

TUVdotCOM ID

tuvdotcomid.gif
The TUV certificate for quality and safety of approved products and companies.

More information...  

 
IEC 62061
Start arrow Products and Systems arrow Products arrow Software Qualification arrow Programmierrichtlinien für Assembler
ISO13849 TÜV
Sorry, this content is only availlable in German language.
All programs, specifically those used in safety relevant applications, should have a strong modularity and must be written, so they can be easily understood. This is specifically true for programs written in assembly language and very important, because the assembler translation program (the "assembler") does no logical or syntactical check of the program. Such checks are typically provided, when using high level language compilers.





The general guidelines are:

1. One subroutine should not exceed the length of about 50 statement, which is one printed page.
2. Even if the length of the program increases, not all possible instructions should be used to help the ease of understanding.
3. No tricks !

Benefits:

    * clear programs
    * reduced time for program review
    * changes can be made locally without effecting the whole program

Suggested Minimum Guidelines:

1. Date, Author, Version of the program first entry
2. Only one entry at the beginning and one exit at the end per subroutine
3. Subroutines are called per standard "call" instruction
4. Build macros for often used constructs, and only for these
5. "push" registers at the beginning, "pop" at the end of a subroutine
6. If ever possible, no stack manipulations
7. First statement should be the label and a short comment only
8. Fill unused program space with "Reset" instructions
9. If possible do not use "org" instructions
10. Do not use self modifying or dynamic generated code
11. Rebuild constructs from high level languages (while, repeat, case, etc.)
12. Parameter passing should be consistent for all parts of the source code. No mix of different methods

Example:
ROM_TEST         ; Checks Rom by simple add
        ;+
        ; ROM_TEST, E. Pofahl, 12-Mar-86
        ; Version 2.1, 14-Apr-86, Fritz Mueller, Programm simplified
        ; -
    Push_Reg     ; Makro to save BC, DE, HL
    LD HL, ROM_TEST     ; first cell
    LD B, ROM_TEST_Ende-ROM_TEST     ; program length
    LD A, 0    
Loop:     ADD A, (HL)     ; add cells
    INC HL     ; inc pointer
    DJNZ Loop     ;
    CP ROM_TEST_Summe    
    JR Z, Ex     ; Yes, exit loop
    LD (Fehler), A     ; Set Errornumber
    LD A, ROM_Fehler    
EX:        
    Pop_Reg     ; Makro to restore BC, DE, HL
ROM_TEST_End:        
    RET    
       

Parts of the documentation can be included in the source code, if clearly marked and extractable, e.g. with start with ";+" and end with ";-" (see example)
 
TÜV Rheinland Industrie Service GmbH Automation - Software - Information Technology

Valid XHTML 1.0 Transitional