EN50128 2011標(biāo)準(zhǔn)培訓(xùn)

1、北京英華經(jīng)綸交通運(yùn)輸有限公司（勞氏北京）于2012年2月9日在北京舉辦了EN50128新版標(biāo)準(zhǔn)研討會(huì)，會(huì)議由 Professor Ali Hessami 講解（歐標(biāo)修訂工作組WG11主席，負(fù)責(zé)EN50128:2011的修訂) 。 Ali Hessami教授介紹了系統(tǒng)安全保障的基本概念，并從標(biāo)準(zhǔn)制定者的角度介紹了新版的EN50128，同時(shí)還談到了EN50126系列標(biāo)準(zhǔn)的整合和未來。 下面的ppt文檔是基于本次研討會(huì)的總結(jié)，也加入了個(gè)人的理解，并把我的提問和回答也都列出。如果有不正確的或者遺漏的地方，請(qǐng)及時(shí)指出，謝謝！Main differences in New EN50128 are the

2、following contents: Organization and role Personnel competence Support tools Application data or algorithms Deployment and maintenanceOrganization, role and independence requirements (section 5.1) Add the role of RQM (requirement manager) , INT(Integritor) and TST(Tester) Add the description of thes

3、e roles The independent requirements for roles are clearly explained.Example:Personnel competencies are added in Annex B of EN50128 2011. An example is shown: Support Tools and Languages (Section 6.7) Provide evidence that potential failures of tools do not adversely affect the integrated toolset ou

4、tput in a safety related manner. Classification Three classes of tools so far as reliability and safety impact is concerned as T1,T2 and T3. Each class will place different requirements on the required assurance T1 class (section 3.1.42) generates no outputs which can directly or indirectly contribu

5、te to the executable code (including data) of the software Example： a text editor, configuration control tools. T2 class (section 3.1.43) supports the test or verification of the design or executable code, where errors in the tool can fail to reveal defects but cannot directly create errors in the e

6、xecutable software. Example：a test coverage measurement tool and a static analysis tool T3 class (section 3.1.44) generates outputs which can directly or indirectly contribute to the executable code (including data) of the safety related system Example： a source code compiler A simple way to underst

7、and the three types of tools: T1 -SIL0 T2 -SIL1&2 T3 -SIL3&4 This part is emphasized in the new EN50128. (section 8) “The requirements for the development of application algorithms are the same as the development of generic software as described in Clauses 1-7 and 9. “ emphasize the importan

8、ce of this part. Example Software deployment (section 9.1): To ensure that the software performs as required, preserving the required software safety integrity level and dependability when it is deployed in the final environment of application. Key requiremnts Follow ISO 90003 as a minimum Define an

9、d maintain baseline (Example: using CC) Release Notes Error Detection in Transport Deployment ManualSIL0 is not viewed as non-safety, which has safety impact below SIL1. Some requirements for SIL0 still needs to be achieved. Example: Predeveloped software and COTS software are uniformly named as Pre

10、-exisitng software (7.3.4.7). Example: Overall Software Test is added to test the software requirements Objective: To analyse and test the integrated software and hardware to ensure compliance with the Software Requirements Specification. Example: Software module is modified as software component. E

11、xample SWSIL is changed as SIL Example Add software interface specification in the architecture design stage Example: EN50126-X will be published in 2014(estimated) EN50126-1 RAMS in Railways(EN50126:1999) EN50126-2 Tools and Methods (New) EN50126-3 SMS for Railways (Many parties do not agree) EN501

12、26-4 Functional Safety of Electronic Systems (EN50129:2003) EN50126-5 Software for Railway Applications (EN50128: 2011) 1. 1. Section 7.3.4.7 b) For all software safety integrity levels the pre-existing software shall be included in the validation process of the whole software. Question: What is the

13、 real meaning of this sentence? Actually all of the pre-existing (COTS) software is included in the system validation. Do we need to carefully validate the pre-existing software especially and independently before validating the whole software or system? Answer (Ali Hessami): Yes. We shall do more t

14、han before about the pre-existing software. It is recommended that all of the functions of pre-existing software shall be checked. If the pre-existing software has passed the certification, only reviewing documents is enough. If the pre-exiting software does not have the certificate, all of the func

15、tions needs to be carefully tested before using. 2. Diverse programming (D16) Diverse programming is a difficult method for implementation. If we can not assess the level of diversity, how could we claim that our own software diversity method is effective or not? For instance, we can implement two d

16、ifferent methods in one computer or two different methods in two computers to achieve software diversity. Could you give us a suggestion which is better? Answer (Ali Hessami): It depends on the problem you want to solve. If two different methods in one CPU can achieve the goal (Hardware unrelated pr

17、oblem), it is OK. Or else, two different methods in two CPUs are necessary (hardware related problem). 3. SIL Traceability In developing safety critical software, the software with SIL4 could be traced by SIL4 and SIL0 software module. It is reasonable. But in some cases, the software with SIL0 may

18、be traced by SIL4 software module. The reason is during implementing software, some software modules with SIL0 can not clearly isolated with SIL4 software modules. Therefore although the software requirement is SIL0, the implementing software module is SIL4. In principle, this scenario is not allowed but it indeed exists in th