VDE Testing and Certification Institute

Size: px

Start display at page:

Download "VDE Testing and Certification Institute"

Martha Melton
6 years ago
Views:

1 Test Report Report No.... : AS6-1 File No.... : / Date of issue... : Laboratory... : Testing and Certification Institute Address... : Merianstrasse Offenbach/Main; Germany Testing location/ address... : rüf- und Zertifizierungsinstitut GmbH Testing and Certification Institute Merianstrasse 28, Offenbach, Germany Applicant's name... : Renesas Electronics Europe GmbH Applicant's address... : Karl-Hammerschmidt-Straße 42; Aschheim- Dornach; Germany Applied standard(s)... : DIN EN ( ): ; EN :2012 DIN EN Ber.1 ( Ber.1): ; EN :2012/AC:2014 EN :2012/A11:2014 DIN EN ( ): ; EN :2011 IEC (ed.5);am1 IEC (ed.5) ;am1 Test item description... : Self-Diagnostic Routines for Micro controller Family S7 Trade Mark... : Renesas Type reference(s)... : File Name Revision cpu_test.c 1.x CU_Test_Control.asm 1.x cpu_test_coupling.c 1.x CU_Test_General_High.asm 1.x CU_Test_General_Low.asm 1.x fpu_control.asm 1.x fpu_exten.asm 1.x fpu_test_coupling.c 1.x TestFUCouplingEnd.asm 1.x TestFUCouplingStart_A.asm 1.x TestFUCouplingStart_B.asm 1.x TestGRsCouplingEnd.asm 1.x TestGRsCouplingStart_A.asm 1.x TestGRsCouplingStart_B.asm 1.x Report No.: AS6-1 age 1 of 15 Disclaimer: This test report contains the result of a singular investigation carried out on the product submitted. A sample of this product was tested to found the accordance with the thereafter listed standards or clauses of standards resp. The test report does not entitle for the use of a Certification Mark and considers solely the requirements of the specifications mentioned below. Whenever reference is made to this test report towards third party, this test report shall be made available on the very spot in full length.

2 TestFUCouplingS0_S3_A.asm 1.x TestFUCouplingS0_S3_B.asm 1.x TestFUCouplingS4_S7_A.asm 1.x TestFUCouplingS4_S7_B.asm 1.x TestFUCouplingS8_S11_A.asm 1.x TestFUCouplingS8_S11_B.asm 1.x TestFUCouplingS12_S15_A.asm 1.x TestFUCouplingS12_S15_B.asm 1.x TestFUCouplingS16_S19_A.asm 1.x TestFUCouplingS16_S19_B.asm 1.x TestFUCouplingS20_S23_A.asm 1.x TestFUCouplingS20_S23_B.asm 1.x TestFUCouplingS24_S27_A.asm 1.x TestFUCouplingS24_S27_B.asm 1.x TestFUCouplingS28_S31_A.asm 1.x TestFUCouplingS28_S31_B.asm 1.x TestGRsCouplingR0_A.asm 1.x TestGRsCouplingR0_B.asm 1.x TestGRsCouplingR1_R3_A.asm 1.x TestGRsCouplingR1_R3_B.asm 1.x TestGRsCouplingR4_R6_A.asm 1.x TestGRsCouplingR4_R6_B.asm 1.x TestGRsCouplingR7_R9_A.asm 1.x TestGRsCouplingR7_R9_B.asm 1.x TestGRsCouplingR10_R12_A.asm 1.x TestGRsCouplingR10_R12_B.asm 1.x clock_monitor.c 1.x crc.c 1.x CRC_Verify.c 1.x ramtest_march_c.c 1.x ramtest_march_c_hw.c 1.x ramtest_march_hw.c 1.x ramtest_march_x_wom.c 1.x ramtest_march_x_wom_hw.c 1.x test_adc12.c 1.x Ratings... : Supplementary information: Report No.: AS6-1 age 2 of 15

4 Environmental conditions (if applicable) Ambient temperature Atmospheric pressure Relative humidity Rated values... : C ha % Verified values... : Range confirmed by: Deutscher Wetterdienst (Meteorological service) Report No.: AS6-1 age 4 of 15

5 erformed tests TABLE R.1 / Table H.1 for software class R.1 / B GENERAL FAULT / ERROR CONDITIONS Component 1) Fault/error Acceptable Definitions Document measures 2) 3) 4) reference Document reference Verdict for applied measure for applied test 1 CU 1.1 Register Stuck at Functional test, or periodic self-test using either: static memory test, or word protection with single bit redundancy H H H H SWD_003_1_A015 _1.0_SW Design Documentation_for_ SWV_002_A015 _1.0_SW Verification report_for_ 1.2 Void 1.3 rogramme counter Stuck at Functional test, or H periodic self-test, or H independent time-slot monitoring, or H logical monitoring of the programme sequence H Interrupt handling and execution No interrupt or too frequent interrupt Functional test; or time-slot monitoring H H Clock Wrong frequency (for quartz synchronized clock: harmonics/ subharmonics only) Frequency monitoring, or time slot monitoring H H SWD_003_1_A015 _1.0_SW Design Documentation_for_ SWV_002_A015 _1.0_SW Verification report_for_ 4 Memory 4.1 Invariable memory All single bit faults eriodic modified checksum; or multiple checksum, or H H SWD_003_1_A015 _1.0_SW Design Documentation_for_ SWV_002_A015 _1.0_SW Verification report_for_ word protection with single bit redundancy H Variable memory DC fault eriodic static memory test, or word protection with single bit redundancy H H SWD_003_1_A015 _1.0_SW Design Documentation_for_ SWV_002_A015 _1.0_SW Verification report_for_ Report No.: AS6-1 age 5 of 15

6 4.3 Addressing (relevant to variable and invariable memory) Stuck at Word protection with single bit parity including the address H Covered by 1.1; 3; 4.1; 4.2 and 5 Internal data path 5.1 Data Stuck at Word protection with single bit redundancy H Addressing Wrong address Word protection with single bit redundancy including the address H External communication 6.1 Data Hamming distance 3 Word protection with multi-bit redundancy, or CRC single word, or H H transfer redundancy, or H protocol test H Void 6.3 Timing Wrong point in time Time-slot monitoring, or scheduled transmission H H Time-slot and logical monitoring, or H comparison of redundant communication channels by either: reciprocal comparison H independent hardware comparator H Wrong sequence Logical monitoring, or time-slot monitoring, or H H scheduled transmission H (same options as for wrong point in time) 7. Input/output 7.1 Digital I/O Fault conditions specified in lausibility check H Analog I/O Report No.: AS6-1 age 6 of 15

7 7.2.1 A/D- and D/Aconverter Analog multiplexer 8. Void 9 Custom chips. ASIC, GAL, Gate array Fault conditions specified in Wrong addressing Any output outside the static and dynamic functional specification Supplementary information: */* lausibility check H SWD_003_1_A015 _1.0_SW Design Documentation_for_ lausibility check eriodic self-test H H SWV_002_A015 _1.0_SW Verification report_for_ To 1.1 Registers: The routines include stuck-at and coupling failure detection. The user can set stuck-at detection only or stuck plus coupling failure detection. To 1.3 rogram Counter In the routines for register test 1.1 a small routine for testing of program counter is integrated. This routine does not cover completely the requirement of standard. It is a support for measures referenced in the table above. Additional measures Details Reference Verdict Watch Dog test Fail Trigger and Rest Source Monitoring Stack ointer Register and Stack Memory Test Write-read-verify with pattern for register and March-C for memory SWD_003_1_A015 _1.0_SW Design Documentation_for_ and SWV_002_A015 _1.0_SW Verification report_for_ Additional hardware features rotection Reference Verdict Ram parity error detection Stuck at or illegal modification - any access to undefined memory - write access to invariable Invalid memory access detection memory (ROM) function - instruction fetch from special predefined memory areas Window Watch dog with independent clock ort Output Enable On Chip Temperature Voltage Monitoring - Loss of clock of the arithmetic logical unit (ALU) or the complete micro controller - permanent execution of an undefined endless loop - permanent undefined code execution ( runaway software ) - time slot monitoring Set WM outputs to High- Impedance when failure is indicated from external or detected by software Over Temperature for Silicon Device Under voltage detection to avoid unstable operation r01um0001eu0080_synergy_s7g2.pdf Report No.: AS6-1 age 7 of 15

8 Clause Requirement + Test Result Remark Verdict R ANNEX R (NORMATIVE) ( ) SOFTWARE EVALUATION rogrammable electronic circuits requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2 validated in accordance with the requirements of this annex Self-test routines for software of class R.1 R.1 rogrammable electronic circuits using software rogrammable electronic circuits requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2 constructed so that the software does not impair compliance with the requirements of this standard R.2 Requirements for the architecture R rogrammable electronic circuits requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2 use measures to control and avoid software-related faults/errors in safety-related data and safety-related segments of the software rogrammable electronic circuits requiring software incorporating measures to control the fault/error conditions specified in table R.2 have one of the following structures: - single channel with periodic self-test and monitoring - dual channel (homogenous) with comparison - dual channel (diverse) with comparison rogrammable electronic circuits requiring software incorporating measures to control the fault/error conditions specified in table R.1 have one of the following structures: - single channel with functional test - single channel with periodic self-test - dual channel without comparison R.2.2 Measures to control faults/errors R R R When redundant memory with comparison is provided on two areas of the same component, the data in one area is stored in a different format from that in the other area rogrammable electronic circuits with functions requiring software incorporating measures to control the fault/error conditions specified in table R.2 and that use dual channel structures with comparison, have additional fault/error detection means for any fault/errors not detected by the comparison For programmable electronic circuits with functions requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2, means are provided for the recognition and control of Report No.: AS6-1 age 8 of 15

9 errors in transmissions to external safety-related data paths R For programmable electronic circuits with functions requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2, the programmable electronic circuits incorporate measures to address the fault/errors in safety-related segments and data indicated in table R.1 and R.2 as appropriate R For programmable electronic circuits with functions requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2, detection of a fault/error occur before compliance with clause 19 is impaired Self-test routines only; compliance to clause 19 has to be insured by the user of the self-test routines R The software is referenced to relevant parts of the operating sequence and the associated hardware functions R Labels used for memory locations are unique R The software is protected from user alteration of safety-related segments and data R Software and safety-related hardware under its control is initialized and terminates before compliance with clause 19 is impaired Self-test routines only; compliance to clause 19 has to be insured by the user of the self-test routines R.3 Measures to avoid errors R.3.1 General For programmable electronic circuits with functions requiring software incorporating measures to control the fault/error conditions specified in table R.1 or R.2, the following measures to avoid systematic fault in the software are applied Software that incorporates measures used to control the fault/error conditions specified in table R.2 is inherently acceptable for software required to control the fault/error conditions specified in table R.1 Class R.1 only R.3.2 Specification R Software safety requirements: Software Id: 1.x The specification of the software safety requirements includes the descriptions listed R Software architecture R The specification of the software architecture includes the aspects listed See table R.1 - techniques and measures to control software faults/errors (refer to R.2.2); - interactions between hardware and software; - partitioning into modules and their allocation to the specified safety functions; Report No.: AS6-1 age 9 of 15

10 R hierarchy and call structure of the modules (control flow); - interrupt handling; - data flow and restrictions on data access; - architecture and storage of data; - time-based dependencies of sequences and data The architecture specification is validated against the specification of the software safety requirements by static analysis R Module design and coding R Based on the architecture design, software is suitably refined into modules Software module design and coding is implemented in a way that is traceable to the software architecture and requirements R Software code is structured R Coded software is validated against the module specification by static analysis The module specification is validated against the architecture specification by static analysis Reviews and source code walk through R Software validation The software is validated with reference to the requirements of the software safety requirements specification Compliance is checked by simulation of: - input signals present during normal operation - anticipated occurrences - undesired conditions requiring system action H Measures to avoid errors ( ) H For controls with software Class B or C the V-model for the software life cycle should be applied Measures used for software class C are inherently acceptable for software class B Other methods are possible if they incorporate disciplined and structured processes including design and test phases Class B Remark: Software self-diagnostics are made of functions to be executed one by one in series, there are no complex relationships and interactions to consider. Report No.: AS6-1 age 10 of 15

11 H Specification H Software safety requirements H The specification of the software safety requirements includes: H H H H A description of each safety related function to be implemented, including its response time(s): o functions related to the application including their related software classes o functions related to the detection, annunciation and management of software or hardware faults A description of interfaces between software and hardware A description of interfaces between any safety and non-safety related functions Software architecture The description of software architecture shall include the following aspects: Techniques and measures to control software faults/errors (refer to H ) Interactions between hardware and software artitioning into modules and their allocation to the specified safety functions Hierarchy and call structure of the modules (control flow) Interrupt handling Data flow and restrictions on data access Architecture and storage of data Time based dependencies of sequences and data The architecture specification shall be verified against the specification of the software safety requirements by static analysis. Acceptable methods are: Control flow analysis Data flow analysis Walk-throughs / design reviews Based on the architecture design, software is suitably refined into modules. Software module design and coding are implemented in a way that is traceable to the software architecture and requirements H Software code is structured H Coded software is verified against the module specification, and the module specification is verified against the architecture specification by static analysis H Design and coding standards MISRA rogram design and coding standards is consequently used during software design and maintenance Coding standards specify programming practice, proscribe unsafe language features, and specify Report No.: AS6-1 age 11 of 15

12 H procedures for source code documentation as well as for data naming conventions Testing H Module design (software system design, software module design and coding) H H A test concept with suitable test cases is defined based on the module design specification. Each software module is tested as specified within the test concept H Test cases, test data and test results are documented H H H H Code verification of a software module by static means includes such techniques as software inspections, walk-throughs, static analysis and formal proof Code verification of a software module by dynamic means includes functional testing, white-box testing and statistical testing Software integration testing A test concept with suitable test cases is defined based on the architecture design specification The software is tested as specified within the test concept H Test cases, test data and test results are documented H H H Software validation A validation concept with suitable test cases is defined based on the software safety requirements specification The software is validated with reference to the requirements of the software safety requirements specification as specified within the validation concept. The software is exercised by simulation or stimulation of: input signals present during normal operation anticipated occurrences undesired conditions requiring system action H Test cases, test data and test results are documented H H H H H Other Items Tools, programming languages are assumed to be suitable if they comply with "increased confidence from use" according to IEC , C.4.4 Management of software versions: All versions are uniquely identified for traceability Software modification Software modifications are based on a modification request which details the following: the hazards which may be affected Report No.: AS6-1 age 12 of 15

13 H H the proposed change the reasons for change An analysis is carried out to determine the impact of the proposed modification on functional safety. A detailed specification for the modification is generated including the necessary activities for verification and validation, such as a definition of suitable test cases H The modification are carried out as planned H The assessment of the modification is carried out based on the specified verification and validation activities. This may include: a reverification of changed software modules a reverification of affected software modules a revalidation of the complete system H All details of modification activities are documented H Supplementary information: For class C control functions: One of the combinations (a p) of analytical measures given in the columns of table H.9 is used during hardware development... : The self-diagnostic routines mentioned under I are foreseen for following measures of table R.1 / H.1 of. File Name cpu_test.c CU_Test_Control.asm cpu_test_coupling.c CU_Test_General_High.asm CU_Test_General_Low.asm fpu_control.asm fpu_exten.asm fpu_test_coupling.c TestFUCouplingEnd.asm TestFUCouplingStart_A.asm TestFUCouplingStart_B.asm TestGRsCouplingEnd.asm TestGRsCouplingStart_A.asm TestGRsCouplingStart_B.asm TestFUCouplingS0_S3_B.asm TestFUCouplingS4_S7_A.asm TestFUCouplingS4_S7_B.asm TestFUCouplingS8_S11_A.asm Measure 1.1 CU Register Report No.: AS6-1 age 13 of 15

14 TestFUCouplingS8_S11_B.asm TestFUCouplingS12_S15_A.asm TestFUCouplingS12_S15_B.asm TestFUCouplingS16_S19_A.asm TestFUCouplingS16_S19_B.asm TestFUCouplingS20_S23_A.asm TestFUCouplingS20_S23_B.asm TestFUCouplingS24_S27_A.asm TestFUCouplingS24_S27_B.asm TestFUCouplingS28_S31_A.asm TestFUCouplingS28_S31_B.asm TestGRsCouplingR0_A.asm TestGRsCouplingR0_B.asm TestGRsCouplingR1_R3_A.asm TestGRsCouplingR1_R3_B.asm TestGRsCouplingR4_R6_A.asm TestGRsCouplingR4_R6_B.asm TestGRsCouplingR7_R9_A.asm TestGRsCouplingR7_R9_B.asm TestGRsCouplingR10_R12_A.asm TestGRsCouplingR10_R12_B.asm clock_monitor.c crc.c CRC_Verify.c ramtest_march_c.c ramtest_march_c_hw.c ramtest_march_hw.c ramtest_march_x_wom.c ramtest_march_x_wom_hw.c test_adc12.c 3. Clock 4.1 invariable memory 4.2 variable memory A/D- and D/A- converter Report No.: AS6-1 age 14 of 15

hoto documentation: Test Setup Testing and measuring

40 IAR Embedded Workbench Common Components, v. 7.

2 Debugger: IAR Embedded Workbenchfor ARM, v. 7.

S7 Uncertainty of measurement (optional according to

.3.1.c of IEC 17025): END OF TEST REORT Report No.

15 hoto documentation: Test Setup Testing and measuring equipment: Editor: IAR Embedded Workbenchfor ARM, v IAR Embedded Workbench Common Components, v. 7.2 Compiler/Linker: IAR Embedded Workbenchfor ARM, v IAR Embedded Workbench Common Components, v. 7.2 Debugger: IAR Embedded Workbenchfor ARM, v IAR Embedded Workbench Common Components, v. 7.2 Hardware: Renesas DK-S7G2 Development Kit for Synergy S7 Uncertainty of measurement (optional according to sub-clause c of IEC 17025): END OF TEST REORT Report No.: AS6-1 age 15 of 15

VDE Testing and Certification Institute

VDE Testing and Certification Institute Test Report Report No.... : 240808-TL5-1 File No.... : 5009141-4970-0001/240808 Date of issue... : 2018-03-21 Laboratory... : Testing and Certification Institute Address... : Merianstrasse 28 63069 Offenbach/Main;