Software testing
tools for Iec 60880


Ensure IEC 60880
software compliance

IEC 60880

 

IEC 60880:2006 (Nuclear Power Plants – Instrumentation and Control Systems Important to Safety – Software Aspects for Computer-Based Systems) is a functional safety standard which, together with IEC 62138, covers the software aspects of computer based systems used in nuclear power plants to perform functions important to safety. IEC 60880 provides requirements for the safety category A as defined by IEC 61226.

 

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.

Software testing in the energy sector to comply with IEC 60880, IEC 61508, HIC++ and CERT C - man in safety vest working in nuclear station controls

Testing tools for compliance with IEC 60880 recommendations

 

QA Systems enables organisations to accelerate IEC 60880 compliance with automated static and dynamic testing tools:

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). Each tool has been certified as usable in development of safety related software according to IEC 60880:2006.

 

Tool certification kits for IEC 60880 are available to ease our customers’ path to certification. This contains everything needed to prove that our tools fulfill IEC 60880 recommendations as well as guidance to help you to achieve compliance.

 

Please contact us for more information about tool certification kits.

SGS Tuev Saar Logo - Funktionale Sicherheit geprueft - Functional Safety approved - certified
Cantata unit testing tool for C & C++ - functional safety approved - testing requirements - SGS-TUV SAAR - ISO 26262 - IEC 60880 - IEC 62304 - IEC 61508 - EN 50128 - safety critical - certified

      Cantata Certificate

PRQA Certificate - QA-C with MISRA - QA-C++ with MISRA C++ - SGS TUEV Saar - certified - Programming Research Ltd.

 QA-C/QA-C++ Certificate

Dynamic testing for IEC 60880 compliance

 

The Cantata testing tool enables developers to automate  unit and integration testing and to verify IEC 60880 compliant code on host native and embedded target platforms. 

 

Cantata helps accelerate compliance with the standard’s dynamic testing requirements by automating:

  • Test framework generation
  • Test case generation
  • Test execution
  • Results diagnostics and report generation

 

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. 

Cantata testing model with logo- Dynamic testing for IEC 62304 compliance - acceptance test and system requirements - system test and architectural design - integration test and detailed design - unit test and unit design then code

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.2 Statistical testing 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

Starten Sie eine kostenlose Testversion, um Ihren Code mit Cantata zu testen.

Static testing 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 testing with QA-C and QA-C++ 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 QA-C, QA-C++ and QA-Verify for IEC 60880. 

 

 

The IEC 60880 requirements for design and implementation in the Normative Annex B and where these are supported by QA-C and QA-C++ are summarised in the tables below.

Static testing for IEC 61506 compliance - Advanced static analysis - Coding standards compliance - sophisticated bug detection

IEC 6088O: Section 8 – Software verification

Clauses/Subclauses QA-C QA-C++
8.1 Software verification process Yes Yes
8.2.1 Verification plan Yes Yes
8.2.3.1 Verification of implementation with general-purpose languages Yes Yes

IEC 6088O: Table B2 Software structure

Clauses/Subclauses QA-C QA-C++
B2.a Control and access structures - Programs and program parts shall be grouped systematically Yes Yes
B2.b Modules shall be clear and intelligible Yes Yes
B2.c Operational system software use shall be restricted Yes Yes
B2.d Execution time - Physical process behaviour influence on execution time shall be kept low - -
B2.e The use of interrupts shall be restricted Yes Yes
B2.f Where possible simple arithmetic expressions should be used instead of complex ones. Yes Yes

IEC 6088O: Table B3 Self supervision

Clauses/Subclauses QA-C QA-C++
B3.a Plausibility checks shall be performed (defensive programming) Yes Yes
B3.b Safe Output - If a failure is detected, the system shall produce a well-defined output Yes Yes
B3.c Memory contents shall be protected or monitored Yes Yes
B3.d Error checking shall be performed by the code Yes Yes

IEC 6088O: Table B4 Detailed design and coding

Clauses/Subclauses QA-C QA-C++
B4.a Branches and loops should be handled cautiously Yes Yes
B4.b Subroutines should be organised as simply as possible Yes Yes
B4.c Nested structures shall be handled with care Yes Yes
B4.d Addressing and arrays - Simple addressing techniques shall be used Yes Yes
B4.e Data structures and naming conventions shall be used uniformly throughout the system Yes Yes
B4.f Dynamic changes to executable code shall be avoidedYesYes

IEC 6088O: Table B5 Language dependent recommendations

Clauses/Subclauses QA-C QA-C++
B5.a Sequences and arrangements - Detailed rules shall be elaborated for the
arrangement of various language constructs
Yes Yes
B5.b Comments - Relations between comments and the code shall be fixed by detailed
rules
Yes Yes
B5.c If an assembly language is used, extended and documented coding rules shall be followed - -
B5.d Detailed coding rules shall be issued Yes Yes
B5.e Application oriented languages should be used rather than
machine-oriented languages
Yes Yes
B5.f Automated code generator - The output of the code generator should
be traceable to the input
- -

Starten Sie eine kostenlose Testversion, um Ihren Code mit QA-C oder QA-C++ zu testen.

Start
Trial
QA-Systems