1. SAMCAHNG Yun Goo Kim I. Formal Model Based Development & Safety Analysis II. UML (Model) Based Safety RMS S/W Development February 03 2006 KIM, YUN GOO

2. Background  SAFECOMP2005  THE 24thInternational Conference on COMPUTER SAFETY, RELIABILITY AND SECURITY  26 - 30 September 2005 Fredrikstad, Norway  CSDUML  The 4th International Workshop on Critical Systems Development Using Modeling Languages  Formal Model Based Development  Keynote by Professor Mats Heimdahl, University of Minnesota, USA  Model Based Safety Analysis of Simulink Models Using SCADE Design Verifier

3. Model Based Development

4. Commercial and research tools  Commercial  Esterel and SCADE (Esterel Technologies)  Statemate Magnum and Rhapsody (i- Logix)  SpecTRM (Safeware Engineering)  Simulink and Stateflows from Mathworks Inc  Rose Realtime from Rational(IBM)  Research  SCR  RSML-e  Ptolemy

5. S/W Development Model Water Fall Model V-Model

6. Model based development Process V-Model Y-Model

7. Y Model from Luiz Fernando Capretz Ref Journal of Computer Science 1 (1): 76-82, 2005 Y: A New Component-Based Software Life Cycle Model

8. ROI with Model Based Development - 37.5 % - 25 % - 75 % - 50 %

10. Model-Based Development Examples

11. Potential Issues… Can We REALLY trust code generator Are the languages usable syntax and semantics? Can they be inspected? Is the specification “right”? Can we trust execution environment? Trust the results? Tested enough? Can we trust execution environment?

12. “Correct” Code Generation—How?  Provably Correct Compilers  Very Hard (and Often Not Convincing)  Proof Carrying Code  Generate Test Suites From Model  Compare Model Behavior With Generated Code  Unit Testing Is Now Not Eliminated, but Largely Automated

13. Proof Techniques  Certify analysis tools  Too costly and probably impossible  Use redundant proof paths  Technically feasible, but is the redundancy “trustworthy”??  Cost…  Automation is key  Must keep analysis cost under control  Generate test suites from specification  Low cost since it is already done for the code generator

14. Three Conjectures  No modeling language will be universally accepted, nor universally applicable  No verification/validation tool will satisfy the analysis needs of a user  Languages and tools must be tested on real world problems by practicing engineers  Preferably commercial tools

15. Tool Chain

16. Challenges  Next generation tools must allow easy extension and modification of notations to meet domain specific needs  They must allow easy construction of high quality translations from modeling notations to analysis tools  They also must enable controlled reuse of tool infrastructure to make tool extensions cost effective  Model Validation  Language Syntax and Semantics  Tool Verification and Certification  New Tools Infrastructure

18. UML Based Development DOORS RhapsodyStatemateC++ Test Concept Requirement ModelingVerification Unit Test System Test ImplementationCode Test Model Test Formal Verification TEST CASE Generation

19. Concept : Use Case Diagram  The Radiation Monitoring System (RMS) shall be a computer based data acquisition, analysis, display, and report generating system. The RMS shall monitor radiation levels of designated systems and areas of a two-unit pressurized water reactor (PWR) nuclear power generating station. Each unit shall have its own independent RMS consisting of redundant (dual) computer subsystem and radiation monitors specified in this specification. The system is to include both safety-related equipment required for safe operation of the plant, and equipment which is not safety-related but necessary for recording the radiation history of the power plant. All hardware, firmware and software necessary for proper system operation shall be included. The RMS shall include offsite dose calculation and report generating subsystem composed of all necessary hardware and software.

20. Requirement : Use Case Diagram  SR1. The RMS shall include at least the following process, functional, and malfunction alarms:  SR1.1 Two high radiation level alarms that can be set at any point in the measurement range. These alarms shall include an output inhibit in the circuit that is initiated by check source actuation.  SR1.2 Rate of rise. An alarm shall be actuated when the rate of increase in radiation level exceeds a preset value.  SR1.3 A low radiation level alarm for indication of malfunction.  SR1.4 Loss of power (may be combined with low radiation level alarm)  SR1.5 A system alarm shall be generated when data buffer is 70 percent full  SR1.6 Cabinet high temperature alarm  SR2. The alarms shall not operate if the RMS is switched off.  SR3. Access to the radiation monitoring system's alarm setpoints shall be under administrative control

21. Requirement : Use Case Diagram

22. Requirement Traceability  SR1. The RMS shall include at least the following process, functional, and malfunction alarms:  SR1.1 Two high radiation level alarms that can be set at any point in the measurement range. These alarms shall include an output inhibit in the circuit that is initiated by check source actuation.  SR1.2 Rate of rise. An alarm shall be actuated when the rate of increase in radiation level exceeds a preset value.  SR1.3 A low radiation level alarm for indication of malfunction.  SR1.4 Loss of power (may be combined with low radiation level alarm)  SR1.5 A system alarm shall be generated when data buffer is 70 percent full  SR1.6 Cabinet high temperature alarm  SR2. The alarms shall not operate if the RMS is switched off.  SR3. Access to the radiation monitoring system's alarm setpoints shall be under administrative control

23. Design : Class Diagram

24. Design : StateChart  Auto Code Generation

25. State chart based Link  Rhapsody and StateMate Magnum are from I-logix  Manual Change  Limit of number of instance  Function Call is not supported by StateMate->use another state  Event Value passing is not supported by StateMate->use Global variable  Automatic Change  XML Conversion  State Chart Source Analysis

26. Discussion  Model Based Development  Introduction to CSDUML and SAFECOMP20005  Paper Review of Prof Heimdahl  Model Validation, Tool verification  Empirical Study  UML Based Development  Detail modeling  Formal conversion (Rhapsody to Statemate magnum)