VDE Testing and Certification Institute

Transcription

1 Test Report Report No.... : TL5-1 File No.... : / Date of issue... : Laboratory... : Testing and Certification Institute Address... : Merianstrasse Offenbach/Main; Germany Testing location/ address... : Testing and Certification Institute Merianstrasse Offenbach/Main; Germany Applicant's name... : STMicroelectronics (Rousset) SAS Applicant's address... : 190 Av. Célestin Coq; Zone Industrielle; ROUSSET; FRANCE 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 :2010 IEC :2010/AMD1:2013 IEC :2010/AMD2:2016 IEC :2013 IEC :2013/AMD1:2015 Focus was on Annex R of EN/IEC and Annex H of EN/IEC for the self-diagnostic library. Test item description... : Micro controller self-test library (Class R1 of EN/IEC and Class B of EN/IEC ) Trade Mark... : Type reference(s)... : Self-test Library for microcontroller series STM8Sxx; STM8Axx; STM8Lxx Software Revision 2.0 Ratings... : Test sample condition... : Non-damaged sample Remark: Source code Sample entry date... : Date (s) of performance of tests... : > Report No.: TL5-1 age 1 of 14 Disclaimer: This test 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 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 towards third party, this test shall be made available on the very spot in full length.

2

3 erformed tests Clause Requirement + Test Result Remark Annex R / H Table R1 ( ) H1 ( ) List of the STL methods All applied measures are acc. to the relevant chapter in Table 1 Verdict Report No.: TL5-1 age 3 of 14

4 Diagram of startup tests Report No.: TL5-1 age 4 of 14

5 Diagram of runtime tests Diagram of light CU run test Report No.: TL5-1 age 5 of 14

6 List of functions List of toolspecific STL procedures Report No.: TL5-1 age 6 of 14

7 List of Unique error codes Supplementary information: Report No.: TL5-1 age 7 of 14

8 hoto documentation: Testing and measuring equipment: Uncertainty of measurement (optional according to sub-clause c of IEC 17025): roducts to be covered Main stream Standard line V, up to 125 C Value line V, up to 85 C Automotive 3-5.5V, up to 150 C 128K STM8S207xx/208xx STM8S007xx STM8AF61xx/62xx/51xx/52xx 32K STM8S105xx STM8S005xx STM8AF61xx/62xx 8K STM8S103xx/903xx STM8S003xx/001xx STM8AF62xx Ultra Low ower Standard line V, up to 125 C Value line V, up to 85 C Automotive V, up to 125 C 32/64K L STM8L151xx/152xx STM8L052xx STM8AL31xx/3Lxx 8K L STM8L101xx STM8L051xx/050xx/001xx STM8TL5xxx STM8AL3036 Supported toolchains STVD Version and Cosmic STM8 32K compiler Version IAR Embedded Workbench for STM8 IDE (EWSTM8) software toolchain Version , IAR compiler V R ANNEX R (NORMATIVE) (Annex H ) 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 Class R1 self diagnostics Covering Microcontroller internal selfdiagnostics 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 Depends on final application R.2 Requirements for the architecture Report No.: TL5-1 age 8 of 14

9 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 Table R1 class R1 measures 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 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 errors in transmissions to external safety-related data paths 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 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 Do be done in final application See details To be ensured in the final application Report No.: TL5-1 age 9 of 14

10 R The software is referenced to relevant parts of the operating sequence and the associated hardware functions To be ensured in the final application R Labels used for memory locations are unique R The software is protected from user alteration of safety-related segments and data To be ensured in the final application R Software and safety-related hardware under its control is initialized and terminates before compliance with clause 19 is impaired To be ensured in the final application 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 R.3.2 Specification R Software safety requirements: Software Id:Revision 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 - 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; - hierarchy and call structure of the modules (control flow); Document ref. No: (The selftest library covers only parts of the Table R1 requirements and have to be bound into the final applications software, they are to be called separately) - interrupt handling; - data flow and restrictions on data access; - architecture and storage of data; - time-based dependencies of sequences and data R 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 Single self diagnostic functions to be called Report No.: TL5-1 age 10 of 14

11 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 The modules have been developed to cover relevant parts of the table R1 The modules have been developed to cover relevant parts of the table R1 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 Report No.: TL5-1 age 11 of 14

12 TABLE R.1 e GENERAL FAULT/ERROR CONDITIONS Table H1 of EN/IEC Component a Fault/error Acceptable measures b, c Definitions Document reference for applied measure Document reference for applied test Ver-di ct 1 CU 1.1 Registers Stuck at Functional test, or H periodic self-test using either: H static memory test, or H word protection with single bit redundancy H VOID 1.3 rogramme counter Stuck at Functional test, or eriodic self-test, or Independent time-slot monitoring, or H H 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 synchroniz ed clock: harmonics/ sub-harmo nics only) Frequency monitoring, or time slot monitoring H H Memory 4.1 Invariable memory All single bit faults eriodic modified checksum, or multiple checksum, or word protection with single bit redundancy H H H (*) 4.2 Variable memory DC fault eriodic static memory test, or word protection with single bit redundancy H H Addressing (relevant to variable and invariable memory) Stuck at Word protection with single bit redundancy including the address H Report No.: TL5-1 age 12 of 14

13 5 Internal data path Stuck at Word protection with single bit redundancy H VOID 5.2 Addressing Wrong address Word protection with single bit redundancy including the address H External communicat ion Hamming distance 3 Word protection with multi-bit redundancy, or CRC single work, or Transfer redundancy, or H H H rotocol test H VOID 6.2 VOID 6.3 Timing Wrong point in time Time-slot monitoring, or scheduled transmission Time-slot and logical monitoring, or H H 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 Input/output periphery 7.1 VOID Fault conditions specified in lausibility check H Analog I/O A/D and D/Aconverter Fault conditions specified in lausibility check H Analog multiplexer Wrong addressing lausibility check H VOID Report No.: TL5-1 age 13 of 14

14 9 Custom chips d e.g. ASIC, GAL, gate array Additional measures Remark for CRC test with Cosmic IDE Any output outside the static and dynamic functional specificatio n Watchdog initial selftest Class R variable protection Stack test eriodic self-test H Current version of the Cosmic compiler and linker supports a specific light check sum algorithm only, which is faster but it doesn t fully correspond to CRC standard. Nevertheless the compiler documentation declares functions supporting full CCITT 16 bit algorithm, too, but these functions were not supported at time of the ST certification appliance. User should check availability of these functions at some later version of the compiler and implement them into the code in adequate way as it is done with the light test at current ST solution. NOTE A Stuck-at fault model denotes a fault model representing an open circuit or a non-varying signal level. A DC fault model denotes a stuck-at fault model incorporating short circuit between signal lines. a) For fault/error assessment, some components are divided into their sub-functions. b) For each sub-function in the table, the Table R.2 measure will cover the software fault/error. c) Where more than one measure is given for a sub-function, these are alternatives. d) To be divided as necessary by the manufacturer into sub-functions. e) Table R.1 is applied according to the requirements of R.1 to R inclusive. END OF TESTREORT Report No.: TL5-1 age 14 of 14