Qualification of PVS for Systematic Design Verification of a Nuclear Shutdown System Mark Lawford & Many Others McMaster Centre for Software Certification (McSCert) McMaster University Hamilton, ON, Canada Dagstuhl Seminar 15182 “Qualification of Formal Methods Tools” April 26-29, 2014 Dagstuhl, Germany Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 1 / 40
Outline Outline Prelude 1 Background: How did we get to qualification of PVS? 2 The process & associated implicit “assurance case” 3 Qualification of PVS for Darlington SDS Redesign Current work on Tools and Conclusions 4 Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 2 / 40
Prelude It was In 1997, the year before IEC-61508-3 Ed 1.0 came out. Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 3 / 40
Prelude It was In 1997, the year before IEC-61508-3 Ed 1.0 came out. I turned down an NSERC Postdoctoral award to go work on an industrial problem related to my thesis work - verification of real-time controls software. For the next two years I wound up learning about theorem provers and had to qualify and use PVS for the Systematic Design Verification of the Nuclear Generating Station that was on the way to my parent’s place. If it was 2010 or 2011, I could have used IEC-61508-3 (ed 2.0) and IEC 61508-4 (ed 2.0) and life would have been much easier. Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 3 / 40
Prelude It was In 1997, the year before IEC-61508-3 Ed 1.0 came out. I turned down an NSERC Postdoctoral award to go work on an industrial problem related to my thesis work - verification of real-time controls software. For the next two years I wound up learning about theorem provers and had to qualify and use PVS for the Systematic Design Verification of the Nuclear Generating Station that was on the way to my parent’s place. If it was 2010 or 2011, I could have used IEC-61508-3 (ed 2.0) and IEC 61508-4 (ed 2.0) and life would have been much easier. My memory of events may be fuzzy. Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 3 / 40
Background: How did we get to qualification of PVS? In the late 1980s industry kicked the first two soft- ware based SDS com- puter controlled safety systems in Canadia Nu- clear industry over the wall to the regulator and said “approve it!” Each system had ap- prox. 84 monitored variables 27 controlled variables Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 4 / 40
Background: How did we get to qualification of PVS? In the late 1980s industry kicked the first two soft- ware based SDS com- puter controlled safety systems in Canadia Nu- clear industry over the wall to the regulator and said “approve it!” Each system had ap- prox. 84 monitored variables 27 controlled variables Regulator response: Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 4 / 40
Background: How did we get to qualification of PVS? In the late 1980s industry kicked the first two soft- ware based SDS com- puter controlled safety systems in Canadia Nu- clear industry over the wall to the regulator and said “approve it!” Each system had ap- prox. 84 monitored variables 27 controlled variables Regulator response: Software? Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 4 / 40
Background: How did we get to qualification of PVS? In the late 1980s industry kicked the first two soft- ware based SDS com- puter controlled safety systems in Canadia Nu- clear industry over the wall to the regulator and said “approve it!” Each system had ap- prox. 84 monitored variables 27 controlled variables Regulator response: Software? WTF? Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 4 / 40
Background: How did we get to qualification of PVS? Regulator Reaction to the Originial Darlington SDS Regulator brought in David Parnas as a consultant. He concluded: The software was developed (and documented), but the requirements documents were not detailed enough. Despite this deficiency, a surprisingly rigorous and comprehensive testing regime had already been developed. Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 5 / 40
Background: How did we get to qualification of PVS? Regulator Reaction to the Originial Darlington SDS Regulator brought in David Parnas as a consultant. He concluded: The software was developed (and documented), but the requirements documents were not detailed enough. Despite this deficiency, a surprisingly rigorous and comprehensive testing regime had already been developed. Dave’s recommendation: develop tabular requirements specification/design for each existing 1 code module from requirements documents and domain experts create tables from the code for each program function by 2 eliminating intermediate variables independent verification team then tries to (manually) prove tables 3 are equivalent Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 5 / 40
Background: How did we get to qualification of PVS? Outcome of the First Darlington Licensing How OPG met regulator expectations Tables were created from both requirements & code in excel spreadsheets Independent team tried to show their were equivalent by manually transforming and composing tables to create new tables in excel spreadsheets. Extensive review of the transformations was used to eliminate single point of failure in process. Regulator was satisfied that system would operate safely but was not maintainable System was licensed for fixed number of years on condition that the software would be redesigned to be maintainable Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 6 / 40
Background: How did we get to qualification of PVS? Outcome of the First Darlington Licensing How OPG met regulator expectations Tables were created from both requirements & code in excel spreadsheets Independent team tried to show their were equivalent by manually transforming and composing tables to create new tables in excel spreadsheets. Extensive review of the transformations was used to eliminate single point of failure in process. Regulator was satisfied that system would operate safely but was not maintainable System was licensed for fixed number of years on condition that the software would be redesigned to be maintainable OPG realized they needed a rigorous approach in order to cost effectively develop safety critical software. Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 6 / 40
Background: How did we get to qualification of PVS? What Original Darlington Experience Taught Us Dialog with the regulator is essential: To make the process affordable and deterministic for industry To make it possible for the regulator to “assessing” a system with a reasonable amount of effort. Verification in one step from code to (low-level) requirements was often too large and complex. reverse engineering tabular specifications for requirements and the code was very expensive and labour intensive Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 7 / 40
Background: How did we get to qualification of PVS? What Original Darlington Experience Taught Us Dialog with the regulator is essential: To make the process affordable and deterministic for industry To make it possible for the regulator to “assessing” a system with a reasonable amount of effort. Verification in one step from code to (low-level) requirements was often too large and complex. reverse engineering tabular specifications for requirements and the code was very expensive and labour intensive Automation and tool support is essential! Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 7 / 40
Background: How did we get to qualification of PVS? What Original Darlington Experience Taught Us Dialog with the regulator is essential: To make the process affordable and deterministic for industry To make it possible for the regulator to “assessing” a system with a reasonable amount of effort. Verification in one step from code to (low-level) requirements was often too large and complex. reverse engineering tabular specifications for requirements and the code was very expensive and labour intensive Automation and tool support is essential! ⇒ Tool qualification on the redesign! Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 7 / 40
The process & associated implicit “assurance case” The Darlington SDS Redesign Project OPG worked with the regulator to get agreement on: what would be an acceptable development process what evidence would be sufficient for licensing For the SDS Redesign Project formal techniques were integrated in the forward development process. Forward development process produced evidence for certification/evaluation Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 8 / 40
The process & associated implicit “assurance case” Using Information Hiding 60 modules 280 access programs 40,000 lines of code (including comments) 33,000 FORTRAN 7,000 assembler 84 monitored variables 27 controlled variables Lawford et al. (McSCert) Dagstuhl 15182 2015/04/28 9 / 40
Recommend
More recommend
