{"id":446166,"date":"2024-10-20T08:45:26","date_gmt":"2024-10-20T08:45:26","guid":{"rendered":"https:\/\/pdfstandards.shop\/product\/uncategorized\/bs-en-507162023\/"},"modified":"2024-10-26T16:18:44","modified_gmt":"2024-10-26T16:18:44","slug":"bs-en-507162023","status":"publish","type":"product","link":"https:\/\/pdfstandards.shop\/product\/publishers\/bsi\/bs-en-507162023\/","title":{"rendered":"BS EN 50716:2023"},"content":{"rendered":"
1.1 This European Standard specifies the process and technical requirements for the development of software for programmable electronic systems for use in control, command for signaling applications and any on-board of rolling stock. This European Standard is not intended to be applied in the area of electric traction power supply (fixed installation) or for power supply and control of conventional applications, e.g. station power supply for offices, shops etc. These applications are covered typically by standards for energy distribution and\/or non-railway sectors and\/or local legal frameworks. For railway related fixed installations (electric traction power control and supply) the EN 50562 is applicable. 1.2 This European Standard is applicable exclusively to software and the interaction between software and the system of which it is part. 1.3 Intentionally left blank 1.4 This European Standard applies to all software used in railway systems, including – application programming, – operating systems, – support tools, – firmware. Application programming comprises high level programming, low level programming and special purpose programming (for example: Programmable logic controller ladder logic). 1.5 This European Standard also addresses the use of pre-existing software and tools. Such software may be used, if the specific requirements in 7.3.4.7 and 6.5.4.16 on pre-existing software and for tools in 6.7 are fulfilled. 1.6 Software developed according to any version of EN 50128 or EN 50657 will be considered as compliant and not subject to the requirements on pre-existing software. 1.7 This European Standard considers that modern application design often makes use of software that is suitable as a basis for various applications. Such software is then configured by application data for producing the executable software for the application. 1.8 Entry intentionally left empty. 1.9 This European Standard is not intended to be retrospective. It therefore applies primarily to new developments and only applies in its entirety to existing systems if these are subjected to major modifications. For minor changes, only 9.2 applies. The assessor has to analyse the evidences provided in the software documentation to confirm whether the determination of the nature and scope of software changes is adequate. However, application of this European Standard during upgrades and maintenance of existing software is highly recommended. 1.10 For the development of User Programmable Integrated Circuits (e.g. FPGA & CPLD) guidance is provided in EN 50129:2018 Annex F for safety related functions and in EN 50155:2017 for non-safety related functions. Software running on soft-cores of User Programmable Integrated Circuits is within the scope of this European Standard. […]<\/p>\n
PDF Pages<\/th>\n | PDF Title<\/th>\n<\/tr>\n | ||||||
---|---|---|---|---|---|---|---|
2<\/td>\n | undefined <\/td>\n<\/tr>\n | ||||||
13<\/td>\n | 1 Scope 2 Normative references <\/td>\n<\/tr>\n | ||||||
14<\/td>\n | 3 Terms, definitions and abbreviations 3.1 Terms and definitions <\/td>\n<\/tr>\n | ||||||
19<\/td>\n | 3.2 Abbreviations <\/td>\n<\/tr>\n | ||||||
20<\/td>\n | 4 Software integrity levels conformance <\/td>\n<\/tr>\n | ||||||
21<\/td>\n | 5 Software management and organization 5.1 Organization and independence of roles 5.1.1 Objective 5.1.2 Requirements <\/td>\n<\/tr>\n | ||||||
24<\/td>\n | 5.2 Personnel competence and responsibilities 5.2.1 Objectives 5.2.2 Requirements <\/td>\n<\/tr>\n | ||||||
25<\/td>\n | 5.3 Lifecycle issues and documentation 5.3.1 Objectives 5.3.2 Requirements <\/td>\n<\/tr>\n | ||||||
26<\/td>\n | 6 Software assurance 6.1 Software testing 6.1.1 Objective 6.1.2 Input documents 6.1.3 Output documents 6.1.4 Requirements <\/td>\n<\/tr>\n | ||||||
27<\/td>\n | 6.2 Software verification 6.2.1 Objective 6.2.2 Input documents 6.2.3 Output documents <\/td>\n<\/tr>\n | ||||||
28<\/td>\n | 6.2.4 Requirements <\/td>\n<\/tr>\n | ||||||
29<\/td>\n | 6.3 Software validation 6.3.1 Objective 6.3.2 Input documents 6.3.3 Output documents 6.3.4 Requirements <\/td>\n<\/tr>\n | ||||||
30<\/td>\n | 6.4 Software assessment 6.4.1 Objective <\/td>\n<\/tr>\n | ||||||
31<\/td>\n | 6.4.2 Input documents 6.4.3 Output documents 6.4.4 Requirements <\/td>\n<\/tr>\n | ||||||
32<\/td>\n | 6.5 Software quality assurance 6.5.1 Objectives 6.5.2 Input documents 6.5.3 Output documents 6.5.4 Requirements <\/td>\n<\/tr>\n | ||||||
35<\/td>\n | 6.6 Modification and change control 6.6.1 Objectives 6.6.2 Input documents 6.6.3 Output documents 6.6.4 Requirements <\/td>\n<\/tr>\n | ||||||
36<\/td>\n | 6.7 Support tools and languages 6.7.1 Objectives 6.7.2 Input documents 6.7.3 Output documents 6.7.4 Requirements <\/td>\n<\/tr>\n | ||||||
39<\/td>\n | 7 Software development 7.1 Lifecycle and documentation for software 7.1.1 Objectives 7.1.2 Requirements 7.2 Software requirements 7.2.1 Objectives 7.2.2 Input documents 7.2.3 Output documents 7.2.4 Requirements <\/td>\n<\/tr>\n | ||||||
41<\/td>\n | 7.3 Architecture and design 7.3.1 Objectives <\/td>\n<\/tr>\n | ||||||
42<\/td>\n | 7.3.2 Input documents 7.3.3 Output documents 7.3.4 Requirements <\/td>\n<\/tr>\n | ||||||
49<\/td>\n | 7.4 Component design 7.4.1 Objectives 7.4.2 Input documents 7.4.3 Output documents 7.4.4 Requirements <\/td>\n<\/tr>\n | ||||||
51<\/td>\n | 7.5 Component implementation and testing 7.5.1 Objectives 7.5.2 Input documents 7.5.3 Output documents 7.5.4 Requirements <\/td>\n<\/tr>\n | ||||||
52<\/td>\n | 7.6 Integration 7.6.1 Objectives 7.6.2 Input documents 7.6.3 Output documents 7.6.4 Requirements <\/td>\n<\/tr>\n | ||||||
54<\/td>\n | 7.7 Overall software testing \/ Final validation 7.7.1 Objectives 7.7.2 Input documents 7.7.3 Output documents 7.7.4 Requirements <\/td>\n<\/tr>\n | ||||||
56<\/td>\n | 8 Development of application data: systems configured by application data 8.1 Objectives 8.2 Input documents <\/td>\n<\/tr>\n | ||||||
57<\/td>\n | 8.3 Output documents 8.4 Requirements 8.4.1 Application development process <\/td>\n<\/tr>\n | ||||||
58<\/td>\n | 8.4.2 Application requirements specification <\/td>\n<\/tr>\n | ||||||
59<\/td>\n | 8.4.3 Architecture and Design 8.4.4 Application data production <\/td>\n<\/tr>\n | ||||||
60<\/td>\n | 8.4.5 Application integration and testing 8.4.6 Application validation and assessment 8.4.7 Application preparation procedures and tools <\/td>\n<\/tr>\n | ||||||
61<\/td>\n | 9 Software deployment and maintenance 9.1 Software deployment 9.1.1 Objective 9.1.2 Input documents 9.1.3 Output documents 9.1.4 Requirements <\/td>\n<\/tr>\n | ||||||
63<\/td>\n | 9.2 Software maintenance 9.2.1 Objective 9.2.2 Input documents 9.2.3 Output documents 9.2.4 Requirements <\/td>\n<\/tr>\n | ||||||
66<\/td>\n | Annex A (normative)Criteria for the selection of techniques and measures A.1 General <\/td>\n<\/tr>\n | ||||||
67<\/td>\n | A.2 Clauses tables <\/td>\n<\/tr>\n | ||||||
73<\/td>\n | A.3 Detailed tables <\/td>\n<\/tr>\n | ||||||
77<\/td>\n | Annex B (normative)Key software roles and responsibilities <\/td>\n<\/tr>\n | ||||||
83<\/td>\n | Annex C (informative)Guidance on software development C.1 Lifecycle model examples C.1.1 General remarks C.1.2 Linear lifecycle models <\/td>\n<\/tr>\n | ||||||
85<\/td>\n | C.1.3 Iterative lifecycle models <\/td>\n<\/tr>\n | ||||||
89<\/td>\n | C.2 Modelling C.2.1 Modelling \u2013 General C.2.2 Modelling \u2013 Definition <\/td>\n<\/tr>\n | ||||||
90<\/td>\n | C.2.3 Modelling \u2013 Lifecycle issues and documentation C.2.4 Modelling \u2013 Software assurance C.2.4.1 General C.2.4.2 Software testing C.2.4.3 Software verification <\/td>\n<\/tr>\n | ||||||
91<\/td>\n | C.2.4.4 Software validation C.2.5 Modelling \u2013 Support tools and languages C.2.6 Modelling \u2013 Software development (Lifecycle and documentation) C.2.6.1 General C.2.6.2 Software requirements C.2.6.3 Architecture and design <\/td>\n<\/tr>\n | ||||||
92<\/td>\n | C.2.6.4 Component design C.2.6.5 Component implementation and testing <\/td>\n<\/tr>\n | ||||||
94<\/td>\n | C.2.6.6 Integration C.2.6.7 Overall software testing \/ Final validation C.3 Artificial Intelligence and Machine Learning C.3.1 General C.3.2 Usage of AI and ML within EN 50716 C.3.3 Challenges to the use of AI and ML within EN 50716 <\/td>\n<\/tr>\n | ||||||
96<\/td>\n | Annex D (informative)Bibliography of techniques D.1 Intentionally left blank D.2 Analysable programs D.3 Avalanche\/stress testing <\/td>\n<\/tr>\n | ||||||
97<\/td>\n | D.4 Boundary value analysis D.5 Backward recovery D.6 Cause consequence diagrams <\/td>\n<\/tr>\n | ||||||
98<\/td>\n | D.7 Checklists D.8 Control flow analysis <\/td>\n<\/tr>\n | ||||||
99<\/td>\n | D.9 Intentionally left blank D.10 Data flow analysis D.11 Data flow diagrams <\/td>\n<\/tr>\n | ||||||
100<\/td>\n | D.12 Data recording and analysis D.13 Decision tables and truth tables D.14 Defensive programming <\/td>\n<\/tr>\n | ||||||
101<\/td>\n | D.15 Coding standards and style guide <\/td>\n<\/tr>\n | ||||||
103<\/td>\n | D.16 Diverse programming D.17 Dynamic reconfiguration <\/td>\n<\/tr>\n | ||||||
104<\/td>\n | D.18 Equivalence classes and input partition testing D.19 Error detecting and correcting codes D.20 Error guessing <\/td>\n<\/tr>\n | ||||||
105<\/td>\n | D.21 Error seeding D.22 Event tree analysis D.23 Fagan inspections <\/td>\n<\/tr>\n | ||||||
106<\/td>\n | D.24 Failure assertion programming D.25 SEEA \u2013 Software Error Effect Analysis <\/td>\n<\/tr>\n | ||||||
107<\/td>\n | D.26 Fault detection and diagnosis D.27 Finite state machines\/state transition diagrams <\/td>\n<\/tr>\n | ||||||
108<\/td>\n | D.28 Formal methods D.29 Formal proof <\/td>\n<\/tr>\n | ||||||
109<\/td>\n | D.30 Forward recovery D.31 Graceful degradation D.32 Impact analysis <\/td>\n<\/tr>\n | ||||||
110<\/td>\n | D.33 Information hiding \/ encapsulation D.34 Interface testing D.35 Intentionally left blank D.36 Memorizing executed cases <\/td>\n<\/tr>\n | ||||||
111<\/td>\n | D.37 Metrics D.38 Modular approach <\/td>\n<\/tr>\n | ||||||
112<\/td>\n | D.39 Performance modelling D.40 Performance requirements <\/td>\n<\/tr>\n | ||||||
113<\/td>\n | D.41 Intentionally left blank D.42 Process simulation D.43 Prototyping \/ animation <\/td>\n<\/tr>\n | ||||||
114<\/td>\n | D.44 Recovery block D.45 Response timing and memory constraints D.46 Re-try fault recovery mechanisms D.47 Safety bag <\/td>\n<\/tr>\n | ||||||
115<\/td>\n | D.48 Software configuration management D.49 Intentionally left blank D.50 Structure based testing D.51 Structure diagrams <\/td>\n<\/tr>\n | ||||||
116<\/td>\n | D.52 Structured methodology <\/td>\n<\/tr>\n | ||||||
117<\/td>\n | D.53 Structured programming D.54 Suitable programming languages <\/td>\n<\/tr>\n | ||||||
119<\/td>\n | D.55 Petri nets <\/td>\n<\/tr>\n | ||||||
120<\/td>\n | D.56 Walkthroughs \/ design reviews D.57 Intentionally left blank D.58 Traceability <\/td>\n<\/tr>\n | ||||||
121<\/td>\n | D.59 Intentionally left blank D.60 Intentionally left blank D.61 Intentionally left blank D.62 Intentionally left blank D.63 Intentionally left blank D.64 Intentionally left blank D.65 Data modelling D.66 Control flow diagram\/control flow graph <\/td>\n<\/tr>\n | ||||||
123<\/td>\n | D.67 Sequence diagram D.68 Tabular specification methods D.69 Intentionally left blank D.70 Intentionally left blank D.71 Domain specific languages <\/td>\n<\/tr>\n | ||||||
124<\/td>\n | Annex ZZ (informative)Relationship between this European Standard and the Essential Requirements of EU Directive (EU) 2016\/797 aimed to be covered <\/td>\n<\/tr>\n<\/table>\n","protected":false},"excerpt":{"rendered":" Railway Applications. Requirements for software development<\/b><\/p>\n |