IEC 60880
Fitness for purpose litigation against companies and individuals is now an increasing risk. IEC 60880:2006 is a technical standard used by lawyers to interpret laws. The relevant law in question for Europe is the General Product Safety Directive 2001/95/EC (GPSD). This states that the product creator has the responsibility to develop a safety critical product in a way which is compliant with ‘State-of-the-Art’ development principles. ‘State-of-the-Art’ simply refers to commonly accepted best practices, which in the case of nuclear electronic safety related systems are now embodied in IEC 60880:2006. Where companies fail to employ accepted industry practices, they cannot use the “State-of-the-Art” legal defence against such litigation.
Testing tools for compliance with IEC 60880 recommendations
QA Systems enables organisations to accelerate IEC 60880 compliance with automated static analysis and software testing tools:
STATISCHE ANALYSE
INTEGRIERTE STATISCHE ANALYSE
Automatisierte Analyse mit Cantata synchronisiert
CANTATA TEST ARCHITECT
Software-Architektur: verstehen, definieren und kontrollieren
SOURCE-CODE-METRIKEN
Automatisierte Source-Code-Metriken für C/C++
SOFTWARE TESTS
CANTATA
Automatisierte Unit- und Integrationstests für C/C++-Code
CANTATA TEAM REPORTING
Add-on für die Zusammenarbeit von verteilten Teams
ADATEST 95
Automatisierte Unit- und Integrationstests für Ada-Code
Tool Certification
QA Systems’ tools have been classified and certified by SGS-TÜV GmbH, an independent third party certification body for functional safety, accredited by Deutsche Akkreditierungsstelle GmbH (DAkkS). Cantata has been certified as usable in development of safety related software according to IEC 60880:2006.
The tool certification kit for IEC 60880 is available to ease our customers’ path to certification. This contains everything needed to prove that Cantata fulfills IEC 60880 recommendations as well as guidance to help you to achieve compliance.
Please contact us for more information about the tool certification kit.
Software testing for IEC 60880 compliance
Cantata helps accelerate compliance with the standard’s software testing requirements by automating:
Our IEC 60880 Standard Briefing traces the requirements of IEC 60880, identifying the scope of those which are supported by Cantata and identifies how the requirements are supported by Cantata.
Please contact us for more information on Cantata for IEC 60880.
IEC 60880: Section 8 – Software verification
| Clauses/Subclauses | Cantata |
|---|---|
| 8.1 Software verification process | Yes |
| 8.2.1 Verification plan | Yes |
| 8.2.3.1 Verification of implementation with general-purpose languages | Yes |
IEC 60880 Table E4 – Verification and testing methods
| Clauses/Subclauses | Cantata |
|---|---|
| E.4.1 Selected verification methods | |
| E.4.1.1 Supervision of testing procedure | Yes |
| E.4.1.1 Supervision of testing procedure | Yes |
| E.4.1.3 Program proving | Yes |
| E.4.1.4 Program analysis | Yes |
| E.4.2 Testing methods | |
| E.4.2.1 General | Yes |
| E.4.2.1: 1 Cases representative for program behaviour in general, its arithmetics, timing | Yes |
| E.4.2.1: 2 All individually and explicitly specified requirements | Yes |
| E.4.2.1: 3 All input variables in extreme positions (crash test) | Yes |
| E.4.2.1: 4 Operation of all external devices | Yes |
| E.4.2.1: 5 Static cases and dynamic paths which are representative for the behaviour of the technical process | Yes |
| E.4.2.1: 6 Correct operation shown by turning off and on each redundant subsystem/external device (some combinations should be also tested where relevant) | Yes |
| E.4.2.2 Path testing | |
| E.4.2.2: 7 Every statement executed at least once | Yes |
| E.4.2.2: 8 Every outcome of every branch executed at least once | Yes |
| E.4.2.2: 9 Every predicate term exercised to each branch | Yes |
| E.4.2.2: 10 Each loop executed with minimum, maximum and at least one intermediate number of repetitions | Yes |
| E.4.2.2: 11 Every path executed at least once | Yes |
| E.4.2.3 Data movement testing | |
| E.4.2.3: 12 Every assignment to each memory place executed at least once | Yes |
| E.4.2.3: 13 Every reference to each memory place executed at least once | Yes |
| E.4.2.3: 14 All mappings from input to output executed at least once each | Yes |
| E.4.2.4 Timing testing | |
| E.4.2.4: 15 Checking of all time constraints | Yes |
| E.4.2.4: 16 Maximum possible combinations of interrupt sequences | Yes |
| E.4.2.4: 17 All significant combinations of interrupt sequences | Yes |
| E.4.2.5 Miscellaneous | |
| E.4.2.5: 18 Check for correct position of boundaries of data inputs | Yes |
| E.4.2.5: 19 Check for sufficient accuracy of arithmetical calculations at all critical points | Yes |
| E.4.2.5: 20 Only for programs; test of module interfaces and module interaction | Yes |
| E.4.2.5: 21 Every module invoked at least once | Yes |
| E.4.2.5: 22 Every invocation to a module exercised at least once | Yes |
| E.4.2.5: 23 Operation at high load | Yes |
IEC 60880 B4.g Unit and integration tests
| Clauses/Subclauses | Cantata |
|---|---|
| B4.g Unit and integration tests shall be performed during the program development | Yes |
| B4.ga The approach to testing should follow the approach to design | Yes |
| B4.gb Each module should be tested thoroughly before it is integrated into the system and the test results documented | Yes |
| B4.gc A formal description of the test inputs and results (test protocol) should be produced | Yes |
| B4.gd Faults which are detected during program testing should be recorded and analysed | Yes |
| B4.ge Incomplete testing should be recorded | Yes |
| B4.gf In order to facilitate the use of unit and integration test results during final validation, the former degree of testing achieved should be recorded | Yes |
Static analysis for IEC 60880 compliance
IEC 60880 (7.1.2) identifies that general purpose programming languages such as C and C++ can be used “provided appropriate design and coding rules are followed”. The Normative Annex B5.d explicitly requires that detailed coding rules shall be issued. Static analysis tools can dramatically reduce the manual effort in enforcing compliance with such coding standards. QA-Verify adds reporting to ensure this over time and across product versions.
Please contact us for more information on static analysis tools and QA-Verify for IEC 60880.
The IEC 60880 requirements for design and implementation in the Normative Annex B are summarised in the tables below.
IEC 6088O: Section 8 – Software verification
| Clauses/Subclauses |
|---|
| 8.1 Software verification process |
| 8.2.1 Verification plan |
| 8.2.3.1 Verification of implementation with general-purpose languages |
IEC 6088O: Table B2 Software structure
| Clauses/Subclauses |
|---|
| B2.a Control and access structures – Programs and program parts shall be grouped systematically |
| B2.b Modules shall be clear and intelligible |
| B2.c Operational system software use shall be restricted |
| B2.d Execution time – Physical process behaviour influence on execution time shall be kept low |
| B2.e The use of interrupts shall be restricted |
| B2.f Where possible simple arithmetic expressions should be used instead of complex ones. |
IEC 6088O: Table B3 Self supervision
| Clauses/Subclauses |
|---|
| B3.a Plausibility checks shall be performed (defensive programming) |
| B3.b Safe Output – If a failure is detected, the system shall produce a well-defined output |
| B3.c Memory contents shall be protected or monitored |
| B3.d Error checking shall be performed by the code |
IEC 6088O: Table B4 Detailed design and coding
| Clauses/Subclauses |
|---|
| B4.a Branches and loops should be handled cautiously |
| B4.b Subroutines should be organised as simply as possible |
| B4.c Nested structures shall be handled with care |
| B4.d Addressing and arrays – Simple addressing techniques shall be used |
| B4.e Data structures and naming conventions shall be used uniformly throughout the system |
| B4.f Dynamic changes to executable code shall be avoided |
IEC 6088O: Table B5 Language dependent recommendations
| Clauses/Subclauses |
|---|
| B5.a Sequences and arrangements – Detailed rules shall be elaborated for the arrangement of various language constructs |
| B5.b Comments – Relations between comments and the code shall be fixed by detailed rules |
| B5.c If an assembly language is used, extended and documented coding rules shall be followed |
| B5.d Detailed coding rules shall be issued |
| B5.e Application oriented languages should be used rather than machine-oriented languages |
| B5.f Automated code generator – The output of the code generator should be traceable to the input |
