Informējam, ka Sistēma pielāgota darbam ar interneta pārlūkprogrammu Internet Explorer (8. un jaunākām versijām) un Mozilla Firefox (3.6 un jaunākām versijām).
Izmantojot citu interneta pārlūkprogrammu, brīdinām, ka Sistēmas funkcionalitāte var tikt traucēta.
This part of IEC 61508, which is a Technical Report, makes a proposal as to which topics to consider and which methods and techniques to use when designing object-oriented software to ensure suitable quality for use in functional safety applications.
Object-oriented languages are perceived as "state-of-the-art" nowadays. Such languages seem to be excluded from use by several statements in IEC 61508-3. However there are additions in some tables such as in IEC 61508-3:2010, Table B.1, where notes are added under which their use might be justified. Such exceptions that would allow, for example, dynamic objects, name the main concerns such as memory allocation and predictable timing issues and guide the user to safe use of object-oriented languages. These considerations are taken up in this document to specify methods and techniques that allow the reduction of systematic faults to the levels required by the respective systematic capabilities.
This document is not intended to replace any part of IEC 61508-3. Rules that exist in IEC 61508 3 are valid here as well and are not repeated, including rules that concern:
• the software life cycle,
• involvement of the assessor,
• modularization,
• principle of information hiding,
• proving and conventional testing,
• basic aspects of documentation,
• low coupling and high cohesion,
• responsibilities and training of people,
• operational experience as described in IEC 61508-4 and IEC 61508-7.
Reģistrācijas numurs (WIID)
83553
Darbības sfēra
This part of IEC 61508, which is a Technical Report, makes a proposal as to which topics to consider and which methods and techniques to use when designing object-oriented software to ensure suitable quality for use in functional safety applications.
Object-oriented languages are perceived as "state-of-the-art" nowadays. Such languages seem to be excluded from use by several statements in IEC 61508-3. However there are additions in some tables such as in IEC 61508-3:2010, Table B.1, where notes are added under which their use might be justified. Such exceptions that would allow, for example, dynamic objects, name the main concerns such as memory allocation and predictable timing issues and guide the user to safe use of object-oriented languages. These considerations are taken up in this document to specify methods and techniques that allow the reduction of systematic faults to the levels required by the respective systematic capabilities.
This document is not intended to replace any part of IEC 61508-3. Rules that exist in IEC 61508 3 are valid here as well and are not repeated, including rules that concern:
• the software life cycle,
• involvement of the assessor,
• modularization,
• principle of information hiding,
• proving and conventional testing,
• basic aspects of documentation,
• low coupling and high cohesion,
• responsibilities and training of people,
• operational experience as described in IEC 61508-4 and IEC 61508-7.
