SysML to SLIMtransformationmethodologyConnecting model-based space systems engi-neering and model-based software engineering

J.T. van der GaagDelft, 20161507036

SysML to SLIMtransformationmethodology

Connecting model-based space systemsengineering and model-based software

engineering

by

J.T. van der Gaag

to obtain the degree ofMaster of Science in Space Engineeringat the Delft University of Technology,

to be defended publicly on Tuesday May 16, 2017 at 09:30 AM.

Student number: 1507036Project duration: June 20, 2016 – May 16, 2017Thesis committee: Prof. dr. E. K. A. Gill, TU Delft

Dr. J. Guo, TU DelftDr. ir. G. La Rocca, TU DelftDr. ir. M. H. G. Verhoef, European Space Agency

Thesis coach: J. Carvajal Godínez, TU Delft

AcknowledgmentA master thesis, the end of an era of intense academic and technical knowledge gathering. First ofall I want to thank my thesis supervisor Jian Guo for his support throughout the years leading to andduring my thesis. I specially want to give thanks to Johan Carvajal Godínez for his excellent insight inthe technical work of my thesis, bringing my thesis to a successful ending in the past four months.

The technical content of this thesis would not be done justice without the English writing support byColin Moore. Colin thank you for the numerous improvements on my writing and the extensive discus-sions about the English language.

A master thesis, the ultimate test before one can call himself a Master of Science. This thesis didnot only tested me on a technical and academic level, but more than ever I was tested on a personallevel. This personal endurance run might be far more intense and challenging than the technical oracademic task at hand.

The past years I have grown tremendously due to this personal endurance run, this thesis beingthe catalyst for it. I am glad this happened, not for the intense doubt or the anger and stress it broughtme, but for every individual person that contributed in any, minor or major, step in helping me grow andconquer this hurdle.

I want to thank my parents, Margreeth and Bram, and my brother, Bas, for always supporting mefrom the beginning of this run till the end without every doubting I would make it, especially when Iwas the one doubting it the most. I want to thank all my friends that listened to me, gave advice andbelieved in me to succeed.

I want to thank Inge and Inge’s group for the past 2.5 years of weekly meetings. These momentsevery week made me a better person and motivated me to finish my master degree. You all helped mein a way hard to imagine and I know that each and every one of you will manage to succeed. I hopedI could helped you as much as you all helped me.

Thank you all! This was not possible without you!

Joost van der GaagDelft, May 2017

iii

Contents

Acknowledgment iii

Acronyms x

List of Figures xi

List of Tables xiii

Abstract xvii

1 Introduction 11.1 Need For Fault Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 State-of-the-Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Research Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Scope of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.7 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Tools 72.1 SysML Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Systems Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Trade-Off Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 Possible SysML Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.4 Trade-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 COMPASS Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 SLIM 3.0 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 System Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Modeling Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.4 Fault Injection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.5 Creating Analysis Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.6 Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Other Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Atom Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.2 IntelliJ IDEA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 The SysML to SLIM Transformation Methodology 253.1 High-Level Methodology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 OOSEM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Model Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 Analyze Stakeholder Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.3 Define System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.4 Define Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.5 Synthesize Candidate-Allocated Architectures . . . . . . . . . . . . . . . . . . . . 28

3.3 SSTM Modeling Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.1 Custom Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Subsystem Node Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.3 Creating Nominal Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.4 Defining Subcomponent Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.5 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.6 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.7 Connecting Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

v

vi Contents

3.3.8 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.9 Subcomponent Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.10 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.11 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.12 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.13 Pseudo States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.14 Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.15 Error Injection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.16 Pattern Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4 Transformation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.1 Detailed Algorithm Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5 Extracting SysML Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5.1 Structure of SysML Model Source File . . . . . . . . . . . . . . . . . . . . . . . . 393.5.2 Extract Stereotype Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.3 Extracting UML Model Information. . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.4 Combine UML Model and Stereotype Instances . . . . . . . . . . . . . . . . . . . 40

3.6 SysML to SLIM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.1 SLIM Components Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.2 Mapping Nominal Component Structure . . . . . . . . . . . . . . . . . . . . . . . 423.6.3 Creating Subcomponents and Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 433.6.4 Finalizing Structure and Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.6.5 Mapping Error Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.6 Create Error Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.7 Limitation of the SSTM Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.7.1 Entire Model is Transformed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.7.2 Missing Automatic Detection of Port Connections Direction . . . . . . . . . . . . . 443.7.3 Constraint Can Only Be Used Once . . . . . . . . . . . . . . . . . . . . . . . . . . 443.7.4 Shallow References in SysML Model . . . . . . . . . . . . . . . . . . . . . . . . . 443.7.5 Single State Machine per Component. . . . . . . . . . . . . . . . . . . . . . . . . 45

4 SSTM Methodology Verification 474.1 The battery-Sensor System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Battery-Sensor SysML Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Modeling the Package Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.2 Creating the Main Components Using a Decomposition Diagram . . . . . . . . . . 494.2.3 Creating the Component Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.4 Model Component Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.5 Modeling Error Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.6 Adding Pattern Properties to the Model . . . . . . . . . . . . . . . . . . . . . . . . 544.2.7 Transforming the SysML Model into SLIM Code . . . . . . . . . . . . . . . . . . . 54

4.3 SLIM Model Battery-Sensor System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3.1 Adding Pattern Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.2 Modeling Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4 Comparing the Manual and Automatically Created SLIM Codes. . . . . . . . . . . . . . . 554.4.1 Verifying the Model and Improving the SSTM Transformation Tool . . . . . . . . . 554.4.2 Code Differences Between Automatically and Manually Generated Codes . . . . . 55

4.5 Comparing COMPASS Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.5.1 Simulating the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.5.2 Fault Tree Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.5.3 FDIR Fault Isolation Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.6 SSTM Methodology Requirements Verification . . . . . . . . . . . . . . . . . . . . . . . . 604.6.1 1 Modeling Method Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.6.2 2 SSTM Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.6.3 3 COMPASS Result Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Contents vii

4.7 Time, Ease-of-Use, and Error Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 634.7.1 Modeling Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.7.2 Modeling Ease-of-Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.7.3 Error Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.7.4 Time and Cost Savings Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.8 Answering First Sub-Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 ADCS Case Study 675.1 Overview of the ADCS System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2 Modeling the Nominal System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.1 EPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2.2 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2.3 IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2.4 Reaction Wheel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2.5 ADCS Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2.6 The ADCS System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2.7 CDHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2.8 Enclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3 Modeling the Error Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.3.1 EPS Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3.2 Computer Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3.3 GPS Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3.4 IMU Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3.5 Reaction Wheel Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.4 Transforming the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.4.1 Trigger Required for Error Transition . . . . . . . . . . . . . . . . . . . . . . . . . 795.4.2 Error Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.4.3 Clock Reset to 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.4.4 Transition with Probabilistic Event and Guard . . . . . . . . . . . . . . . . . . . . 79

5.5 ADCS SLIM Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5.1 SLIM Code of the adcsComputer Component. . . . . . . . . . . . . . . . . . . . 805.5.2 SLIM Code of the FDIR_CDHS Component . . . . . . . . . . . . . . . . . . . . . . 80

5.6 COMPASS Analysis and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6.1 Simulating the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6.2 Fault Tree Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.6.3 FDIR Fault Isolation Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Discussion and Roadmap 896.1 Option to Select Physical Nodes for Transformation . . . . . . . . . . . . . . . . . . . . . 896.2 Automatic Creation of an Enclosure Component . . . . . . . . . . . . . . . . . . . . . . . 896.3 Automatic Direction Detection for Connections . . . . . . . . . . . . . . . . . . . . . . . . 896.4 Removing Shallow References in Multiple Modeling Elements . . . . . . . . . . . . . . . 906.5 Creating Custom Stereotypes for Flows and Connections . . . . . . . . . . . . . . . . . . 906.6 Using Multiplicity in Part Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.7 Using Constraints for Modeling Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.8 Data Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.9 Bus-Modeling Using Data Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.10 Deactivating and Reactivating Components . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.10.1 Adding an Activation State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.11 Generic Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.12 Better Timing Modeling Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.13 Adding Reset Events to Error Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.14 Adding Error Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.15 Support All SLIM Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.16 Improvements Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.16.1 Prioritizing Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.16.2 Improvement Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

viii Contents

6.17 Answering Second Sub-Research Question . . . . . . . . . . . . . . . . . . . . . . . . . 956.18 Full Model to Model Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7 Conclusion and Recommendations 977.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.1.1 Answering Research Question. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.2.1 Recommendations for the Improvement Process of SSTM . . . . . . . . . . . . . 997.2.2 Solving the Gap Between COMPASS and TASTE . . . . . . . . . . . . . . . . . . 99

A SSTM SysML Modeling Steps 101A.1 Creating a New Project and Adding an SSTM Profile . . . . . . . . . . . . . . . . . . . .101A.2 Create Starter Package Structure Following an Adapted OOSEM Strategy. . . . . . . . .101A.3 Create Black Box Specification and Node BDD. . . . . . . . . . . . . . . . . . . . . . . .102A.4 Create Value Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102A.5 Create Node Specific Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . .102A.6 Node BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102A.7 Creating Nominal Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

A.7.1 Element IBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103Creating Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Importing Subcomponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Creating Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Creating Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A.7.2 Element State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Pseudo State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

A.8 Creating Error Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104A.8.1 Error Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

Error Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Error States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Error Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A.8.2 Error Injection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105Error Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Error State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Error Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Error Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

B Source code 107

C Current Methodologies and Evaluation Criteria 121C.1 INCOSE Object-Oriented Systems Engineering Method . . . . . . . . . . . . . . . . . . .121

C.1.1 Model Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122C.1.2 Analyze Stakeholder Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123C.1.3 Define System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123C.1.4 Define Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123C.1.5 Synthesize Candidate Allocated Architectures . . . . . . . . . . . . . . . . . . . .123

C.2 Catalogue of System and Software Properties . . . . . . . . . . . . . . . . . . . . . . . .125

Bibliography 127

AcronymsAADL Architecture Analysis & Design Language. 3, 13, 14, 42, 99, 121, 126

ADCS Attitude Determination and Control System. vii, xi, xii, xvii, 2, 3, 67–69, 71, 72, 75, 77, 80–84,91, 98, 114, 125

ASSERT Automated proof-based System and Software Engineering for Real-Time applications. x, 2,99

BDD Block Definition Diagram. viii, 8, 10, 28, 29, 32, 49, 102, 103, 123, 124

CAD Computer-Aided Design. 1, 2, 125

CDHS Command and Data Handling System. vii, xi, 68, 71, 74, 75

COMPASS Correctness, Modeling and Performance of Aerospace Systems. v–viii, xvii, 2–5, 7, 13–15, 17–20, 25, 26, 29, 30, 35, 43, 47, 49, 54–59, 61–64, 67, 79–81, 83, 85, 87, 89, 90, 92, 97–99,102

COTS Commercial Of The Shelf. 124

CSSP Catalogue of System and Software Properties. viii, 18, 125, 126

DoD Department of Defence. 2

ECSS European Cooperation for Space Standardization. 125

EPS Electrical Power System. vii, xi, 68, 71, 72, 75, 77

ESA European Space Agency. 2, 3, 13, 14, 99

FDIR Fault Detection, Isolation and Recovery. vi, vii, xi, xii, 14, 19, 20, 30–32, 42, 48, 51, 54, 57–61,68, 71, 80–82, 85–88

FMEA Failure Mode and Effects Analysis Another. 19, 20

GUI Graphical User Interface. xvii, 18, 19, 35, 37, 38, 55

IBD Internal Block Diagram. viii, xi, 8, 28, 29, 33, 49–51, 69, 71–74, 76, 90, 91, 103, 123, 124

IBM International Business Machines Corporation. 26, 121

IDE Integrated Development Environment. 21

IMU Inertial Measurement Unit. vii, 15, 68, 69, 71, 72, 77–79, 91

INCOSE International Council on Systems Engineering. viii, 26, 121, 123

JPL Jet Propulsion Laboratory. 2, 26, 121

MBESE Model Based Embedded Software Engineering. 3–5, 97

MBSE Model-Based Systems Engineering. xvii, 1–5, 7, 26, 90, 97, 99, 121

MDSM Model-Driven Systems Development. 26, 121

ix

x Acronyms

MOE Measure Of Effectiveness. 124

MXL Michigan Exploration Lab. 2

NASA National Aeronautics and Space Aministration. 2

OCL Object Constraint Language. 34, 104

OMG Object Management Group. 7

OOSEM Object-Oriented Systems Engineering Method. v, viii, xvii, 2, 3, 25–30, 48, 97, 101, 121–125

OPM Object-Process Methodology. 26, 121

PSU Power System Unit. xi, 47–50, 52, 58, 60, 62

RAX Radio Aurora Explorer. 2

ROI Return Of Investment. xi, 63, 65

RUP SE Rational Unified Process for Systems Engineering. 26, 121

SA State Analysis. 26, 121

SE System Engineering. 2

SLIM System-Level Integrated Modeling. v–vii, xi, xiii, xvii, 3–5, 7, 13, 14, 17–22, 25–27, 30–45, 47,52–57, 61–65, 67, 77–80, 89–95, 97–99, 101, 103, 104, 114

SSTM SysML to SLIM Transformation Methodology. v, vi, viii, xi, xiii, xvii, 3–5, 7, 12, 13, 21, 25, 26,29–42, 44–50, 52, 54, 55, 60–67, 72, 77–79, 89–95, 97–99, 101–104, 107

SSWG Space Systems Working Group. 2

SysML Systems Modeling Language. v, vi, viii, xi, xiii, xvii, 2–5, 7–13, 20, 25–30, 32–44, 47–49, 51,53–57, 61–67, 72, 79, 80, 89–92, 94, 95, 97–99, 101, 102, 104, 121, 122

TASTE The ASSERT Set of Tools for Engineering. viii, 2, 14, 99, 121

TFPG Times Failure Propagation Graphs. 19, 20

UML Unified Modelling Language. vi, xi, 7–10, 12, 30, 38–41, 50, 125

XMI Extensible Markup Language (XML) Metadata Interchange. 36, 38–40

XML Extensible Markup Language. x, 36, 39

List of Figures

1.1 Position of thesis scope in “V-model” edited from [33] . . . . . . . . . . . . . . . . . . . 4

2.1 SysML is derived from UML, some parts are (re)used, others are new [12] . . . . . . . . 82.2 SysML diagram taxonomy [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 The four pillars of SysML [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Example regex expressions for SLIM highlighting rules in Atom editor . . . . . . . . . . 212.5 Difference between SLIM highlighted code (left) and plain text (right) . . . . . . . . . . . 222.6 IntelliJ IDEA editor window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 High-level overview of the methodology to connect SysML and SLIM models . . . . . . 273.2 SSTM modeling work flow diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 SSTM profile diagram version 0.0.40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Flow connected to a port of the component . . . . . . . . . . . . . . . . . . . . . . . . . 333.5 Flow connected to a subcomponent port . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.6 SSTM transformation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.7 Process and data overview of the SSTM tool procedure . . . . . . . . . . . . . . . . . . 46

4.1 Graphical representation of the battery-sensor system . . . . . . . . . . . . . . . . . . . 484.2 Node package structure for battery-sensor experiment . . . . . . . . . . . . . . . . . . . 484.3 Node decomposition, with all components for the battery-sensor experiment . . . . . . . 494.4 Internal Block Diagram of the Power System Unit (PSU) component . . . . . . . . . . . 504.5 Internal Block Diagram of the System component . . . . . . . . . . . . . . . . . . . . . . 504.6 Internal Block Diagram of the Enclosure component . . . . . . . . . . . . . . . . . . . . 514.7 State machine diagram of the system component . . . . . . . . . . . . . . . . . . . . . . 514.8 State machine diagram of the battery component . . . . . . . . . . . . . . . . . . . . . . 524.9 State machine of the PermanentFailure error component . . . . . . . . . . . . . . . 534.10 Settings for the sensor error effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.11 Interface of the SSTM tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.12 Random simulation stack trace of the battery-sensor system . . . . . . . . . . . . . . . 584.13 Fault tree for automatically generated battery-sensor system model . . . . . . . . . . . 594.14 FDIR fault isolation tree for alarm alarm_battery . . . . . . . . . . . . . . . . . . . . . . . 594.15 FDIR fault isolation tree for alarm alarm_battery_1 . . . . . . . . . . . . . . . . . . . . . 604.16 FDIR fault isolation tree for alarm alarm_battery_2 . . . . . . . . . . . . . . . . . . . . . 614.17 SSTM Return Of Investment (ROI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Graphical representation of ADCS case study system . . . . . . . . . . . . . . . . . . . 695.2 State machine of the GPS component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3 State machine of the reaction wheel component . . . . . . . . . . . . . . . . . . . . . . 705.4 IBD of the ADCS computer component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.5 State machine of the ADCS computer component . . . . . . . . . . . . . . . . . . . . . 725.6 IBD of the system component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.7 IBD of the CDHS component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.8 State machine of the CDHS component . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.9 IBD of the enclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.10 State machine of the EPS error model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.11 Simplified gps error model, Bruintjes [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.12 Reaction wheel error model first iteration state machine . . . . . . . . . . . . . . . . . . 785.13 Random simulation stack trace of the ADCS case study . . . . . . . . . . . . . . . . . . 815.14 Probabilities for ADCS fault tree analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 82

xi

xii List of Figures

5.15 ADCS fault tree for a failed system, part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 835.16 ADCS fault tree for a failed system, part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 845.17 FDIR fault isolation tree for alarm alarm_eps . . . . . . . . . . . . . . . . . . . . . . . 855.18 FDIR fault isolation tree for alarm alarm_master_computer . . . . . . . . . . . . . . 865.19 FDIR fault isolation tree for alarm alarm_rw1 . . . . . . . . . . . . . . . . . . . . . . . 875.20 FDIR fault isolation tree for alarm alarm_save_state . . . . . . . . . . . . . . . . . . 88

List of Tables

2.1 SysML tools trade-off table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 SSTM custom stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Supported SLIM components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Software engineer and space systems engineer salaries . . . . . . . . . . . . . . . . . . 644.2 SSTM development cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3 Iteration cost per year, with and without the use of SSTM . . . . . . . . . . . . . . . . . 65

6.1 SSTM improvement scoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

xiii

Listings2.1 SLIM type declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 SLIM implementation declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 SLIM subcomponents and ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 SLIM modes, states and transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 SLIM timed specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 SLIM error model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 SLIM fault injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1 Transitions in the manually generated code . . . . . . . . . . . . . . . . . . . . . . . . . 564.2 Transitions in the automatically generated code . . . . . . . . . . . . . . . . . . . . . . . 565.1 adcsComputer component implementation code . . . . . . . . . . . . . . . . . . . . . 805.2 FDIR_CDHS component implementation code . . . . . . . . . . . . . . . . . . . . . . . . 80B.1 Automatically generated battery-sensor SLIM code . . . . . . . . . . . . . . . . . . . . . 107B.2 Manually written battery-sensor SLIM code . . . . . . . . . . . . . . . . . . . . . . . . . 110B.3 Generated SLIM code for the ADCS case study . . . . . . . . . . . . . . . . . . . . . . . 114

xv

AbstractIdentifying faults early on in the design phase drastically reduces the cost of fixing them and can evenprevent the loss of a spacecraft. The Correctness, Modeling and Performance of Aerospace Systems(COMPASS) project created a toolset to approach the design of systems with a model-based angle,specifically critical on-board systems for the space domain. The COMPASS toolset requires an inputmodel written in the high-level System-Level Integrated Modeling (SLIM) language.

Systems engineers working with a Model-Based Systems Engineering (MBSE) approach commonlyuse a graphical modeling language to model systems on an architectural level. One of modeling lan-guages most used for this purpose is Systems Modeling Language (SysML).

For optimal use of the COMPASS toolset in an MBSE design project, a smooth transition betweenSysML and SLIM is desired. There is currently a gap between these two languages is present. Thechallenge lays in the fact that systems engineers using a graphical modeling language are not softwareengineers, which limits the ability to model the architectural SysML model in SLIM.

This thesis presents a new developed methodology, the SysML to SLIM Transformation Methodol-ogy (SSTM), to develop a space SysML model which is able to automatically transform a SysML modelinto a SLIM model, ready to be imported by the COMPASS toolset. This allows a systems engineerwithout software engineering knowledge to model in a familiar modeling environment, but adds theability to directly run tests on the model using the COMPASS toolset thus giving valuable insight intothe behavior, limitations and possible errors of the system under development. Ultimately reducingdevelopment time and cost.

A methodology based on the Object-Oriented Systems Engineering Method (OOSEM) method iscreated that introduces a set of custom stereotypes. Modeling with these stereotypes allow the trans-formation tool to automatically transform the SysML model into a SLIM model.

The open-source, Eclipse-based modeling environment, Papyrus is used to model the SysMLmodel. A profile with the required stereotypes is developed which can be imported and used in Papyrusprojects. The transformation tool, written in Java, has a simple Graphical User Interface (GUI) to loadthe SysML model and save it as a SLIM model.

Two experiments were executed and are presented in this thesis. Verifying the SSTM methodologyand transformation tool was themain focus point of the first experiment in which a battery-sensor systemwas modeled. A second experiment was performed modeling an Attitude Determination and ControlSystem (ADCS) case study to test the possibilities and limitations of modeling a complex space relatedsystem and identifying improvement points for the SSTM methodology.

The first experiment successfully verified that using the SSTM methodology a SysML model can bedeveloped without significantly more effort than to develop any other SysML model. It also verified thatthe tool successfully transformed the SysML model into a correct SLIM model that can be used in theCOMPASS toolset.

The second experiment, modeling an ADCS case study, showed that a simple space system cansuccessfully be developed with the SSTM methodology. The case study also identified important im-provement points for the SSTM methodology to model complex space systems.

The experiments performed show that the SSTM methodology and transformation tool togetherbridge the gap between SysML and SLIM models and can be analyzed in the COMPASS toolset. Thiscan be performed without significantly more modeling effort and in-depth programming knowledge. Atthis stage the SSTM methodology and transformation tool are ready to be used on component-basedsystems with event-based error models. Improvements in the SSTM methodology are proposed. Theimprovements will increase the maturity of the SSTM methodology and allow the modeler to modelcomplex space systems SysML models with more ease and with less programming knowledge.

xvii

1Introduction

Model-Based Systems Engineering (MBSE) is a new way of performing systems engineering. “Model-based systems engineering: Revolution or evolution” by Brown [6] asks the question of whether it isa totally new concept or an evolution comparable to the evolution of Computer-Aided Design (CAD)models replacing paper-based drawings. MBSE is still on its way to becoming accepted as the stan-dard for systems engineering. Important to becoming accepted is the continuous refinement of MBSE.

1.1. Need For Fault IdentificationThe space industry has always been at the frontier of new technology. The complexity of the systemshas driven the technological advancement in the space sector to its limits. MBSE is part of a methodto control this complexity and has been investigated and used in the space industry for several years,mainly for the hardware development of space systems.

The space industry, as most of the technical industry, is heavily dependent on software and em-bedded systems to give the products a “brain”. Therefore, during product development, it is importantfor the interaction between the hardware and software parts of the project to be as optimal as possi-ble. This reduces work, development time, and costs. However, this interaction in the space industrybetween the hardware and software in MBSE is not yet established [19]. MBSE is more common to beused in the software industry and can be of help in developing new MBSE methodologies and tools forsystems engineering.

Most faults introduced during the development cycle of a system are introduced early on in thesystem and software design phases. Although 70% of all faults can be traced back to these phases,only 3.5% is detected at this point [13]. Fault discovery and removal during later systems developmentcycle stages have an estimated 110 times higher costs than when they are discovered and removeddirectly [13]. It is therefore of great importance to detect these faults as soon as possible to reduce theoverall development cost of a system.

1.2. State-of-the-ArtThe use of MBSE is being investigated throughout industries. Studies to investigate the investmentand result of MBSE have shown that initial investment is needed which can result in tremendous im-provements to the design process and reduction of costs [3][38][45]. MBSE not only gives more insightinto the design but also allows for early design analysis on the model. This early analysis will resultsin early fault detection which will reduces the overall project costs [13].

Reuse of information is made easier using MBSE, because the information is not stored in unlinkeddocuments but in a software model. “This can simplify the development of new products, and conse-quently reduce development costs.” [25]

Development of small satellites normally takes less time. MBSE is used in the development ofthese small satellites, cubesats [41],[21],[30] made by small space companies or universities. The

1

2 1. Introduction

frequent change in students at universities working on these problemsmake it hard to use the traditionaldocument-based System Engineering (SE).

Spangelo et al. [41] describes the modeling of a cubesat using Systems Modeling Language(SysML) as the model language. This is Phase 1 of the Space Systems Working Group (SSWG)MBSE project. The cubesat modeled is the Radio Aurora Explorer (RAX) cubesat developed by theMichigan Exploration Lab (MXL). Before modeling the RAX satellite, the hypothetical satellite FireSatwas modeled in phase 0.

The cubesat modeling framework is created by applying the Object-Oriented Systems EngineeringMethod (OOSEM). The framework provides the basic building blocks (stereotypes in SysML) to beused in building a cubesat model.

Kaslow et al. [21] follows up on the RAX cubesat modeled with SysML and focuses on designinga cubesat reference model to be used for later projects. This is phase 4 of the SSWG project. Theprevious phases are Phase 0: [41]. Phase 1: [41]. Phase 2: [42]. Phase 3: [2], [20]. Phase 4 focuseson the distribution of the model.

The RAX satellite describes a detailed use of sensors for Attitude Determination and Control System(ADCS)[44][43]. Chapter 5 elaborates more on this.

Nottage et al. [30] describes the modeling of a cubesat in a university team, it discusses the creationof the model and the specific advantages for small teams with high personnel turnover and limited timecommitment.

MBSE is not only used in small satellite projects. Proposals and studies on how to use MBSE inlarge space systems have been performed [18], [9], [1].

Jepperson [18] investigated the use of MBSE for space systems in the Department of Defence(DoD). The thesis concluded that MBSE can be extremely powerful, however a fundamental paradigmshift is required to apply MBSE. Implementing a standard data exchange specification can be appliedearlier to begin taking advantage of the MBSE structure.

Cole et al. [9] describes a pilot with SysML as the MBSE language for the Jet Propulsion Laboratory(JPL). MagicDraw is the used tool used for the pilot and integration with multiple analytical modelsoftware such as MATLAB/Simulink and Mathematica. The paper concludes that most of the toolsare mature enough to be used, with some adaptations. It also presents several principles concerningworking with MBSE.

Alexander et al. [1] describes the evaluation of SysML for The Aerospace Corporation. This wasdone by designing a small satellite system with SysML. This model is based on the Tactical Satellite-3System. This evaluation concludes that SysML is adequate to address system engineer’s needs.

Other projects from the National Aeronautics and Space Aministration (NASA) are investigatingMBSE: [45], [3], [38]. Vipavetz et al. [45] discusses a pilot with MBSE and SysML on NASA’s MaterialsInternational Space Station Experiment-X project. The pilot focused on the early phases of the design.It concludes that the investment is significant, but the yield can be significant as well. Bayer et al. [3]also concludes that using MBSE in early development has a positive outcome on the durability andrichness of the information communicated throughout the project. Polit-Casillas et al. [38] focuses onthe practical application for better interaction between SysML and CAD software in MBSE.

OOSEM has been used for the development of the cubesat framework[21][41]. Several other MBSEmethodologies to develop systems are present in literature [12][14][24][26][27][47]. Section 3.2 and Ap-pendix C elaborate on the use and trade-off of multiple MBSE methodologies.

The European Space Agency (ESA) is investigating MBSE as system engineering method multipleprojects are under investigation and several tools and toolsets are being developed [11]. The Auto-mated proof-based System and Software Engineering for Real-Time applications (ASSERT) Set ofTools for Engineering (TASTE) is one of these toolsets under development [8]. Correctness, Modelingand Performance of Aerospace Systems (COMPASS) is another tool being developed by the universityof Aachen [28], supported by ESA.

1.3. Research Question 3

1.3. Research QuestionThe initial research question of this thesis was defined as: “Which key improvements to link Model-Based Systems Engineering and Model Based Embedded Software Engineering can be identified anddemonstrated on a case study that focuses on an Attitude Determination and Control System?”.

This research question turned out to be to broad and needed to be refined and the scope needed tobe narrowed. The narrowing of the scope was needed to have scientific viable results for this thesis. Inorder to narrow the scope more research was carried out, finally leading to a tool used by ESA, calledCOMPASS.

RWTH Aachen University, financially supported by ESA, developed COMPASS [10]. COMPASSis a toolset developed to analysis embedded systems. Typically, it is designed to analyze critical flightsoftware. The COMPASS tool allows software engineers to create models of the system that can beimported into the tool. Once imported the models can be analyzed. The input models need to be writtenin the System-Level Integrated Modeling (SLIM) languages, which is based on Architecture Analysis &Design Language (AADL) [5].

However, in practice, there is a gap between modeling the architectural model and analyzing a moredetailed model using COMPASS [19]. This gap is positioned on the transitioning point of the architec-tural mode, commonly written in a high-level modeling language such as SysML, and the COMPASSinput models written in SLIM.

The identified gap resulted into an improved research question with several sub-research questions:

1. Is it possible to achieve a full model to model transformation between SysML and SLIM?

1.1. What are the minimal requirements to have a functional model to model transformation be-tween SysML and SLIM?

1.1.1. Which methods are needed for a minimal functional model to model transformation?1.1.2. Which tools are needed for a minimal functional model to model transformation?1.1.3. How is the minimal transformation performed?

1.2. Which improvements to the minimal transformation will allow a full model to model transfor-mation?

1.2.1. What are the missing functionalities of the minimal transformation?

1.4. Research StrategyThe main research strategy of this thesis is the grounded theory approach. Known methods and toolsare used as a starting point. A methodology is then developed and verified using two case studies.The first case study is used to verify the minimal required transformation. The second case study isused to find the limitations and to identify the improvements needed.

1.5. Scope of the ThesisThis thesis proposes a new methodology, SysML to SLIM Transformation Methodology (SSTM), ac-companied by a newly developed transformation tool to bridge this gap. The SSTMmethodology allowssystems engineers to model the system using SysML. The SSTM methodology is based on OOSEM,thus allowing it to have a strong systems engineering approach while modeling the architectural model.The SSTM methodology defines steps that need to be performed in order to make the architecturalmodel ready to be transformed into a SLIM model. This transformation tool automatically transformsthe SysML model created with the SSTM methodology into a SLIM model that can be imported directlyinto the COMPASS toolset. Using the SSTM methodology and transformation tool allows systems en-gineers to communicate and exchange SysML model with software engineers and use the analyzingcapabilities of COMPASS early on in the design.

4 1. Introduction

The SSTMmethod improves the interaction between MBSE and Model Based Embedded SoftwareEngineering (MBESE). The SSTM methodology is positioned at the beginning of the detailed designprocess in the “V-model”, seen in Figure 1.1.

Figure 1.1: Position of thesis scope in “V-model” edited from [33]

The SSTM methodology and transformation tool need to be verified. Three categories of require-ments are established. The first category is for the requirements of the modeling method of the SSTMmethodology. The second requirement category is for the transformation tool supporting the SSTMmethodology. The last category sets a requirement on the use of the results from the COMPASStoolset. The three categories with the corresponding requirements are listed below.

1. SSTM modeling method related requirements:

1.1. SSTM shall provide a profile that will be used to model systems with the SSTMmethodology.1.2. SSTM shall give modeling steps, interpretable by a systems engineer, to model component-

based systems.1.3. SSTM shall give modeling steps, interpretable by a systems engineer, to model timed be-

havior modeling for the system of interest.1.4. SSTM shall give modeling steps, interpretable by a systems engineer, to model event-based

errors.1.5. SSTM shall give modeling steps, interpretable by a systems engineer, to model injection of

errors in the nominal model.

2. SSTM transformation tool-related requirement:

2.1. The SSTM transformation tool shall be able to automatically transform SysMLmodels, madeusing the SSTM profile and method, into compilable SLIM models.

3. COMPASS result related requirement:

3.1. The results from the COMPASS toolset shall enable the refinement of the SysML model.

These requirements are verified by modeling a case study. A full procedure of modeling the SysMLmodel with the SSTM methodology, transforming it using the transformation tool, and finally testing thegenerated SLIM model, is performed to verify the requirements. This is described in Chapter 4. Once

1.6. Thesis Structure 5

these requirements have been met, it is possible to identify the limitations of the SSTM methodologyresulting in the definition of future improvements.

1.6. Thesis StructureMultiple SysML editors were used during this thesis to model with SysML. A trade-off between theavailable editors is presented in Chapter 2. The use of COMPASS and the used SLIM and Java editorare also discussed.

Chapter 3 discusses the SSTM methodology and transformation tool including the most importantSysML modeling steps as well as the high-level transformation process.

The verification of the methodology and tool is done by modeling a battery-sensor system. Thissystem is a known system and is one of the example systems of COMPASS. This verification processis described in Chapter 4.

With the methodology verified it is possible to identify the limits of the SSTM methodology. Thisis done by modeling a more complex model compared to the battery-sensor system. This process isdescribed in Chapter 5.

While verifying and searching for the limitations of the SSTM methodology numerous improvementpoints were identified. Chapter 6 lists all the improvement points. This chapter also provides a roadmapdirecting the future development of the SSTM methodology and transformation tool.

The conclusions on the work performed and recommendations for future research are presented inChapter 7.

1.7. ContributionThis thesis describes the development of the SSTMmethodology. It provides detailed steps to developa SysML model that can be transformed with the accompanied transformation tool to a SLIM modelthat can be compiled and used in the COMPASS toolset.

More importantly, the SSTMmethodology provides a better connection betweenMBSE andMBESE,thereby improving the interaction between the architectural design and embedded software design.This ultimately contributes to an improved design process, resulting in space systems designed withmore confident due to the early availability of verification on model level. This improved design processwith early verification at the model level will reduce the total development costs of space systems.

2Tools

MBSE is highly dependable on models. These models are created and edited using several programsor software tools. These tools have a significant influence on the final methodology. This chapter there-fore presents the tools used in this methodology.

The first tool to be discussed is the SysML editor tool. Several SysML editor tools were evaluatedfor this thesis. A trade-off between these tools is presented, with a final winner used throughout therest of the thesis. This is followed by a description of the COMPASS toolset and the correspondingSLIM language. The COMPASS toolset is the final tool in the tool chain for this thesis. The last sectionof this chapter presents several tools that were used during the thesis.

2.1. SysML ToolsOne of the sub research questions that needs to be answered is which SysML editor tool will be usedfor the transformation. A SysML editor tool is one of the most important tools in the methodology. Thisis because a simple editor will not work in creating SysML models, and because SysML is a graphicallanguage, which uses graphics to store and convey information to the user. A graphical editor is thusof utmost importance.

This section briefly describes the SysML language and the process of selecting the SysML editortool used in the thesis. Knowing the SysML language is important to evaluate possible SysML editors.Several editor tools were identified but only one was selected that suited the thesis and the develop-ment of the SSTM methodology best. The process of finding the best option is the trade-off, describedin the rest of the section.

First of all, an overview of the language is presented in Subsection 2.1.1. Following is Subsection2.1.2, discussing the criteria used in the trade-off. This is followed by presenting the possible tools.Finally, Subsections 2.1.2, 2.1.3, and 2.1.4 elaborate on the actual trade-off criteria, possible SysMLeditors, and the final outcome of the trade-off.

2.1.1. Systems Modeling LanguageSysML is a graphical MBSE language managed by the Object Management Group (OMG). SysML isderived from the Unified Modelling Language (UML). In 1999, OMG describes UML as follows “TheUnified Modeling Language (UML) provides system architects working on object analysis and designwith one consistent language for specifying, visualizing, constructing, and documenting the artifacts ofsoftware systems, as well as for business modeling.”[31]. The main focus of UML are software sys-tems. Throughout the following years more and more effort was put into UML to make it mare useful forsystems engineers. Several modifications were added. However, more modifications were still needed[16]. A call for a new profile designed for systems engineers was issued by OMG, trying to achieve“standard modelling language for Systems Engineering to analyze, specify, design, and verify complexsystems, intended to enhance system quality, improve the ability to exchange Systems Engineering in-

7

8 2. Tools

formation amongst tools, and help bridge the semantic gap between systems, software, and other engi-neering disciplines”[16][32]. This profile was created and called Systems Modeling Language (SysML).

SysML as UML is a modeling language creating a model instead of documents. This abstractmodel is edited and viewed through diagrams. Each diagram gives a specific view of the system,highlighting specific details of the central model. Creating a single model allows the model to representthe actual system far better than single design document. Instead of making a separate specificationdocument for each component in a system, which needs to be checked every time something changes,the component is modeled with constraints to the system and the required document is generated fromthe model. The generated document is automatically updated if the systems changes.

Modeling the diagrams allow specific users to view the part of the model they are interested inwithout all the unnecessary information. Diagrams from UML are reused, directly or modified, andother diagrams are introduced by SysML. A graphical representation can be seen in Figure 2.1.

Figure 2.1: SysML is derived from UML, some parts are (re)used, others are new [12]

As SysML is a subset / extension to UML, it uses multiple diagrams to define the model. Figure 2.2shows the diagrams used in SysML and their relationships. This figure shows the diagrams directlyused from UML, adapted UML diagrams, and new diagrams defined by SysML. SysML is based onfour pillars, these pillars are the structure-, behavior-, requirements-, and the parametrics pillars. Thestructure and behavior pillars contain multiple diagram types, whereas the requirements and paramet-rics pillars only consist of the corresponding diagram. The parametrics pillar is defined as a separatepillar but the parametric diagram, located in the structure diagram, is a generalization of the InternalBlock Diagram. A brief overview of example diagrams for each pillar is shown in Figure 2.3.

Structure pillar The first pillar of SysML is the structure pillar. Diagrams in this pillar determine thestatic structure of the system, how parts are connected and organized.

Block Definition Diagram (BDD) Blocks are the main element in a Block Definition Diagram(BDD). The blocks and the relations between these blocks dictate the structure or hierarchy of thesystem. Blocks present in BDD are described in more detail in other diagrams, e.g. in Internal BlockDiagram (IBD). Generalizations and association relationships connect different blocks in the diagram.

Internal Block Diagram (IBD) IBD is similar to a BDD. However, IBDs represent the internalstructure of a block defined in a BDD. An IBD does not shows blocks but it displays usages of blocks.IBD can show the flow between these block usages.

Package diagram A package diagram is an organizational diagram. It allows themodeler to struc-ture other diagrams that are closely related at the package level. Package diagrams can themselves

2.1. SysML Tools 9

Figure 2.2: SysML diagram taxonomy [16]

be nested in other package diagrams.

Behavior pillar The second pillar determines the dynamic behavior of a system. How the systemreacts to different input and states. The diagrams shows the order of behavior or events a systemundergoes over time.

Activity diagram The activity diagram’s main strength is to show the flow of objects, energy ordata over time in a system. Complex behaviors can be expressed in an activity diagram, e.g. what func-tion is executed depends on the control variables. Activity diagrams can display continuous behavior,a loop is created instead of a single flow of actions.

Sequence diagram The sequence diagram is the second behavior diagram and like the activitydiagram shows the dynamic behavior of the system. It however focuses on the exchange of calls,and asynchronous signals. It specifies from which exact part a signal comes and where it goes to dosomething. A sequence diagram is more suitable in detailed design than an activity diagram becauseit contains more exact information. The drawback of this is that due to the detailed information in thediagram the complexity increases quickly, which forces sequence diagrams to show a subset of thebehavior.

State machine diagram The state machine diagram is a dynamic diagram that focuses on thechange in the system’s structure in response to events. A state machine can display the dynamicbehavior of a block. Because a block can represent almost everything from an entire system until adetailed component, a statemachine can bemade for system behavior until single component behavior.

Use case diagram A use case diagram displays use cases of the system to be designed. It givesa black box view of what the system should do. Actors are linked to the use cases they want the systemto perform. A use case diagram is mostly used as an analysis tool to discover the functions the systemneeds to perform and is generally created early in the design cycle.

Requirements pillar The requirements pillar is new to SysML compared to UML. Defining require-ments and keeping track of them during the design is one of the major system engineering tasks.

10 2. Tools

Figure 2.3: The four pillars of SysML [16]

Requirement diagram The requirements diagram displays the requirements of the system. Notonly are requirements shown but also other modeling elements such as blocks and test cases that havea direct relation to a requirement. Several of these relationships exist in SysML. These are the con-tainment, trace, derive, refine, satisfy, and verify relationships. The containment relationship describesthat a requirement is contained in another requirement. The trace relationship traces one requirementto another. One requirement can be derived from another. A refined element is a more detailed wayto describe the parent requirement. A satisfying relationship connects the way a requirement can besatisfied. A test case can be connected to a requirement with the verify relationship.

Parametrics pillar The parametric pillar is just like the requirements pillar introduced in SysML com-pared to UML.

Parametric diagram The parametric diagram displays twomain things. The first is that a paramet-ric diagram displays the connection between constrain parameters in different constrain expressions.Secondly, it displays the connection between constrain parameters and value properties. Both containmore information on how constrain blocks in BDD are connected. This makes the constrains very pow-erful.

The four pillars and the corresponding diagrams describe the overall structure of SysML. However,in order to model with SysML and the presented diagrams, more language knowledge is needed. Thisis not presented here because it falls outside the scope of the thesis. Two books on how to model withSysML are “A Practical Guide to SysML: The system modeling language” by Friedenthal, Moore andSteiner and “SysML Distilled: A brief guide to the systems modeling language” by Delligatti. It is rec-

2.1. SysML Tools 11

ommended to read through these books to obtain the basic language knowledge while simultaneouslymodeling with it to gain practical knowledge in working with an editor.

2.1.2. Trade-Off CriteriaFour criteria were selected for this trade-off. Weights were given to each criterion such that the totalweight factor was 50. The full set of criteria and each weight were as follows:

• Cost (20)

• Usability (15)

• Support (10)

• Correctness of SysML rendering (5)

These four criteria were the main criteria for the tools trade-off. They were ordered by importance,where the first one was the most important and the last one the least.

Each criterion was scored with four possible scorings, ++, +, -, and --, where ++ (double plus) wasthe best and -- (double minus) was the worst. This scoring was quantified as follows: ++ equals 2, +equals 1, - equals -1, and -- equals -2. An middle score (+-) was not used to prevent neutral scoring.

Cost Cost was the one of the most important criteria for this trade-off. This is because the thesis hasa limited to non-existent budget. This criterion therefore has a great influence on the selection of thetool. Arguably, trail versions could have been used which would have reduced the actual cost for thethesis period. However, future work with the tool in the department of space engineering is desired,which is also included in the criteria. The acquisition cost as well as operation cost are included in thiscriterion.

Cost drove the trade-off as can be read further in this chapter and was therefore given almost halfof the total weight of the trade-off. The weight for cost was set to 20.

Usability Usability of the tool was the second, most important criterion. Due to the complexity ofSysML, a consistent and easy-to-use tool is desired. For example a tool that makes it hard to differen-tiate between multiple connections costs more time to learn and is more error-prone, which results inincorrect models.

Usability was almost as important as cost and was given a weight of 15 to count this in.

Support The second-to-last criterion to be judged on was support. As said, SysML is quite complex,which makes modeling using it a complex task as well. Good support on how to model using the toolcan make this much easier resulting in faster model development time with fewer incorrect models thanwithout any support for the tool.

Support was given a weight of 10.

Correctness of SysML rendering SysML is a graphical language. This means that information isshared and especially exchanged with users via visual diagrams. It is therefore important that the toolproduces correct diagrams according to the SysML specifications. This criterion looks purely at theoutcome of a correct model if the visuals correspond to that model. This is different from the secondcriterion; only the usability of the tool during the model creation process was observed here.

The correctness of SysML rendering was given a score of 5.

2.1.3. Possible SysML ToolsThree candidate tools were selected for the trade-off. These tools are shown below.

• PTC Integrity Modeler

• No Magic’s MagicDraw / Cameo Systems Modeler

• PolarSys’s Papyrus

12 2. Tools

PTC Integrity Modeler Integrity Modeler by PTC was selected because the Space Engineering de-partment previously had a license for Artisan Studio. Artego, Artisan Studio’s developer company, wasbought by PTC in 2014 and integrated into PTC Integrity Modeler. Due to the previous agreement withthe department and Artego this tools was selected.

MagicDraw / Cameo Systems Modeler No Magic’s MagicDraw or Cameo Systems Modeler wasthe second candidate. Cameo Systems Modeler is the package name where the required version ofMagicDraw and essential architectural modeling plugins such as the SysML plugin are bundled. Forreadability this option is named MagicDraw. MagicDraw is one of the most used SysML tools [8]. Itwas selected for this trade-off due to its popularity and easy interface.

PolarSys’s Papyrus Papyrus is an open-source SysML editor and is the successor to PolarSys’sTopcased, which was their previous UML and SysML editor. Papyrus was chosen because it is open-source and more importantly, free. It is the most used and maintained of all the free software programs.

2.1.4. Trade-OffThe three tools are scored on each criterion. The detailed scoring per tool is presented below. It issummarized in the last part of this subsection showing the final scoring in table format. The goal of thetrade-off was to select a SysML editor to use in the SSTM methodology.

PTC Integrity Modeler PTC Integrity Modeler has the lowest score of all candidates. This was mainlydue to the cost of the program. A trail version of the tool was tested to evaluate the tool. This evaluationwas successful and several contact forms were filled in to contact the company to discuss pricing andpossible academic options. The predecessor of PTC IM, Artisan Studio, is licensed to the department.The possibility to extend this with PTC IM would have been favorable for the thesis and future workin the department. Unfortunately, no response from PTC on the contact forms was received, severalphone calls were made to contact the Dutch service point of PTC all without success. This resulted inno information regarding possible pricing to use the tool, hence the lowest possible score for the cost.

During the trail period, other criteria were scored. The tool is very intuitive and easy to model with,thus scoring the maximum score for usability. One of the most important functions in modeling a SysMLmodel is to link elements to each other. This option is present by right-clicking an element in PTC IM.

Support for PTC IM is available. During the trail this was unfortunately not possible. It is thusscored with a single plus because a separate support forum is available for licensed customers whereall questions can be asked.

The last criterion, correctness of SysML rendering, was given a single plus as well. Almost allgraphical indications were correctly rendered. The missing graphical representations were slightlydifferentiating headers of diagrams and missing stereotype indications.

MagicDraw MagicDraw scored a second closely behind Papyrus. The cost of MagicDraw was givenone minus. Contact with the sales department of NoMagic, MagicDraws developer, was made. Thisresulted in an extensive overview of the services required to model SysML models using one or moreof their products. The cheapest option turned out to be Cameo Systems Modeler, which is a packageof several products including MagicDraw. The second option is MagicDraw plus the SysML plugin, butthis is more expensive than the former option. Funding for this tool was however not possible, thusresulting in the lower score. It was not given the lowest possible score because an evaluation key wasprovided for the duration of the thesis. This was used for the evaluation, however no continuation ofthe project can be performed using this key.

The usability of the tool was given the maximum score. Modeling with the tool is similar to PTC IMand very intuitive. It has a familiar Windows interface. No issues were found while using the tool for abrief test period.

A lot of support is provided online due to MagicDraw being one of the most used tools for modelingSysML models. This resulted in a positive (one plus) score for support.

MagicDraw has the best rendering of SysML diagrams of all three candidates. All diagrams wereaccording to the SysML specifications and no discrepancies were detected while using the tool. Severalpapers and books describe the use of MagicDraw in modeling SysMLmodels and diagrams, which also

2.2. COMPASS Tool 13

conform to SysML specifications. This results in the maximum score for the correctness of the SysMLrendering criteria.

Papyrus Papyrus is the only open source tool of the three candidates and is free to use. This resultsin the maximum score for the cost criterion. Being free comes with the cost of being less developedcompared to the other two candidates. This is represented in the scores of the remaining criteria.However active development of the tool is still being performed, which results in regular updates. Soscoring of this tool could change for future comparisons.

An extensive example was modeled using Papyrus. The tool has a higher learning curve comparedwith the other two but after this time and since the latest update of the tool the easy-of-use is almoston the same level as the usability of PTC IM or MagicDraw. This resulted in a positive (one plus) scorefor usability.

Support has a negative score (one min), this because a lot of questions and problems while mod-elling could not be answered or fixed as desired while modeling. Being an open-source and free tool,support needs to come from the community of users working with the tool. Support is therefore not asimportant or possible compared with the other tools, thus resulting in the lower score.

Lastly, the correctness of SysML rendering was scored with a negative score (one min) as well. Ofall the tools, Papyrus is the least correct according to the SysML specifications. For example, the entireframe for almost every diagram type is missing. It is however possible to model all elements and oncethe differences in representation of the elements was known it had no drawbacks for use in the thesis.Therefore only a single negative score was given instead of the lowest possible score.

Trade-off summary Table 2.1 shows this trade-off summary. It shows that Papyrus was the winnerof the trade-off. Papyrus was therefore used as the SysML editor for the thesis and for the developmentof the SSTM methodology.

Table 2.1: SysML tools trade-off table

Weight

PTC

Integrity

Modeler

MagicDraw

Papyrus

Cost 20 -- - ++Usability 15 ++ ++ +Support 10 + + -Correctness of SysML rendering 5 + ++ -Total 50 5 30 40

2.2. COMPASS Tool“The COMPASS project advances the system-software perspective by providing means for its valida-tion in the early design phases, such that system architecture, software architecture, and their interfac-ing requirements are aligned with the overall functional intents and risk tolerances.” [29]. Ideas for atool started in 2007 [29], advances in model checking triggered this. From these ideas, COMPASS wascreated with funding from the ESA. COMPASS uses a dialect from AADL, SLIM, for its modeling lan-guage. Models of the system are written in SLIM and can be imported into the COMPASS tool, whichcan automatically run several verification and validation checks on the model. Fault tree, deadlocksand more can be checked. This section gives a brief overview of the SLIM language, the COMPASStool and it’s possibilities.

COMPASS allows model checking at an early phase of the design process. This model checkingat architectural level allows the discovery of faults in the system earlier, thus reducing the cost of fixingthem [13]. The COMPASS tool uses SLIM models to be imported to describe the system; Section 2.2.1goes into detail on this language. Subsection 2.2.2 and Subsection 2.2.3 describe how to model the

14 2. Tools

nominal and error models used by the COMPASS toolset. Subsection 2.2.4 shows how fault injectionsare modeled. This is followed by Subsection 2.2.5 describing the creation of properties in SLIM whichare used for analysis in COMPASS. The tool itself allows the user to perform multiple analyses onthe model. These different options are described in Section 2.2.6. The global steps to in using theCOMPASS tool are as follows:

1. Describe the system and its behavior, nominal and error, using a text editor and the SLIM lan-guage.

2. Load the created SLIM files into the COMPASS toolset. The toolset checks the files for syntaxerrors.

3. In the case that error behavior is used, connect the nominal behavior and the error behavior usingfault injection. This can be done in two ways, both are described in Subsection 2.2.4.

4. The dynamic behavior can be investigated using the simulation features of COMPASS.

5. Write properties for the system, these will be used in other analyses.

6. More complex analyses can be performed using the model and the properties created. The kindof analyses depends on the way the model is created using the SLIM language.[22]

Properties are an important part of using the COMPASS toolset and allow for more complicated an-alyzing options. Due to its importance Section 2.2.5 describes the method of creating these properties.

2.2.1. SLIM 3.0 LanguageSLIM is the input language for the COMPASS toolset. With the SLIM language the system to beanalyzed is modeled. It not only models just the structure or the behavior of a system, but models both.On a high-level it can be compared with Matlab/Simulink. Writing a SLIM file can be done in any texteditor just like most other programming languages. The Atom editor was selected for this thesis to beused as the editor of choose, see Subsection 2.3.1 for more detail.

The main purpose of the SLIM code for this thesis was the create a model that can be analyzed bythe COMPASS toolset. One of future research topics might be the use of the SLIM code as base forthe input model for TASTE. TASTE uses AADL models, from which SLIM is derived, as input models.Using SLIM models to (automatically) generate AADL models might be an option to bridge the gapbetween COMPASS and TASTE, as identified and presented during ESA’s MBSSE workshop [19].

SLIM is derived from AADL and its error annex. Similar to AADL, the SLIM languages is basedaround components which describe parts of the system or systems itself. Components can have sub-components and connections between these subcomponents. SLIM also allows the user to define errormodels. Both component and error models have two separate definitions. The first definition definesthe interfaces of the model, how they are seen by the outside. This is called the type of the model.The second definition defines the implementation of the model and is called the implementation of themodel. The implementation implements the type of the model. It uses the interfaces defined by thetype and defines the internal structure and behavior of the model. Subcomponents and the connectionsbetween them are defined in the implementation of the model. It is possible to have multiple imple-mentations of a model, each implementation implements the same type but defines a different internalstructure and/or behavior.

SLIM has been designed with four essential features [23]. These features are as follows:

1. The ability to model both the nominal and non-nominal (error) behavior of the system. This featureis extensively used with the COMPASS toolset. Sections 2.2.2 and 2.2.3 go into detail on how tomodel the nominal and error models.

2. The ability to model observability and the associated requirements. This feature is used with FaultDetection, Isolation and Recovery (FDIR).

3. The ability to specify timed and hybrid behavior. This is used to analyze continuous systems.SLIM support these continuous change of variables depending on time.

4. The ability to model probabilities of faults and repairs.

2.2. COMPASS Tool 15

2.2.2. System ModelingThe system or nominal model is organized into different components. Three groups of components canbe identified: software (Process, Thread, Data), hardware (Processor, Memory, Device, Bus, Network),composite (System, Node, Subject), and abstract components. The type declaration of a componentdetermines the interface of the component, an example type declaration is presented in Listing 2.1.The example gyroscope sensor has three ports, one input port determining whether there is power andtwo output ports, one boolean to determine whether the sensor produces readings and a second onegiving the actual reading value as a real.1 device Gyroscope2 fea tu res3 has_power : i n data po r t bool ;4 reading : out data po r t bool ;5 r o t a t i o n : out data po r t r ea l ;6 end Gyroscope ;

Listing 2.1: SLIM type declaration

The implementation of a component describes the internal structure and behavior of the component.Listing 2.2 shows the implementation of the gyroscope component example. The example is a verybasic implementation describing that a reading is set as long as the sensor has power.1 device implementat ion Accelerometer . Imp2 connect ions3 f low has_power > reading ;4 end Accelerometer . Imp ;

Listing 2.2: SLIM implementation declaration

Subcomponents and ports The implementation of a component can define subcomponents of thatparticular implementation of a component. Listing 2.3 shows the implementation of an Inertial Mea-surement Unit (IMU). It has three gyroscopes and three accelerometers. The type and implementationof the accelerometer is shown as well. The gyroscope model defined in Listings 2.1 and 2.2 is used forthis model as well.1 system IMU2 fea tu res3 has_power : i n data po r t bool ;4 accelX : out data po r t r ea l ;5 accelY : out data po r t r ea l ;6 accelZ : out data po r t r ea l ;7 r o t a t i o nRo l l : out data po r t r ea l ;8 r o t a t i o nP i t c h : out data po r t r ea l ;9 rotat ionYaw : out data po r t r ea l ;10 end IMU ;1112 device implementat ion IMU . Imp13 subcomponents14 accelerometerX : device Accelerometer . Imp ;15 accelerometerY : device Accelerometer . Imp ;16 accelerometerZ : device Accelerometer . Imp ;17 gyroscopeRol l : device Gyroscope . Imp ;18 gyroscopePi tch : device Gyroscope . Imp ;19 gyroscopeYaw : device Gyroscope . Imp ;20 connect ions21 po r t has_power > accelerometerX . has_power ;22 po r t has_power > accelerometerY . has_power ;23 po r t has_power > accelerometerZ . has_power ;24 po r t has_power > gyroscopeRol l . has_power ;25 po r t has_power > gyroscopePi tch . has_power ;26 po r t has_power > gyroscopeYaw . has_power ;27 po r t accelerometerX . accel > accelX ;28 po r t accelerometerY . accel > accelY ;29 po r t accelerometerZ . accel > accelZ ;30 po r t gyroscopeRol l . r o t a t i o n > r o t a t i o nRo l l ;31 po r t gyroscopePi tch . r o t a t i o n > r o t a t i o nP i t c h ;32 po r t gyroscopeYaw . r o t a t i o n > rotat ionYaw ;

16 2. Tools

33 end IMU . Imp ;3435 device Accelerometer36 fea tu res37 has_power : i n data po r t bool ;38 reading : out data po r t bool ;39 accel : out data po r t r ea l ;40 end Accelerometer ;4142 device implementat ion Accelerometer . Imp43 connect ions44 f low has_power > reading ;45 end Accelerometer . Imp ;

Listing 2.3: SLIM subcomponents and ports

The subcomponents are defined in the subcomponents feature of the component. Implementa-tions of the components are referenced here. The ports feature defines how the ports are connectedin the example; code ports of the component are connected with the ports of the subcomponents andvise versa. It is also possible to connect ports from one subcomponent to ports of other components.

Modes and states A component may specify either modes or states. States can only be definedfor atomic components. Atomic components are components that do not have any subcomponents.Modes are defined for non-atomic components, components that do have subcomponents. Modes de-fine configuration changes in subcomponents in the components where transitions specify the behaviorof the atomic component. Listing 2.4 shows an example with modes and states. Two components aredefined, the Sensor component which is an atomic component and the SensorSystem component,which is a non-atomic component. The modes in the SensorSystem component define how the con-nections are in each mode. Only one of the two sensors is connected in each mode, the primary sensorin the primary mode and the backup sensor in the backup mode. This is defined in the connection partof the implementation by the keywords in modes.

1 device Sensor2 fea tu res3 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;4 reading : out data po r t bool De fau l t => ” t r ue ” ; ;5 end Sensor ;67 device implementat ion Sensor . Imp8 s ta tes9 base : i n i t i a l s t a t e ;10 t r a n s i t i o n s11 base [ when has_power then reading := t rue ] > base ;12 base [ when not has_power then reading := f a l s e ] > base ;13 end Sensor . Imp1415 system SensorSystem16 fea tu res17 has_power : i n data po r t bool ;18 reading : out data po r t bool ;19 go_to_backup : i n event po r t ;20 end SensorSystem ;2122 system implementat ion SensorSystem . Imp23 subcomponents24 pr imary_sensor : device Sensor . Imp ;25 backup_sensor : device Sensor . Imp ;26 modes27 pr imary : a c t i v a t i o n mode ;28 backup : mode ;29 connect ions30 po r t has_power > pr imary_sensor . has_power i n modes ( pr imary ) ;31 po r t has_power > backup_sensor . has_power i n modes ( backup ) ;32 po r t pr imary_sensor . reading > reading i n modes ( pr imary ) ;33 po r t backup_sensor . reading > reading i n modes ( backup ) ;34 t r a n s i t i o n s35 pr imary [ go_to_backup ] > backup ;

2.2. COMPASS Tool 17

36 end SensorSystem . Imp

Listing 2.4: SLIM modes, states and transitions

Transitions Transitions define the transition from mode to mode or state to state. Transitions can betriggered by events or by guards. Mode transitions are constructed as follows [5]:

𝑚 − [ 𝑒 ]− > 𝑚

𝑚 and 𝑚 are two different modes and 𝑒 is a trigger, for example an event from an event port. Statetransitions have a slightly different construction [5]:

𝑠 − [ 𝑒 when 𝑔 then 𝑓]− > 𝑠

Here 𝑠 and 𝑠 are two different states, 𝑒 is an event, 𝑔 a guard, and 𝑓 an effect. The event, guard andeffect are all optional.Listing 2.4 shows both mode transitions, in the SensorSystem component, and state transition, in theSensor component.

Timed specifications Timed specifications are possible in SLIM. Listing 2.5 shows a second imple-mentation of the Sensor component defined in Listing 2.4. This sensor is modeled with an internalbattery and can output readings for a limited time without external power. This is modeled using timespecifications. In order to model this, a clock subcomponent was defined, called delay. This clockincreases by one for each time step of the model. The transitions have an extra guard to tell whenthings are executed. In this example, when there is power the sensor resets the delay (this is importantso that the clock is not run boundlessly) and sets the reading output port to true and transitions to theworking state. This is done with the beginning state as working or not_working. The sensor doesnot directly stop with readings when there is no external power. This can be seen in the second tran-sition. The guard in this transition works when the clock has a value of three or higher and only thenis the reading stopped. This means that the sensor has readings for three time steps after the externalpower has been lost.1 system implementat ion Sensor . Imp22 subcomponents3 delay : data c lock ;4 s ta tes5 working : i n i t i a l s t a t e wh i le ( delay <= 3) ;6 not_working : s t a t e wh i le ( delay <= 1) ;7 t r a n s i t i o n s8 working [ when delay >= 1 and has_power then delay := 0 ; reading := t rue

] > working ;9 working [ when delay >= 3 and not has_power then delay := 0 ; reading :=

f a l s e ] > not_working ;10 not_working [ when delay >=1 and has_power then delay :=0 ; reading := t rue

] > working ;11 not_working [ when dealy >= 1 and not has_power then delay := 0 ; reading :=

f a l s e ] > not_working ;12 end Sensor . Imp2

Listing 2.5: SLIM timed specifications

2.2.3. Modeling ErrorsError models have a type declaration and an implementation similar to components. Listing 2.6 showsan error model for a permanent failure, the code is from the COMPASS tutorial [22]. The type dec-laration defines the states the error model has. The implementation defines events and transitions.The event triggers the transition from one state to the other. Events can be called manually or have arandom probability of occurrence, this is indicated by the occurrence poisson keywords.1 e r r o r model PermanentFai lure2 fea tu res3 ok : a c t i v a t i o n s ta te ;

18 2. Tools

4 dead : e r r o r s t a t e ;5 end PermanentFai lure ;67 e r r o r model implementat ion PermanentFai lure . Imp8 events9 f a u l t : e r r o r event occurrence poisson 0 .01 ;10 t r a n s i t i o n s11 ok [ f a u l t ] > dead ;12 end PermanentFai lure . Imp ;

Listing 2.6: SLIM error model

The error model only defines the error and not any effects on the system it is connected to. This isdone by fault injection and is described in Section 2.2.4.

2.2.4. Fault InjectionOnce an error model has been defined, it can be connected to system components. Connecting theerror model to a component and describing what the effects of an error state are on this componentis called fault injection. Fault injection can be created in two ways. It can be done directly in theSLIM source code or it can be created using the COMPASS toolset, which creates the injection codeautomatically.

Fault injection using SLIM code Listing 2.7 shows a fault injection example, taken from the COM-PASS tutorial [22]. Two properties need to be added to the component implementation, one to connectan error model (line 3) to the component and one to describe the effects of this error model (line 4).The FaultEffects option holds a list of effects. Each effect has three properties to it. The Stateproperty defines the state of the error model when the effect takes place. The Target property refer-ences to a feature of the component that changes due to the error. Lastly the Effect property definesthe effect or the new value of the feature.

1 system implementat ion Generator . Imp2 p rope r t i e s3 ErrorModel => c l a s s i f i e r ( PermanentFai lure . Imp ) ;4 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( has_power ) ; E f f e c t =>” f a l s e

” ; ] ) ;5 end Generator . Imp ;

Listing 2.7: SLIM fault injection

Fault injection using the COMPASS toolset The second option is to use the COMPASS GraphicalUser Interface (GUI) to add fault injections. This is done on the first screen of the toolset where themodel can be loaded as well. The GUI allows the user to select the component one once to add a faultinjection to it. Once clicked on the component, the error model can be selected and one or multipleeffects can be added. The toolset only allows the user to select the values of the properties of theeffect. This is done via drop down menus.

2.2.5. Creating Analysis PropertiesProperties are used in the COMPASS toolset to perform several analyses. They specify boolean ex-pressions that can be checked. Elements in these expressions can be ports, modes, and more SLIMelements from the model. Properties can be created using the COMPASS toolset or by writing themdirectly in the SLIM code. Properties are saved in the SLIM models, thus a new model needs to besaved once properties have been added via the COMPASS GUI. For backwards comparability it ispossible to load and attach a properties file to a SLIM model using the GUI.

Three kinds of properties can be created. These are generic properties, pattern properties, andCatalogue of System and Software Properties (CSSP) properties.

Generic properties Generic properties directly represent a SLIM expression. This can be used forexample in a fault tree to detect possible actions or fault before this generic property becomes true.

2.2. COMPASS Tool 19

Pattern properties Pattern properties are more complex than generic properties. A pattern propertyhas a specific pattern class associated with it, this determines how the property is structured. Exam-ples of pattern classes are: Absence the property will never hold true, Response two properties aredefined where the second must always follow the first one for the pattern property to become true. TheCOMPASS GUI is especially useful for creating pattern properties because it allows the user to selecta pattern class and then presents fields to fill in the expression(s), which guide the user in creating theproperty.

2.2.6. Analysis OptionsThe COMPASS toolset has a GUI. All analysis can be accessed, run, and viewed using this GUI. Beforean analysis can be run, the model needs to be loaded in the tool, this is done on the landing page ofthe application. This screen shows the components in the model as well as any error models injectedin the components of the model. Furthermore, properties need to be created or loaded before someanalysis work. Section 2.2.5 describes these properties. Once this is done, analysis can be performedon the model. The following kind of analysis are available:

• Model Simulation

• Model Checking

• Deadlock checking

• Fault Tree Analysis

• Failure Mode and Effects Analysis Another

• Times Failure Propagation Graphs

• Fault Detection, Isolation and Recovery (FDIR)

An explanation of each kind of analysis is presented below. It briefly describes what the analysisdoes and how it can be accessed in the COMPASS tool.

Model simulation Simulating the model allows the user to check whether the model behaves asintended. This is done in the Correctness -> Model Simulation tab. Three possible simulationscan be run here. Random, guided by transition, and guided by values simulations.

Model checking The model can be checked using properties. This allows simulations to be run anddetermine whether properties are true or not. Model checking can be performed in the Correctness-> Model Checking tab of the toolset. If the property is found to be not true over the simulation, acounter example is shown when the property is not true.

Deadlock checking Deadlock checking allows the user to check if any deadlocks are present in theSLIM model. This can be done in the Correctness -> Deadlock Checking tab. The simulationthen tells whether the model has any deadlocks.

Fault Tree Analysis Fault tree analysis, a top-down safety assessment technique is supported byCOMPASS. The fault tree analysis can be run in the Safety -> Fault Tree Generation tab.Multiple engines can be used. It is possible to fill in the computed probabilities of the faults associatedwith the model. This gives a probability that the property of the fault is correct. Calculating the faultprobability using the error probabilities defined in themodel is possible after the static fault tree has beengenerated. This can be done by going to the Safety -> (Dynamic) Fault Tree Evaluation tab.The severity and simulation end time needs to be filled in. This simulation uses the error probabilitiesdefined in the error models. Fault trees can also be verified, this is done in the Safety -> (Dynamic)Fault Tree Verification tab.

20 2. Tools

Failure Mode and Effects Analysis Another The bottom-up safety analysis Failure Mode and Ef-fects Analysis Another (FMEA) are also supported as well in the COMPASS toolset. Possible failuresand combination of failures for a selected property can be shown by using this technique. It is acces-sible in the Safety -> Failure Mode Effect Analysis tab of the tool.

Times Failure Propagation Graphs Failure propagation throughout the model can be visualizedusing Times Failure Propagation Graphs (TFPG). The first step is to create a TFPG file that modelthe failure modes, discrepancies, and modes. This file can be loaded in the toolset in the TFPG tab.Once loaded it shows a graphical representation of the TFPG file. The second step is to associate theTFPG elements to the SLIM elements of the model. This is done in the Slim Associations subtab. SLIM expressions need to be assigned to each TFPG element. The associations can be checkedin the Behavioral Validation sub tab. A TFPG can also be created from a SLIM model and anassociation file. This can be done in the Synthesis sub tab.

Fault Detection, Isolation and Recovery In order for the FDIR analysis to work the SLIM modelneeds to be provided with observables and one or more controllers, also defined as FDIR components.Observables are signals, in SLIM these are data ports visible for the FDIR analysis. The controlleris a component that runs parallel to the system and uses the observables to observe and/or changethe configuration of the system. It is tagged as an FDIR component. An FDIR component can havealarms. Alarms are put on outgoing boolean data ports. These ports indicate when an anomaly isdetected. These alarms can be picked up by other FDIR components in order to reconfigure the systemto react to faults. Once again, the updated model can be checked to see whether properties hold. Newproperties that represent configuration changes or introduced alarms can be added to the propertieslist that can be checked on the model. With the FDIR properties fault detection, fault isolation, andfault recovery analysis can be performed. All three can be executed from the FDIR tab. For this, faultrecovery is checked by writing special properties, which can themselves be checked by the program.Diagnosability analysis can be performed as well in the FDIR tab. This can be used to determine whichcomponents need sensors to detect a specific fault.

2.3. Other ToolsThe SysML editor and the COMPASS toolset are the main two tools, where the work starts with theSysML editor and needs to end at the COMPASS toolset. However, these two tools are not the onlyones. This section describes other tools used in the entire methodology process.

2.3.1. Atom EditorThe SLIM language can be programmed in any text editor. The most basic editors can be used, how-ever syntax highlighting for coding languages is not supported by these basic editors. Syntax high-lighting makes coding in any language much easier by highlighting different keywords in the language,which improves the readability and reduces errors while coding. Unfortunately, SLIM does not recom-mend a specific editor which includes these highlighting capabilities for SLIM because no highlightingplugin/ extension yes exists for SLIM yet. In order to allow for such easy-to-make highlighting plugin,the Atom editor was chosen as the editor for SLIM files. Atom editor is an open-source text editor spe-cialized for coding purposes. It is available for the most used operating systems (Windows, Linux andMac). This was desirable because Windows as well as Ubuntu (Linux) were used during the thesis dueto different tools only being available on the specific operating systems. Having the ability to read onboth operating systems, the SLIM code was a great advantage. Besides this, the Atom editor allowscustom packages to be installed. These packages add functionalities to the editor. A package for SLIMcode highlighting is being developed parallel to this thesis work.

SLIM highlighting package Asmentioned before highlighting code improves the readability andmin-imizes coding errors. The highlighting package for the Atom editor is coded using regular expressions,regex. Figure 2.4 shows some rules of the highlighting file.

Using this highlight package color-codes different key words and structures in the SLIM code. Figure2.5 shows the difference between highlighted code and code displayed in plain text (without highlight-ing).

2.3. Other Tools 21

Figure 2.4: Example regex expressions for SLIM highlighting rules in Atom editor

2.3.2. IntelliJ IDEAIntelliJ IDEA is a Java Integrated Development Environment (IDE) developed by JetBrains. IntelliJ wasused for developing the transformation tool. The tool was written in Java. Previous positive experiencewith IntelliJ was the reason to choose IntelliJ as editor for the creation of the tool. JetBrains offers afree student license for IntelliJ. Therefore the use of the editor came without costs.

Figure 2.6 shows the window of the IntelliJ editor. The opened project seen in the figure is the SSTMtransformation tool. Not only useful color-coding is supported by InteliJ but it also provides easy codenavigation, code refactoring, code suggestions. All these support features speed up the developmentprocess drastically.

22 2. Tools

Figure 2.5: Difference between SLIM highlighted code (left) and plain text (right)

2.3. Other Tools 23

Figure2.6:

IntelliJ

IDEA

editorw

indow

3The SysML to SLIM Transformation

MethodologyThe SysML to SLIM Transformation Methodology (SSTM) which transforms SysML models into theSLIM models used in the COMPASS toolset is discussed in this chapter. The methodology is notonly a method on how to work, following specific modeling steps, but it also explains the tools used tosuccessfully transform one model into the other.

This chapter is divided into seven sections. The first section gives a general overview of the method-ology. This includes the creation of the SysMLmodel using theOOSEMmethod as well as the analyticalprocesses performed using COMPASS. Section 3.2 briefly describes the OOSEM method; part of theSSTM is based on the OOSEM method. Section 3.3 to Section 3.6, describes the steps necessary totransform the SysML model into a SLIM model used by COMPASS. Three steps are identified in thisprocess:

1. SysML-specific modeling steps. Including modifications of the OOSEM method.

2. Extracting the SysML data in such a way that it can be easily used for model transformation.

3. Creating SLIM models, component and error models from the extracted SysML data.

The last section, Section 3.7, summarizes the limitations found while developing the methodologyas it currently stands.

3.1. High-Level Methodology OverviewThis section gives a high-level overview of the methodology to be created. Figure 3.1 shows a flowchartof the methodology. The methodology can be divided into three main parts.

1. OOSEM / SysML part

2. Transformation part

3. COMPASS part

The first part, the OOSEM part, creates the SysML model using the OOSEMmethod. Modificationsto this method are introduced which results in extra information in the SysML model that is used in thesecond part. The second part, the transformation, extracts the SysML data and transforms it into aSLIM model. The transformation is performed by the transformation tool. This SLIM model is used inthe last part, the COMPASS part, as nominal and error model input models for the COMPASS toolset.

Figure 3.1 shows all the major processes performed, external data and documents created in thedifferent parts. Processes are indicated as rectangles. External data is a rectangle with a concave arcon one side and a convex arc on the other side. Documents are shown as outlined rectangles with asinusoidal bottom edge.

25

26 3. The SysML to SLIM Transformation Methodology

Figure 3.1 shows the three parts of the methodology. The first part, the OOSEM part, is mostlydefined by the OOSEM method. In the first step, set up model, the SSTM profile is added to theSysML project. The next steps, step 2,3, and 4, are defined by the OOSEM method. SSTM does notchange these steps. The actual modeling steps of SSTM start in process 5, Synthesize candi-date physical architecture, here the OOSEM method is modified and modeling using SSTMelements start. The physical SysML model is created in this step.

After the creation of the SysML model the model is loaded in the SSTM transformation tool. Thedata from the SysML is extracted in the tool, this is step 6, Extract SysML model data, in Figure3.1. The extracted data can then be mapped to SLIM elements, indicated by the seventh process inthe high level overview figure. Three elements are created in this process:

1. SLIM nominal components

2. SLIM error components

3. SLIM properties

Step 8, Combine components and properties, combines the three elements into one SLIMmodel.

The SLIM model is then imported into the COMPASS toolset. Analyzes can be then be performedusing the COMPASS toolset. The results of the analyzes are used iteratively to update the createdSysML model in step 5, this is indicated by the dashed line in Figure 3.1.

The next sections elaborate on the first two parts. These parts have newly created processes oraltered processes. The last part about the use of the COMPASS toolset has not been changed in themethodology. An overview of this tool and the analyzing options are given in Section 2.2. Results fromthe COMPASS toolset are however presented in the two case study chapters, Chapter 4 and 5.

3.2. OOSEM OverviewThis section gives a brief overview of the OOSEM method. Only the basic steps as described in “Apractical guide to SysML: The systems modeling language” chapter 17 [14] are presented. A more de-tailed overview of this method can be found in Appendix C. Multiple SysMLmethods andmethodologieswere considered for the use of the first part. These methods and methodologies were:

• International Business Machines Corporation (IBM) Telelogic Harmony-SE

• International Council on Systems Engineering (INCOSE) Object-Oriented Systems EngineeringMethod (OOSEM)

• IBM Rational Unified Process for Systems Engineering (RUP SE) for Model-Driven Systems De-velopment (MDSM)

• Vitech Model-Based Systems Engineering (MBSE) Methodology

• Jet Propulsion Laboratory (JPL) State Analysis (SA)

• Dori Object-Process Methodology (OPM)

OOSEM was chosen because firstly it is tool-independent, making it a method instead of a methodol-ogy, and secondly because of the availability of documentation on the method. More information onthe other considered methods is presented in Appendix C.

OOSEM uses the traditional “Vee”, or V-model, life cycle process, which uses six processes in thismethod.

1. Analyze stakeholder needs

2. Define system requirements

3. Define logical architecture

3.2. OOSEM Overview 27

Figure 3.1: High-level overview of the methodology to connect SysML and SLIM models

28 3. The SysML to SLIM Transformation Methodology

4. Synthesize candidate allocated architectures

5. Optimize and evaluate alternatives

6. Validate and verify system [12]

In practice an extra process is performed before these six, which sets up the model. In order to focusthe work of the thesis, far more time was spent in the downhill processes of the “Vee” diagram. Only thefirst four processes of the OOSEMmethod were investigated in full detail, as well as the setup process.These processes are elaborated in the following subsections.

3.2.1. Model SetupThe model setup is the first process in the OOSEM method. First a high level package structure iscreated with the following five top level packages:

1. Process Guidance

2. Model Domain as-is

3. Model Domain to-be

4. Value Types

5. Viewpoints

Most model elements and diagrams are stored in the Model domain to-be package which in turnhas multiple subpackages for the requirements elements, behavior elements and more. During eachprocess, more detail is added to the model which can be seen in the package structure by an extrapackage of the more detailed system which in its turn houses the requirements and behavior packages.

Besides the package structure, some elements are modeled that are used throughout the method.Domain-specific value types are modeled and stored in the Value Types top level package. Lastlycustom stereotypes are created and connected to or stored in the project. These stereotypes aremethod and domain-specific and extend the default set of stereotypes of SysML.

3.2.2. Analyze Stakeholder NeedsThe domain-as-is is modeled in this process, mainly focusing on improvements to be made to it thatthe system-to-be will solve. This leads to mission requirements of the system-to-be. If a new systemis being developed, this process starts by creating mission requirements. Following the requirementsis the modeling of the model domain-to-be structure with all the interacting parties, the system itselfis given the «system of interest» custom stereotype, which is used and elaborated throughout thefollowing processes. Finally, using the domain-to-be structure, enterprise use cases can be created.

3.2.3. Define System RequirementsUsing the enterprise use cases lower level requirements and activity diagrams can be created refiningthe mission requirements and the use cases as well as creating functionalities to the system to satisfythe use cases. The start of signal and flow definitions, used throughout the system, are created at thispoint.

3.2.4. Define Logical ArchitectureUsing the requirements and functionalities defined in the previous process it is possible to define thelogical architecture. It treats the system as a whole and defines logical components that, connectedtogether, perform the required functionalities. BDD is used to show the logical composition of thesystem. IBD shows the internal connections of these logical components. Activity diagrams are finallycreated to show the behavior of the logical system. Important to note is that interfaces of the overallcomponents are the same as in the structure and behavior diagrams from the previous processes.

3.2.5. Synthesize Candidate-Allocated ArchitecturesThe last process discussed is the synthesis of the candidate-allocated architectures process. The finaloutcome of this process is a physical composition of the system with specifications for the physicalcomponents. However, some intermediate steps are performed before this final outcome.

3.3. SSTM Modeling Steps 29

Define nodes The first step is to define nodes, or partition the system in independent sections. Tra-ditionally in the OOSEM method this partitioning is done by the physical location of components in thesystem. The OOSEM method creates one node for the space segment and one node for the groundsegment. The SSTM methodology modifies the node definition to tailer it to space engineering. Thismodification is described in Subsection 3.3.2.

Define “node logical” architecture The next part is to define the “node logical” architecture. Thisallocates the functional components from the logical architecture to the node that provide this function-ality. Structure diagrams (BDD and IBD) and behavior diagrams (Activity diagrams) for each node arecreated.

Define “node physical” architecture The next step is to define the “node physical” architecture.This is done by allocating logical functions from the previous steps to physical components and nodes.Trade-offs to determine the best physical component to execute the logical task are performed at thisstep. The result is a physical model with the corresponding structure and behavior diagrams. Multiplephysical components can be identified each having its own stereotype. The possible stereotypes are:hardware, software, procedure, and operator.

Create physical component specifications The last part is to generate overviews of componentspecifications. Each component has its own component black box specification, containing ports, op-erations, parts, and more from that component.

3.3. SSTM Modeling StepsThe first step in SSTM is to model the system using SysML in the Papyrus tool. OOSEM is used as abaseline method to start modeling the system from scratch. Additional stereotypes on top of the defaultSysML and OOSEM method set of stereotypes are introduced and need to be used throughout themodeling of the SysMLmodel. Subsection 3.3.1 describes the added stereotypes. The stereotypes arean addition to the OOSEM method. However, some changes to the OOSEM method were introduced.

The rest of this section elaborates on the diagram-specific rules and steps that needed to be followedin order to have a correct model which could be transformed. Figure 3.2 shows the work flow of themodeling steps in SSTM. The first step was to create nodes for each subsystem. Thismodification of theOOSEMmethod is described in Subsection 3.3.2. Once the subsystem nodes had been created, it waspossible to create the components of each subsystem (node). These nominal models were modeledusing a set of modeling elements. The modeling of a nominal component is described in Subsection3.3.3 to Subsection 3.3.13. An unlimited amount of nominal components could be created for a node.Error components were created using slightly different steps. This is discussed in Subsection 3.3.14.Error injections can be modeled in the nominal model once the error components had been created.This is described in Subsection 3.3.15. The fifth and last step in modeling the system was to createpattern properties. Pattern properties are used by the COMPASS toolset to perform analysis. Thecreation of pattern properties is described in Subsection 3.3.16.

This section describes the modeling steps needed to be performed on a high-level. How to modelan actual system which consequently verifies the methodology, is described in Chapter 4. This chapterdescribes the practical modeling steps of the SSTM methodology in more detail.

3.3.1. Custom StereotypesOOSEM introduces a set of custom stereotypes. A few of these were used to identify systems in themodel, such as the «system of interest» and «node physical» stereotype, Subsection 3.3.2 discussesthe use of the latter one in more detail. SSTM defines a set of custom stereotypes extending theOOSEM method. Figure 3.3 displays the stereotypes and the relation with other stereotypes and mod-eling elements. These stereotypes were implemented as a customized profile to refine the mappingprocess. Table 3.1 lists the custom stereotypes together with a short description of the use of each.

The SSTM stereotype profile consist of the SSTM stereotypes but it also includes all the OOSEMstereotypes as described in [14]. The OOSEM stereotypes are included because SSTM extends fromthe OOSEM method. Therefore the stereotypes from OOSEM are added, the SysML modeler onlyneeds to include the SSTM profile to have access to all the necessary stereotypes.

30 3. The SysML to SLIM Transformation Methodology

Figure 3.2: SSTM modeling work flow diagram.

Several colors of elements of the profile stand for different groups of elements. The orange ele-ments are imported elements from UML and SysML extended or generalized. Yellow elements areenumerations used for typing properties of custom stereotypes. The blue elements are stereotypesused to type nominal modeling elements. Red elements are stereotypes for error components anderror injection. Lastly, green elements are property elements, used to type properties used in theCOMPASS toolset for analysis. More information on the difference per property can be found in theSLIM semantics document [5].

The base elements of the profile, which are colored orange, are the «Block» stereotype and theProperty, Port, and State metaclass. These elements are UML and SysML elements. Extendingand generalizing these elements allow the SSTM profile to be used on SysML models.

The «Signal» stereotype is not directly mapped from a SLIM component. It is used to typify signalblocks. These signal blocks are used to typify flow ports that handle events.

Not all SLIM components are represented in the stereotype set. The reason behind this is thatnot all SLIM components are supported by the SSTM methodology. Subsection 3.6.1 discusses thisselection of supported components.

3.3.2. Subsystem Node DefinitionTraditionally, in OOSEM, nodes are defined as the grouping of elements in a single physical location.SSTM alters this definition and the use of nodes slightly to better conform to the separation of spacesystems. In SSTM nodes, and consequently the logical and physical variant of nodes, represent sub-systems of satellite design. If the traditional definition would have been used, one satellite would havebeen a single node. Satellite design already categorizes different subsystems which are being devel-oped concurrently. Defining nodes at this level of categorization is compliant with traditional satellitedesign and allows for slightly less complex nodes.

3.3.3. Creating Nominal ModelsNominal models, models that are not errors, are modeled using blocks. These blocks need to betyped with one of the supported SLIM component stereotypes. These stereotypes are described inSubsection 3.3.1. The structure and behavior of these blocks / components is modeled using severalprinciples, all described in the following subsections.

FDIR component A nominal element can be typified by the «FdirComponent» stereotype. Thismakes the transformed model of this element a FDIR component, allowing FDIR analysis to be per-

3.3. SSTM Modeling Steps 31

Table 3.1: SSTM custom stereotypes

Stereotype Parent Description«Signal» «Block» Stereotype to type signal block, which are

used in typing event ports«SlimComponent» «Block» Base stereotypes for all SLIM component

stereotypes«SlimSubcomponent» «SlimComponent» Base stereotypes for subcomponents that do

not follow standard component specifications«Data» «SlimComponent» Stereotype for SLIM Data component«Thread» «SlimComponent» Stereotype for SLIM Thread component«Bus» «SlimComponent» Stereotype for SLIM Bus component«Device» «SlimComponent» Stereotype for SLIM Device component«Memory» «SlimComponent» Stereotype for SLIM Memory component«Processor» «SlimComponent» Stereotype for SLIM Processor component«System» «SlimComponent» Stereotype for SLIM System component«Clock» «SlimSubcomponent» Stereotype for SLIM clocks«ErrorState» «Metaclass» State Stereotype for error states«SstmState» «Metaclass» State Stereotype for states with extra conditional in-

formation«ErrorModel» «Block» Stereotype for SLIM error models«ErrorEvent» «Metaclass» Port Stereotype for error event ports«ErrorEffect» «Metaclass» Property Stereotype for properties that contains the er-

ror effect information«FdirComponent» «SlimComponent» Stereotype to type FDIR components«Observable» «Metaclass» Port Stereotype to type a port as an observable for

FDIR analysis«Alarm» «Metaclass» Port Stereotype to type a port as an alarm for FDIR

analysis«PatternProperty» «Metaclass» Property Base stereotype for pattern properties«UniversalityPattern» «PatternProperty» Universality pattern property stereotype«AbsencePattern» «PatternProperty» Absence pattern property stereotype«ExistencePattern» «PatternProperty» Existence pattern property stereotype«RecurrencePattern» «PatternProperty» Recurrence pattern property stereotype«PrecedencePattern» «PatternProperty» Precedence pattern property stereotype«ResponsePattern» «PatternProperty» Response pattern property stereotype«ResponseInvariancePattern»

«PatternProperty» Response invariance pattern property stereo-type

«UntilPattern» «PatternProperty» Until pattern property stereotype

32 3. The SysML to SLIM Transformation Methodology

Figure 3.3: SSTM profile diagram version 0.0.40

formed on this component.

3.3.4. Defining Subcomponent StructureStructure in the SSTM methodology is ordered per subsystem. Each subsystem is defined as a node.Each subsystem is located in its dedicated packages, this is for the modeler’s convenience, becausethe transformation tool does not depend on packages for the structure of the system.

Components can be modeled as usual with blocks in a BDD. Compositions of components can becreate using part associations. These part associations need to be named in order for the transforma-tion to output the correct SLIM code.

3.3.5. ClocksClocks are SLIM components to track timing events. Clocks are modeled in the SysML model usingblocks with the custom «Clock» stereotype. Using the stereotype settings the time unit can be se-lected, which defaults to seconds. Other expressions such as guards and effects can use clocks. Moreinformation on using guards and effects is presented in Subsection 3.3.12.

3.3.6. PortsOnly flowports are recognized by the transformation tool. Value types, primitives or blocks can be usedto typify the flow flowing through the ports. A port is transformed into a data port in the SLIM model bydefault. If the flowport is typified with a primitive data type then the data port in SLIM is also typified withthis primitive. In all other cases the SLIM port is typified as a Real data port. The SSTM profile definesa «Signal» stereotype. This stereotype is used to typify event ports. A block in the SysML model needsto be typified with the «Signal» stereotype, this block can then be used to typify the flowport. After thisprocess the flowport can be identified as an event port in the SLIM model.

Default values Default values can be set while modeling ports. If a primitive value type is used forthe value type, a literal of that primitive can be used for the default value. If an enumeration is used aliteral instance of that enumeration can be used.

FDIR properties Two FDIR properties, observable and alarm, can be added to a port. This is doneby adding the corresponding stereotype to the port.

3.3. SSTM Modeling Steps 33

Figure 3.4: Flow connected to a port of the component

Figure 3.5: Flow connected to a subcomponent port

3.3.7. Connecting PortsConnecting ports is done in Internal Block Diagrams. Ports are connected using connectors. Thedirection of this connection is not easily visible or changeable in Papyrus. However, it is importantto connect the source port first and the target port second because SLIM explicitly needs to state thedirection of the connection. This is not automatically detected by the transformation tool, as describedin Section 3.7.

3.3.8. FlowsFlows are connections between expressions and a port. An expression can be a simple statementor it can be an expression which uses other port conditions to construct the expression. A commentelement is used to create the expression. Linking the comment element to the target port is donevia a link connection see Figure 3.4. If the flow connects to a port of a subcomponent a link to thesubcomponent instance needs to be made as well, see Figure 3.5.

3.3.9. Subcomponent AccessA bus subcomponent can be shared by other subcomponents. This is modeled by connecting the bussubcomponent instance to the other subcomponent instances that have access to it. Important to noteis that the bus subcomponent should be clicked first to make it the source end of the connection.

3.3.10. State MachinesState machines are the modeling element storing behavior information. States and transitions are mod-eled and stored in the state machine. The SSTM only supports a single state machine per component,this state machine can also only consist of one region. Three elements can be modeled in the regionof a state machine.

• States

• Transitions

• Pseudo states

The following subsections elaborate on these elements.

3.3.11. StatesStates model the states of the element it is connected to. Several configuration layouts, determiningthe behavior of the component, can change for each state. SysML only allows the user to model states,the transformation tool automatically transforms states to modes in the SLIM model if the componentis non-atomic.

34 3. The SysML to SLIM Transformation Methodology

3.3.12. TransitionsTransitions connect states to each other and define the transition from one state, the source state, tothe other state, the target state. States can be named to make them more easily readable for the user.However the name is not needed for the transformation. One exception to this rule is the naming of theinitial transition, which is described in the following subsection. If a name is added to the transition, itis transformed as a comment in the SLIM code, it does not influence the code, but it makes the SLIMcode more readable for humans.

A transition can be started by an event or a guard. Each transition can have an effect on thecomponent. How to model these three added properties to the transition using the SSTM methodologyis described below.

Transition event An in event can trigger the start of the transition. Only event ports, ports typifiedby a «Signal» stereotype block, can trigger a transition in SSTM. Events are connected to a transitionby adding a trigger to the transition. This trigger can then reference to an event port of the component.If an out event port is modeled as a trigger, an out event on that port is triggered once the transitiontakes place.

Transition guard A guard, similar to an event, can start a transition. Where an event is triggeredby an event port, a guard describes an expression. Once this expression holds true the transition isstarted. Guards are modeled using constraints. The constrain needs to have an OpaqueExpres-sion connected to it. The expression needs to be written using SLIM syntax. The Object ConstraintLanguage (OCL) term “self” can be used to reference to the owning object to select ports or otherproperties. This term is removed during the transition. Note that the “self” term only works when thelanguage of the expression is set to OCL.

Transition effect The transition effect dictates an expression that is executed once the transition isstarted. An OpaqueBehavior needs to be added to the transition. The language of this OpaqueBe-havior needs to be the OCL language. The expression that is the actual effect needs to be written inthe body of this behavior, and needs to be a SLIM expression. Similar to the guard the “self” term canbe used in the effect expression.

3.3.13. Pseudo StatesPseudo states are state-like nodes used in SysML to represent a specific point in the behavior of thecomponent. The only supported pseudo state is the initial node. This node is not a state, but indicateswhat the initial state of the component is. It is required to name this initial pseudo state “initial”. Atransition with the source as the initial pseudo state and the target as the initial state needs to benamed “initial” as well to convey this information.

3.3.14. Error ModelBesides the nominal model, which is described in the previous subsections, SSTM allows the modelerto model error models. Error models are modeled as blocks typified with the «ErrorModel» stereotype.Error models have four main modeling features:

• Error events

• Clocks

• Error states

• Transitions

Error events and error states are slightly different compared to the nominal model equivalents. Thedifferences are described below. Clocks and transitions are modeled exactly the same as in nominal.

Error events Error events are modeled as ports with the «ErrorEvent» stereotype. Probability andtime unit options of the error event can be modeled using the properties of the stereotype.

3.3. SSTM Modeling Steps 35

Error states Error states are modeled in a state machine diagram but have an «ErrorState» stereo-type added to them to identify them as error states.

3.3.15. Error InjectionConnecting error models and nominal models is done by error injection. An error injection is modeledby adding a property to the nominal model that has the «ErrorEffect» stereotype added to it. Thisstereotype allows the modeler to model the effect of a specific state of an error model. Four propertiesneed to be set using the property options of the stereotype.

Error Model The error model property refers to the error model that is used for the error injection.This needs to be an error model and cannot be another nominal model.

Error State The error state of the refers error model needs to be selected. The effect takes placeonce the state is the active state in the error model.

Error Target The target element that is changed by the effect needs to be selected using this property.The element needs to be a port of the nominal model the effect is attached to.

Error Effect The effect on the error target is modeled using this property. This needs to be a validSLIM expression.

3.3.16. Pattern PropertiesPattern properties are used for analyzing the SLIM model. It is possible to create these patterns usingthe COMPASS toolset. This gives a GUI for creating these pattern properties. Pattern properties aresaved in the SLIM model and can be used when loaded.

A problem arises when the SysMLmodel changes and should be re-transformed to an updated SLIMmodel. Pattern properties made using the COMPASS tool for a previous version of the system are lostwhen the updated SysML model is transformed. A set of pattern property stereotypes is added to theSSTM profile. This allows the modeler to model these pattern properties in the SysML. The propertiesare correctly transformed and saved using the SSTM transformation tool into the SLIM model. Patterninformation is modeled using these pattern stereotypes. This is done by filling the stereotype optionswith SLIM expressions similar to when modeling the patterns using the COMPASS tool. Adding apattern property to a components is done by creating a new property to the specific component andtyping it with one of the pattern stereotypes.

Eight classes of pattern properties are supported and are listed below:

• Universality Pattern Property

• Absence Pattern Property

• Existence Pattern Property

• Recurrence Pattern Property

• Precedence Pattern Property

• Response Pattern Property

• Response Invariance Pattern Property

• Until Pattern Property

More detailed information on the use of the pattern properties and specifics can be found in theSLIM 3.0 syntax and semantics document [5].

In version 1.0 of the SSTM tool and methodology the only supported scope for pattern properties isthe global scope.

36 3. The SysML to SLIM Transformation Methodology

Figure 3.6: SSTM transformation overview

3.4. Transformation AlgorithmThe transformation algorithm is a complex algorithm that can be divided in multiple sub parts. The firstmain processes that can be identified are already described in Section 3.1 and can be seen in Figure3.1. These processes are the following:

• Extract SysML model data

• SysML to SLIM mapping

• Combine SLIM components and properties

The three processes can all be divided into smaller sub processes. Figure 3.6 shows these subprocesses. The numbering for the parent processes as used in Figure 3.1 is used for this figure aswell.

The Extract SysML model data process is split up in two sub-processes. Firstly the ExtensibleMarkup Language (XML) Metadata Interchange (XMI) file is read and stored in the tool. This is followedby extracting the SysML data from the stored XMI data.

The SysML to SLIM mapping process is split into two sub-processes. The first process, CreateSLIM data objects from SysML data objects, creates the initial SLIM data objects. TheseSLIM data objects are finalized in the second sub-process, Finalize SLIM data objects.

3.4. Transformation Algorithm 37

The last process combines the SLIM data objects. In the first sub-process the error componentsare used to create error injections in the nominal model. This is done with error effects. The lastsub-process adds properties to the nominal components.

Answering research question 1.1.3: How is the minimal transformation performed? This sec-tion and the following two sections, Section 3.5 and Section 3.6, answer research question 1.1.3 Howis the minimal transformation performed?.

3.4.1. Detailed Algorithm DescriptionFigure 3.7 shows the detailed processes and data objects of the SSTM transformation tool. Section3.5 and Section 3.6 describe the individual processes in more detail. This subsection combines theinformation of these two sections and describes from start to finish the algorithm of the tool. Figure 3.7is used as reference to explain all the steps. The sub processes shown in Figure 3.6 are visualized inFigure 3.7 by containers containing the corresponding detailed processes.

The tools algorithm starts on the top left corner of the figure. The first process performed,Read XMLfile , reads the XML file generated by Papyrus. The file is selected via the tool’s GUI. The file is readusing a DocumentBuidler and is pared to a document. This document is saved in the tool, the greenparallelogram named Document represent this document data.

The next process, Get all stereotype instances, extracts all the stereotypes stored in thedocument. This process stores all the individual stereotype instances, represented by the green par-allelogram named Stereotype instances.

Parallel to the stereotype extraction processes another process, Get all models, is performed.This process extracts all the model elements from the document. Multiple models can be saved inone document. However, the transformation tool only supports the transformation of a single tool. TheSelect only first model step selects only the first model of all the extracted models and savesthis as the model to be transformed. This model is represented by the green parallelogram namedModel.

All processes described previously are processes done on the input file. All processes describedfrom this point on use the extracted data and not the input file. A separate controller, ModelCon-troller, is created to perform all these processes. Processes from this model controller are coloredred in the figure.

The first process of the ModelController is to extract and categorize packagedElement. Pack-agedElements are the root elements inside the model. They can represent a range of different ele-ments. The kind of element it represents is determined by the type attribute of the packagedElement.Four types of packagedElements are extracted in the tool, Packages, Classes, DataTypes, andEnumerations. Each type of packaged element is stored in the tool by the corresponding process.Packages store the hierarchical structure of the SysML model. This hierarchy is modeled by the SysMLmodeler. A good defined hierarchy is important while modeling the SysML model. However, the trans-formation tool does not require this structure. The strength of the SysML model is that all elements arereferenced to each other. The packages are stored, but are not used furthermore in the tool. Classesare the most important type of packagedElement and are the base element for most custom elementsintroduced by the SSTMmethodology. All elements generalized from the «Block» stereotype, see Sub-section 3.3.1, are modeled as a class. Each class is stored in the tool inside an array list, representedin the figure by a green cylinder named ModelController: classes. All child elements storedin the class element are extracted and stored separately in the class instance created by the Cre-ate Class process. The elements stored at this point are properties representing subcomponentsand ports, flows, connections, and all behavioral elements modeled in the state machine. The last twopackagedElement types, DataTypes and Enumerations, store custom data. The Datatype instancestores a simple datatype such as a boolean or a integer. The Enumeration instance is a special caseand stores enumerations.

38 3. The SysML to SLIM Transformation Methodology

At this point the stored data object represent UML objects as XMI objects. The Add stereotypesto XMI objects process combines these XMI objects and adds stereotypes to them. The stereo-types added to the elements give them a meaning in the SysML and SSTM context. Signals can nowbe extracted, in the Extract Signals from Classes process, from all the class objects. Theseclasses are used to determine which port in each component is an event port. This is done in the TypeEvent Ports process. Data ports are determined using DataType objects in the Type Data portsprocess. All this extra information is stored in the class object and its child objects. When all theseprocesses are performed a final XMI object of each class is stored in the tool. This finalized objecthas all the necessary transformation information attached to it. These finalized class objects are thestarting point of the transformation.

The process that starts the actual transformation is named Map XMI Objects to SLIM Objectsin the figure. During this process the initial SLIM objects are created. This is done by reading the XMIclass objects and using the attached stereotypes from the SSTM profile the correct SLIM objects canbe created. Three types of components are created and saved separately. The three componentsare Clocks, Nominal Components, and Error Components. The mapping process maps a XMIobject to the correct component and saves it. For the nominal components an extra categorization isdone to create the specific SLIM component. Supported SLIM components are discussed in Subsec-tion 3.6.1. The stored SLIM objects are represented by yellow parallelograms in Figure 3.7.

The SLIM objects can not directly be used after they are created. Three iteration steps are neededto finalize the components. The first iteration process, Create subcomponents, create subcompo-nents in each nominal component. References to a subcomponent are stored in the model since thecorresponding class was created. The process loops over all known components and clocks and createsubcomponent instances. The second iterative process needed is the Finalize: -Transitions,-Connections, -Flows process. Transitions, connections and flows can reference to ports of sub-components. Therefore the subcomponent needs to be saved in the component before these elementscan be finalized. The last iterative process is the Finalize Error Effects process. Error effectsare stored in a nominal component and refers to an error model, one of its states, and to an element ofthe nominal component. This step can only be performed after all the elements of the nominal modelare finalized, which is done in the second iterative process.

After the three iterative processes the SLIM objects are finished and are ready to be exported. Theexportation process is not shown in the figure. The user selects in the GUI the output directory and thename of the file. The tool then writes each nominal and error component to the file using the correctSLIM syntax.

3.5. Extracting SysML DataIn order to map SysML data to SLIM data, it first needs to be extracted from the source SysML modeland saved in such a way that it can be mapped to SLIM components. The extraction and storing of theSysML model is discussed in this section. This section is subdivided into several subsections. First,the source structure is discussed highlighting the most important features of the source code of theSysML model. Subsection 3.5.2 explains the procedure of extracting stereotype information. Next theExtraction og UML information is discussed. The final subsection describes how to combine the UMLand stereotype information to create a SysML model in the SSTM tool. The SSTM transformation toolis written in Java. Java is chosen because it is class-based and object-oriented. This allows the user tocreate a robust tool that can easily be extended. Java programs are not operating-system-dependentand once compiled can run on all operating systems without other tools. This makes the transformationtool accessible to anyone independent of operating system. Figure 3.7 shows an overview of stepstaken by the SSTM transformation tool to create an SLIM model. This section discusses the first part,where UML and SysML data is extracted and stored. These are displayed as green data objects in thefigure. The extraction of SysML data stops after all the classes have been created, before the “MapXMI Objects to SLIM Objects” process. At this point the mapping starts, which is described in the nextsection.

3.5. Extracting SysML Data 39

3.5.1. Structure of SysML Model Source FileThe SysML model is saved in XML files following the XMI standard. The root element is a xmi:XMIelement. The model is saved in the uml:Model element. As the name already implies, the modelis stored as a UML model and not as a SysML model. SysML information is provided by connectingstereotype instances to each UML element defined by a stereotype. All this stereotype information isstored in elements directly in the root element, on the same level as the model element. Due to this splitof UML and stereotype information several steps are needed to extract the SysML information from themodel and store it in such a format that it can be used. The first step is to extract all the stereotypeinstances, this is described in subsection 3.5.2. This step is followed by extracting the UML model andstoring this model information, described in subsection 3.5.3. The last step, described in subsection3.5.4, combines the extracted stereotypes with the UML model. This adds the stereotypes to the UMLobjects and gives them SysML information.

3.5.2. Extract Stereotype InstancesExtracting stereotype information is done parallel to extracting the model information. This is possi-ble due to the fact that the stereotype instances are stored separate from the model. Each stereo-type instance is identified by the tag of the element. Each stereotype has its own tag for example,Blocks:Block is the tag name of a block stereotype from the SysML profile. Custom stereotypesinstances are named following the naming of the stereotype in the custom profile as described in Sub-section 3.3.1 for example, SSTM:SSTM:Device is the device stereotype tag name.

The SSTM tool extracts all the stereotype instances using these tag names and stores them inan array list. Subsection 3.5.4 describes the combination of these stereotype instances with the UMLmodel to create the SysML model in the SSTM tool.

3.5.3. Extracting UML Model InformationThe most important elements in the UML model are packagedElements, these elements are thebasic building blocks of the model. A packagedElement can represent multiple model elements. Thetype attribute of this element determines the element type. The three most important element typesextracted from packagedElements are:

1. Class element, typed by uml:Class

2. Datatype element, typed by uml:DataType

3. Enumeration element, typed by uml:Enumeration

A package element can also be extracted from the model, using the uml:Package tag name.However, the package element is not used in the the SSTM tool. It is used to order other elements,useful for UML and SysML editors, but no vital information for the model.

The datatype element is used to describe value types in SysML. This is used when custom valuetypes, other value types than the primitive types used in programming for example, acceleration orangular velocity. These value types are used further on in the tool to define ports, this is discussedlater in this subsection.

The enumeration element is to define enumerations. These enumerations are stored separatelyand used in other components, such as ports and clocks.

The most important element that is used in the model transformation is the class element. ThisUML element is the parent element of the block element and due to the definition of the custom stereo-type also the parent of all the custom stereotypes used to model SLIM components. The rest of thissubsection describes the process of extracting all the information from the class element. Two ownedattributes can be extracted from a class element using the SSTM tool. These are properties and ports.Property extraction is described in the following paragraph whereas ports are described in the next one.

Properties Properties can be a numerous of properties linked to the class element. An owned at-tribute typedwith uml:Property is a property of the class. For the transformation to SLIM componentstwo property kinds are stored in the properties of the class. The first kind is a reference to subcom-ponents and clocks. The second type is the error effect properties. These properties later connecterror effect instances to components. When a class is created only a shallow reference to the property

40 3. The SysML to SLIM Transformation Methodology

is saved in the class model. During the SysML to SLIM mapping a stronger reference to the actualsubcomponents, clocks, and error effects is created using these properties stored in the class model.

Ports Ports are the second owned attribute of a class and are typed with uml:Port. Ports are typedwith a value type that describes the kind of data that flows through the port. This is not always thecase for UML or even SysML ports. However, the SSTM methodology only allows ports of nominalcomponents to be flow ports and this constraint limits the multiple kinds of ports to one. Value typescan be of a UML primitive type, such as a boolean or an integer. Value types can also be a customvalue type defined by the user. In the former case, the type is defined in the port element. In thelater case a reference to the custom value type is stored in the port definition. The SSTM methodologyassumes that all custom value types except enumerations store their information in a primitive real dataobject. Error components use ports as error event ports. These ports are not flowports but are typifiedby the «ErrorEvent» stereotype. Error events are used similar as event ports in nominal components.

Connections Connections are created between ports of the class and possible subcomponents. Themetadata of these connections are stored in the class model and are used in the mapping phase tocreate the actual connections between ports of the component and its subcomponents. Connectionsare also used to store information about subcomponent access. These are treated similar to portconnections in the class model but are mapped differently in the SLIM model.

Flows Flows are expressions connected to ports. They describe the information of the port as de-scribed in the expression. Only metadata of the flow are stored in the class, which are later used tocreated the actual flow model in the SLIM model.

State machines Properties, ports, connections, and flows define the structure, external and internal,of the class. State machines describe the behavior of a class. Regions inside the state machine housestates and transitions that determine that actual behavior of the class. The SSTM tool is currently limitedto one state machine per class and one region per state machine. This does not limit the numberof states or transitions but only limit the readability of the UML state machine diagram. However,limiting the number of state machines and regions per class drastically simplifies the transformation,this simplification outweighs the slightly less readable diagrams.

States States are extracted from the state machine’s region. No other logic than saving the statesin the class model is used. The behavioral logic is introduced by the transitions. One special case ofa state is the initial state which is a pseudo state. This indicates the start of the state machine. Thispseudo state is saved separately and used later on with the transitions to determine the initial state ofthe class. The SSTM tool requires the modeler to name this initial pseudo state initial.

Transitions Transitions model the behavior of state changes. Each transition can be initiated by anevent from an event port, a guard or a combination of the two. It can also force an effect on the class.Detail on extracting the event trigger, guard and effect is described bellow.

A special transition is the transition from the initial pseudo state to one state. This transition is notstored but is only used to typify the target state of this transition as the initial state of the class. This isneeded because SLIM does not use pseudo initial states as UML does.

3.5.4. Combine UML Model and Stereotype InstancesOnce all the stereotypes are extracted from the model and the UML components are extracted andstored, it is possible to combine the two. Combining both kinds of data to form a SysML model is bylinking the stereotype instances to the UML elements using their IDs. Each XMI element has an uniqueID that is used by other elements to reference to each other.

The kind of stereotype connected to the element conveys the most important information for thetransformation used in the mapping phase to map the element to the right SLIM element. However,some stereotypes, such as the <ErrorEvent» stereotype, have extra properties adding vital metadatato the element. This metadata as well is used in the mapping phase.

3.6. SysML to SLIM Mapping 41

After combing the stereotypes and UML elements it is possible to transform the combined model,which represents a SysML model, to a SLIM model. This mapping is described in Section 3.6.

3.6. SysML to SLIM MappingThe mapping of the SysML model to a SLIM model phase is done in several steps. The last part in Fig-ure 3.7 describes the mapping on a high level. Yellow data elements represent SLIM elements in thisfigure. The first step of this phase is to map SysML elements to SLIM components. Not all SLIM com-ponents are supported. Subsection 3.6.1 elaborates on the SLIM components that are supported. Thisfirst step in the mapping phase creates the structure of the SLIM components. The second step is touse the structure of all the components and create subcomponents and clocks in the SLIM components.The third step is to finalize the internal structure and behavior of the SLIM components. Transitions,connections, and flows are finalized using the subcomponents created in the second step. The fourthand last step creates the error injections. The error injections create error effects in the nominal modelusing and referencing to a specific error model. The four steps are described in Subsection 3.6.2 tillSubsection 3.6.6.

3.6.1. SLIM Components SelectionSLIM has a total of 12 component types [5]. In order to limit the amount of work, resulting in a betterquality of the remaining work, a subset of these component types is supported by the mapping. Table3.2 shows the possible component types which are supported by first version of the SSTMmethodology.

The supported components were selected to satisfy the minimum requirements set for the SSTMmethodology. Improvement iterations will add full support for all components. The improvements aredescribed in Chapter 6.

Table 3.2: Supported SLIM components

Component type SupportedSoftware Components

Data NoProcess NoThread Yes

Hardware ComponentsBus YesDevice YesMemory YesNetwork NoProcessor Yes

Composite ComponentsNode NoSubject NoSystem Yes

UncategorizedAbstract No*

Data component The data component can be an import component in the future of the transformationtool. Currently, in version 1.0, the data component is not supported. This was chosen to limit the scopetomake sure a basic functional tool could be created in the allocated time. Including the data componentdirectly in version 1.0 would take a lot of development time of the tool, because data components havedifferent limitations then other SLIM components. These limitations need to be added to the tool inorder for it to work.

Process component The process component is not supported by the transformation methodology.To simplify the methodology at this moment it is chosen to support only the process or thread compo-

42 3. The SysML to SLIM Transformation Methodology

nent type. Because a process is a superset of multiple threads it is chosen to support threads overprocesses.

Thread component As mentioned above the thread component is supported over the process com-ponent. The task of the system can be modeled in the thread component.

Bus component The bus component is supported as well due to the abundance use in the satellitedesign of buses.

Device component The device component is supported because it is the only general hardwarecomponent that has no specific use. A space system is more than hardware on which software com-ponents run, which AADL and therefore SLIM is designed for. The device component is used to modelother hardware elements of the system.

Memory component In order to store information, which is used in most spacecrafts, the memorycomponent is used and is therefore supported.

Network component The network component is not supported. Mainly to simplify the model and itstransformation at this point. This limits the modeling of networks.

Processor component The processor is supported, it is the hardware component which threads canrun on.

Node and Subject component Both these composite components are not supported due to the lackof documentation on the use of these components.

System component This is the only composite component that is supported. It models systems thathave both hardware and software components.

Abstract component This component is not supported by the SSTM methodology.

3.6.2. Mapping Nominal Component StructureThe first step in mapping the SysML model to the SLIM model is to create SLIM components fromclasses typified by a «SLIMComponent» stereotype. The supported stereotypes for these componentsare discussed in Subsection 3.6.1. One extra component is also treated as a SLIM component. Thiscomponent is mapped in this step as well but the basic metadata from the class element can be usedto initiate the SLIM component. The information that is directly created in this step is the following:

• Name and property information of the component.

• Initiation and finalization data and event ports for the component.

• Initiation of flows for the component.

• Initiation of connections for the component.

• Initiation and finalization states for the component.

• Initiation of transitions for the component.

• Initiation of error effects for the component.

Name and properties The name of the component is the identifier of the component and is directlyextracted from the corresponding class. Properties are also saved during the initiation of the com-ponent. In the current version of the tool the property is only saved when the component is a FDIRcomponent. Pattern properties are mapped to the properties of the component. The function of thesepattern properties is described in Subsection 3.3.16.

3.6. SysML to SLIM Mapping 43

Data and event ports Ports from the corresponding class are extracted and evaluated if they are adata or an event port. The corresponding SLIM port is created and stored in the component model. Noextra processing is needed for these ports.

Flows Flows are initiated and stored in the component model. Metadata of the flow are stored usedlater on, while finalizing all flows.

Connections Connections are also initiated and their metadata are stored in each connection object.Connections do also need to be finalized later in the process.

States States are extracted and saved in the SLIM component object. The identification of initialstates is already performed in the SysMLmodel, therefore no further processing of the states is needed.SLIM makes a distinction between states and modes. States are present in atomic component wheremodes are present in non-atomic components. The model stores both as a state object. During theparing of the SLIM source code, an evaluation of the component determines whether it is atomic ornon-atomic. This evaluation determines whether a state is parsed as a mode or not.

Transitions Transitions are initiated and need to be finalized later in the mapping process, similar toflows and connections.

Error effect Metadata of error effects from the corresponding class object are used to initiate the erroreffect objects for SLIM components. One of the last steps in the mapping phase is finalizing these erroreffects. This is discussed in Subsection 3.6.6.

Pattern properties Pattern properties are modeling elements that are transformed to COMPASSproperties. COMPASS properties are used by the COMPASS tool to run analyses. Pattern propertiesare added as properties of the nominal component.

3.6.3. Creating Subcomponents and ClocksOnce each component and clock has been initiated, subcomponents can be defined. This is done bycomparing the ID of each component with the ID of each subcomponent property of the correspondingclass. If they match, a subcomponent instance is created and added to the component. The subcom-ponent object refers to the particular component it is referencing. This reference allows the program touse all the information of a subcomponent in the parent component.

3.6.4. Finalizing Structure and BehaviorSome elements cannot be directly created and finalized on initiation of the SLIM component. This ismainly due to these elements having references to other SLIM component. The tool initializes compo-nents randomly and therefore a second iteration step is needed to finalize these elements. Subsection3.6.3 discusses the creation of subcomponents and clocks, which also is an iteration step. The ele-ments that need to be finalized in this step are:

• Flows

• Connections

• Transitions

Flows Flows in a component can target a port of a subcomponent. Once subcomponents are created,described in the previous subsection, all subcomponents and their ports are known. This allows theflow to be finalized to see whether the flow targets a port and subcomponent.

Connections Connections can reference to ports of subcomponents, similar to flows. However, con-nections have two port ends, a source end and a target end, both can target a port of a subcomponent.Subcomponents need to be created first to be able to reference these ports.

44 3. The SysML to SLIM Transformation Methodology

Transitions Transitions can be triggered by an event port. This event port can be of a subcomponent.Subcomponents and their ports are needed again to finalize this element as well.

3.6.5. Mapping Error ComponentsError components as described in Subsection 3.3.14 are similar to nominal components but have adifferent internal structure. This different internal structure allows the component to be finalized duringinitialization. No extra iteration steps are needed to finalize the error component.

3.6.6. Create Error InjectionsError effects are stored as elements in the nominal model. Once initiated it stores the metadata ofelements it refers to. One iteration step is needed to finalize the error effect. In this step the erroreffect is finalized using the error models, described in Subsection 3.6.5, and the ports of the nominalcomponent.

3.7. Limitation of the SSTM MethodologyThe capabilities of a methodology are important. Just as important is a clear definition and explanationof the limitations of the methodology. This is especially necessary for methodologies still under de-velopment as the SSTM methodology is. This section describes these limitations and proposes futureimprovements to overcome these limitations. Most limitations of the methodology were set to limit andcontrol the scope of the thesis. If no other cause of the limitation has been mentioned throughout, thisscope controlling cause was the reason for the specific limitation.

3.7.1. Entire Model is TransformedThe SSTM methodology transforms the entire SysML model into SLIM code. All typified elements aretransformed. An improvement is to select only a specific subsystem (defined by a «NodePhysical»stereotype) and only extract and transform the elements belonging to this node. However, this wasnot necessary during the thesis, mainly looking at the performed experiments. This was because theexperiments only covered a single subsystem. For use on a larger scale this feature is recommended.

3.7.2. Missing Automatic Detection of Port Connections DirectionThe methodology does not automatically detect the direction of port connections. This can introduceerrors because it forces the modelers to model connections in SysML in a certain way without the visualfeedback in Papyrus to check whether this is correct. Including an automatic detection to determinewhat the direction of the connection should be would eliminate this error and allows the SysML modelerto model connections much more easily.

3.7.3. Constraint Can Only Be Used OnceConstraints are used to define guards for transitions. However, the same constraint can not be sharedwith multiple transitions. Therefore, a separate constraint, with the same content, needs to be createdfor multiple transitions that rely on the same guard logics.

3.7.4. Shallow References in SysML ModelThe best way to refer to elements in a model is by referring to specific IDs of elements. The SysMLmodel is built mostly out of these references. A modeler does not have to do anything to make thesereferences most of the time, the editor, Papyrus, does this automatically. However, not all informationmodeled in the SysML model can use these ID references. Modeling guards and effects of transitionsis done using plain text in a specific programming language. This is directly interpreted by the trans-formation tool and can not be linked to a specific component. This works if the guards and effects usethe same name for components as defined by the modeler. However, name changes occur regularly.These name changes need to be corrected in these guards and effect as well. This can result in errorswhile using the SLIM model later on. The best option is to improve the creation of guards and effectsso that they use ID references instead of plain text.

3.7. Limitation of the SSTM Methodology 45

3.7.5. Single State Machine per ComponentThe methodology supports a single state machine per component. From this state machine only asingle region is transformed into the SLIM code. Note that this only limits the number of state machinesper component. Each component can have a different state machine.

46 3. The SysML to SLIM Transformation Methodology

Figure3.7:Process

anddata

overviewofthe

SSTMtoolprocedure

4SSTM Methodology Verification

To validate the developed SSTM methodology shown in Chapter 3, the SSTM methodology was vali-dated by modeling a known system. An example SysML model,a battery-sensor system, was modeledin Papyrus and transformed into a SLIM model. A SLIM model of the same example was manuallymodeled parallel to the SysML model. This SLIM model was created following the COMPASS tutorialdocument [22]. This process and the final results of the process were used to verify the methodology.

This chapter presents the developed SysML model and compares the automatically transformedand manually created SLIM models. The source code of the models are compared as well as theresults of the COMPASS analysis of both models. Other factors that were compared are:

• The time it takes to model using the two different approaches.

• The ease-of-use of modeling.

• The eliminating syntax errors.

These factors were being evaluated from the perspective of a system engineer.Section 4.1 provides a description of the system that was modeled for this experiment. The two

following sections, Section 4.2 and Section 4.3, show the most important diagrams and codes of theSysML and SLIM models respectively. Section 4.4 compares the automatically generated SLIM modelwith the manually created one. This is followed by comparing the analysis results of both SLIM modelsin Section 4.5. Section 4.6 describes the verification of the requirements set for the methodology.The requirements are verified using the results from the battery-sensor system model. A comparisonis presented in Section 4.7 comparing the time needed to model the models for each approach, theease-of-use for both methods, and possible errors that may be introduced to each method. With thecreated and verified SSTM methodology described in this chapter the first sub-research question canbe answered. This is presented in Section 4.8.

4.1. The battery-Sensor SystemThe goal of the system that was modeled for this experiment was to provide sensor data. This batterysystem had two sensors for redundancy, each sensor was powered by a Power System Unit (PSU)consisting of a generator generating power, which was transfered to a battery storing a specific charge.The battery was connected to the output power port of the PSU, which powered the sensor. A graphicalrepresentation of this system is shown on Figure 4.1.

The systems had three operational modes. The first and initial mode was the Primary mode. Inthis mode each sensor was powered by the corresponding PSU. Two secondary modes were present,Secondary1 and Secondary2, activated when the first or second PSU failed. In both modes, the stillworking PSU powered both sensors. This is represented by the dashed lines in the figure.

Not presented in Figure 4.1, but modeled for the experiment were the following components:

• Enclosure, this component is the root modeling element containing all other elements.

47

48 4. SSTM Methodology Verification

Figure 4.1: Graphical representation of the battery-sensor system

• Monitor, the monitor is an FDIR component monitoring the system and reacting to arising faults.

• Bus, the bus is a bus component in the system connecting the PSUs and sensors.

• PermanentFailure, this is a error component used to inject errors in the nominal model.

4.2. Battery-Sensor SysML ModelThe battery-sensor example was modeled in SysML using the SSTM methodology steps for modelingthe SysML model. The detailed steps can be found in Appendix A. This section describes the mostimportant modeling steps and provides examples of the diagrams representing the SysML.

4.2.1. Modeling the Package StructureModeling the package structure is of great importance for the modeler. Despite the fact that the trans-formation tool does not need a package structure, having a well thought-out structure makes modelingwith SysML models more organized and therefore more efficient. The SSTM methodology is built onthe OOSEM method and uses its steps for defining the high-level package structure. At node level,a newly developed package organization is used, categorizing hardware, software, utilities, and errorelements in a separate package. The structure for this package is shown in Figure 4.1.

Figure 4.2: Node package structure for battery-sensor experiment

4.2. Battery-Sensor SysML Model 49

Hardware, software and errors are stored in the corresponding packages. The utility packagesstores all elements that are not by default an actual component. In the battery-sensor experiment, theenclosure andmonitor components were stored in the utility package. The enclosure components holdsall the other components and was the start component for COMPASS. Version 1.0 of SSTM neededto have such an enclosure for each node. Future developments will be needed to automatically createenclosure components. This is an improvement to the SSTM methodology. The monitor componentwas an FDIR component which monitored the rest of the system and reacted to faults, trying to resolvethem.

The clocks package in the utility package was used to store all clock components. Instances ofthese clocks were used as subcomponents in nominal and error components.

4.2.2. Creating the Main Components Using a Decomposition DiagramThe main components were created and viewed using a node decomposition BDD. Part associationswere created, which modeled the subcomponents’ structure and the relationship of all components.Figure 4.3 shows the node decomposition BDD for the battery-sensor experiment.

Figure 4.3: Node decomposition, with all components for the battery-sensor experiment

Important to note is that if two instances of the same component were needed in a parent com-ponent, two part associations needed to be created. This can be seen in the Figure 4.3, the Systemcomponent has two instances of the Sensor component and two instance of the PSU component. Thismodelling solution was needed for version 1.0 of SSTM. Future improvements will allow a single partassociation connection with a multiplicity on the target end to model a multiplicity of subcomponents ofthat particular component.

4.2.3. Creating the Component StructureAlmost every component had an external and internal structure. In general, the external structuredefines ports visible outside the scope of the component and the internal structure defines the wiringinside the component. Figures 4.4, 4.5, and 4.6, show the IBD of the PSU, System, and Enclosurecomponent respectively.

Figure 4.4 shows the IBD of the PSU. Three subcomponents can be identified. The Bus componenthas no modeled interaction. The other two components, the generator and the battery, provided thepower requirements for the PSU. External ports on the PSU indicated to the battery whether zero or

50 4. SSTM Methodology Verification

Figure 4.4: Internal Block Diagram of the PSU component

double consumption was being drawn from the battery. This depended on the mode of the system, iewhether the PSU was powering zero or two sensors.

Figure 4.5: Internal Block Diagram of the System component

Figure 4.5 shows the IBD of the system. Two PSUs and two sensor subcomponents had accessto the fifth subcomponent, the bus. Each has_power port of a single PSU was connected to thehas_power port of both sensors. Owned comments, attached to the connection (not visible in thefigure), were used to model in which mode these connections were active. A reference to a state wasmodeled in this comment. The states were modeled in the state machine of the component. Sub-section 4.2.4 elaborates on modeling the behavior of the components using state machines. Modelingconnections between ports has one important constraint. The source port should be selected first whencreating the connection. Secondly, the target port should be selected to finish the connection. Thisensures the correct direction for the connection. This is a limitation of version 1.0 of SSTM. Futureimprovements will allow the connection to be modeled in any direction. The improved transformationtool can evaluate each connection to determine the direction. In the model, flows were modeled withcomments stored in the component. Five flows are visible in Figure 4.5. Each flow was linked to aport it refers to. An extra link was needed when a port of a subcomponent was referred. This linkshould connect the flow comment to the subcomponent instance. This was the case for the four flowsreferring to the ports of both PSUs. Similar to connections, owned comments of the flows were used tomodel in which mode of the component the flows were active. Version 1.0 of SSTM uses comments formodeling flows and in which mode connections and flows are active. Future improvements will changethis behavior for both modeling steps. This will allow the UML comment element to be used purely for

4.2. Battery-Sensor SysML Model 51

commenting, retaining the intended modeling purpose of the comment.

Figure 4.6: Internal Block Diagram of the Enclosure component

The enclosure IBD is shown in Figure 4.6. The system and the monitor for the model were thetwo subcomponents of the enclosure. The monitor, an FDIR component, monitored and controlled thesystem. This was done by the monitor and control ports of both components, which were connected inthe enclosure.

Modeling the monitor as an FDIR component with FDIR alarms prepared the model for FDIR anal-ysis. This was an important addition resulting in detailed analysis possibilities. The FDIR analysisperformed on the system using this monitor component is described in Subsection 4.5.3.

4.2.4. Model Component BehaviorThe behavior of components was modeled using state machines. The state machine diagram for thesystem component is show in Figure 4.7. The initial state of the system was the primary state asindicated by the transition from the initial pseudo state to the primary state. Two event ports,go_to_secondary1 and go_to_secondary2, were present in the system model, as can be seenin Figure 4.6. These events triggered two possible transitions putting the system in either the sec-ondary1 or secondary2 state.

Figure 4.7: State machine diagram of the system component

The behavior of the system component was relatively simple with only three states and two tran-sitions both triggered by an event port. The battery component had a more complex behavior. The

52 4. SSTM Methodology Verification

charge of the battery depends on being powered by the generator and the amount of sensors con-nected to the PSU the battery is part of. This was modeled in the state machine of the battery, the statemachine diagram of the battery is shown in Figure 4.8.

Figure 4.8: State machine diagram of the battery component

Generally, the initial state, the full state is themain state of the battery. When no power is providedto the battery the charge decreases. Depending on whether double consumption is requested, thebattery enters one of the two states where the charge is low, low_single or low_double. Besidesmaintaining this state, the only other state the battery can go into from this point onwards is the emptystate. This state is reached when no charge is left in the battery.

Transitions are not started by a trigger of an event port, which is the case in the System component,but started by guards. Guards are expressions; once these expressions are true the transition is started.Where guards start transitions depending on other variables in the component, effects change thesevariables once a transition has been performed. In version 1.0 of SSTM, guards and effects are writtenin SLIM expressions. This is done using OpaqueExpressions and OpaqueBehaviors. An importantfuture improvement for the systems engineering modeler will be a dedicated element to model theguard and expressions without SLIM expressions. This guides the modeler and prevents errors madedue to mismatching elements names and SLIM syntax, as previously discussed in Subsection 3.7.4.

4.2.5. Modeling Error ComponentsError components were used to model errors that could be introduced to the nominal model by meansof error injections. Important is to note when to model errors or when it is better to the fault in thebehavior of the nominal component. No hard guidelines are present for modeling errors. However, inthis example and in the case study presented in Chapter 5, an error was defined as an unexpected statewhich is very hard to recover from. In the battery-sensor example, the error used was a permanentfailure, meaning the component that was affected by this error would not work and no option of recoverywas present. For example, it is not advisable to model a calibration error for an gyroscope using anerror model. Recalibration of the sensor is an expected operation for which most sensors are designedfor. In this case, it is better to model a state in the model where output will differ due to drift, for example.Transitions triggered by a calibration event or activated periodically return the component to the nominalstate with the correct output.

An error component models the error events that changes the state of the error model. Each errorcomponent starts in an initial non-error state. Events and guards can trigger a transition from theinitial state to an error state. Figure 4.9 shows the state machine diagram for the error component,

4.2. Battery-Sensor SysML Model 53

PermanentFailure, of the battery-sensor system.

Figure 4.9: State machine of the PermanentFailure error component

Error injections are used to combine error components with nominal models. An error injection isa property of the nominal model affected by the error. This property is typified with the «ErrorEffect»stereotype. This stereotype has four properties, see Figure 4.10. The first property selects the errormodel this error injection referred to. The second property is the state of the error model which triggersthe error injection and change the nominal model. The third property is the element of the nominalcomponent that changes due to the error component reaching the error state selected for the secondproperty. The last property of the stereotype is the effect on the target element. This is modeled as aSLIM expression.

Two components in the battery-sensor system were injected with an error. The two componentswere the generator component and the sensor component. Both components were injected with thePermanentFailure error and were triggered when this error model was in the dead state. The outputport has_power in the generator component was set to false once this state had been reached. Thesensor component reacted by setting the reading output port to false in the dead state. Figure 4.10shows the settings for the sensor error injection.

Figure 4.10: Settings for the sensor error effect

54 4. SSTM Methodology Verification

4.2.6. Adding Pattern Properties to the ModelPattern properties are used to analyze the system in tests. Subsection 3.3.16 of the previous chapterdescribes the different kinds of pattern properties. The pattern properties are modeled as properties ofa nominal model. For the battery-sensor experiment 1, pattern properties were added to the enclosurecomponent.

4.2.7. Transforming the SysML Model into SLIM CodeOnce the SysML model is created, it can be transformed using the SSTM tool. Figure 4.11 shows theinterface of the SSTM tool. The first step to transform the model is to load it with the tool. Once themodel is loaded it is automatically stored in the tool and converted to SLIM objects ready to be exported.The progress can be seen in the progress window at the bottom of the interface. The next step is toselect an output directory where the SLIM file is saved. This is followed by setting the filename of theSLIM file. The last step is to export the SLIM model to the SLIM file. Two possible options can beselected. The first option, Write SLIM to file, writes the component type and implementationtogether, component by component. The second option, Write SLIM to file Types first,writes all the type declarations of each component first and then writes all the implementations of thecomponents. The SLIM model does not change and both files can be used by the COMPASS tool. Asoftware engineer evaluating the SLIM code might prefer a certain code style, therefore the two optionsare presented.

Figure 4.11: Interface of the SSTM tool

Listing B.1 in Appendix B, shows the automatically generated SLIM code from the battery-sensorexample presented in this section. The selected output format is the second option, Write SLIM tofile Types first, First all the type declarations are written followed by the implementations of thecomponents.

4.3. SLIM Model Battery-Sensor SystemThe SLIM code for the battery-sensor system was written manually as well. Listing B.2 in Appendix Bshows this code. The code was written following the instructions of tutorial in the COMPASS tutorial[22]. From a systems engineering point of view it takes time getting used to modeling a system in SLIM.The type declarations were programmed first and later the implementations were created. FDIR com-ponents and properties were programmed last. The pattern properties were created in the COMPASStool once the model was loaded.

4.4. Comparing the Manual and Automatically Created SLIM Codes 55

4.3.1. Adding Pattern PropertiesAdding pattern properties can be done in two ways if a SLIM model is manually created. The firstoption is to add the pattern properties to the source code. This has a disadvantage of being errorprone which can result in an incorrect model. The second option is to use the COMPASS tool to createthe properties using its GUI. This guides the modeler in creating the properties. The model needs tobe saved with the properties. This new file needs to be used further on to update the model, else theentire process of creating properties need to be done again.

4.3.2. Modeling TimeThe SLIM model was manually created using the instructions in the COMPASS tutorial document [22].Several days were needed to understand the basic SLIM syntax and to model the battery-sensor sys-tem. Learning the SLIM language has a steep learning curve. This was relatively fast considering theextensive programming and software knowledge and experience of the modeler. If a system engineerwithout this amount of programming and software knowledge and experience should (attempt to) modelthe system, the time to model the system would drastically increase. It is not common for a systemsengineer to have this amount of programming and software knowledge. Using an automated trans-formation tool to generate the SLIM code is extremely useful for the standard systems engineer. Nomanual SLIM code needs to be written thus eliminating the steep learning curve of the SLIM language.

4.4. Comparing the Manual and Automatically Created SLIM CodesDuring the experiment the automatically generated SLIM code was compared with the provided batter-sensor SLIM code from the COMPASS project. The manually created code was created with theinstructions of the COMPASS tutorial document. This resulted in the same code that was provided bythe COMPASS project. The automatically transformed code can therefore also be compared with theprovided code. For the same reason, the next section can for the same reason compare the COMPASSresults from the transformed model with the results from the COMPASS documentation. This was doneto iteratively verify the code and tool. Once a verification process was successfully endedmore featurescould be added to the transformation tool. This process is described in Subsection 4.4.1. The secondsubsection, Subsection 4.4.2, elaborates on the differences in the automatically and manually createdSLIM codes.

4.4.1. Verifying the Model and Improving the SSTM Transformation ToolThe first step in comparing the two source files was to load them both into the COMPASS tool. Everymodel loaded by the tool was being checked to see whether it was a valid model. A second moreelaborated verification step was to compare the automatically created code with the provided SLIMcode of the example system that was modeled.

During the development of the tool and while performing this experiment several attempts weremade to load the automatically created model in the COMPASS tool. Most of the time an compileerror was thrown, indicating an incorrect model. The debug log showed the point were the compilerthrew the error and from this point the second verification step was started. Where the error occurred acomparison between the automatically created code and the provided code was performed. This leadto the exact fault in the code generation of the SSTM tool.

This process of verifying and improving the model was done numerous times, beginning with simplemodels where not all of the functionalities were modeled. Once a simple model was successfully loadedinto the COMPASS tool, features could be added. This iterating process resulted in an elaboratedexperiment where with every iteration the SysML model was improved as well as the transformationtool.

4.4.2. Code Differences Between Automatically and Manually Generated CodesThe majority of the automatically and manually generated codes were the same. Two main differencescould be addressed.

The first difference was that pattern properties were directly saved in the automatically generatedcode. This was not done for the manually generated code, because these pattern properties wereadded using the COMPASS tool. The source code did however contain these properties once they areadded using the COMPASS tool and if the model was saved afterwards.

56 4. SSTM Methodology Verification

The second difference was an addition that the transformation tool added. Transitions in the manu-ally generatedmodel are not generally named by default. This can be confusing, especially for someonewho is not familiar with the system. Finding out which transition does what can be a time-consumingtask. However, transitions in SysML do have a naming property. This naming property is used in thetransformation tool to add comments after the transition has defined the name of the transition. Anexample of this is shown in Listings 4.1 and 4.2. Both listings show the same monitor component. Thefirst of the two is the manually created, without identifying the names of the transition. The secondlisting shows the code of the automatically generated code. Each transition in this listing ends with --transition name: <name of transition>, naming the transition. This makes reading theSLIM code much easier.1 [ Name => ” never NOT i s _ a l i v e ” ; Pa t te rn => ” Globa l ly , i t i s never the case

t ha t not sys . i s _ a l i v e holds ” ; ] ,2 [ Name => ” never Secondary1 ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t

sys .mode = mode : secondary1 holds ” ; ] ,3 [ Name => ” never Low_double ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t

sys . psu1 . ba t t e r y .mode = mode : low_double holds ” ; ] ,4 [ Name => ”B1_LOW > ALARM_B1 ” ; Pat te rn => ” Globa l ly , i f sys . psu1 . ba t t e r y . low

has occurred then in response mon. a larm_bat tery1 even tua l l y holds ” ;] ,

5 [ Name => ”ALARM_B1 > SECONDARY2” ; Pat te rn => ” Globa l ly , i f mon.a larm_bat tery1 has occurred then i n response sys .mode = mode : secondary2 even tua l l y holds ” ; ] ,

6 [ Name => ” Ba t te ry low responded by reconf ” ; Pa t te rn => ” Globa l ly , i f sys .psu1 . ba t t e r y . low or sys . psu2 . ba t t e r y . low has occurred then i n response sys .mode = mode : secondary1 or sys .mode = mode : secondary2 even tua l l y holds” ; ]

7 ) ;8 end Enclosure . Imp ;910 system implementat ion Moni tor . Imp11 subcomponents12 delay : data c lock ;13 connect ions14 f low t rue > a la rm_bat te ry i n modes ( recovery ) ;15 s ta tes16 base : i n i t i a l s t a t e wh i le ( delay <= 1) ;

Listing 4.1: Transitions in the manually generated code

1 system implementat ion Moni tor . Imp2 subcomponents3 delay : data c lock ;4 connect ions5 f low t rue > a la rm_bat te ry i n modes ( recovery ) ;6 s ta tes7 base : i n i t i a l s t a t e wh i le ( delay <= 1) ;8 recovery : s t a t e wh i le ( delay <= 1) ;9 t r a n s i t i o n s10 base [ when delay >= 1 and not bat te ry1_ low and not bat te ry2_ low then delay :=

0 ] > base ; t r a n s i t i o n name : base > base11 base [ go_to_secondary1 when delay >= 1 and bat te ry1_ low then delay := 0 ;

a larm_bat tery1 := t rue ] > recovery ; t r a n s i t i o n name : go_to_secondary112 base [ go_to_secondary2 when delay >= 1 and bat te ry2_ low then delay := 0 ;

a larm_bat tery2 := t rue ] > recovery ; t r a n s i t i o n name : go_to_secondary213 recovery [ when delay >= 1 then delay := 0 ] > recovery ; t r a n s i t i o n name :

recovery > recovery14 p rope r t i e s15 FDIR => t rue ;16 end Moni tor . Imp ;

Listing 4.2: Transitions in the automatically generated code

4.5. Comparing COMPASS ResultsAfter the source code of the automatically created SLIM model was compared to the example code andthe manually created code it was possible to perform an analysis on the model using the COMPASS

4.5. Comparing COMPASS Results 57

toolset. The COMPASS tutorial document [22] provides a detailed overview of the possible analyticaloptions and how to perform these tests. Subsection 2.2.6 gives a summary of these options.

The following sections from the COMPASS tutorial document [22] were performed. All results arethe same as those provided in the COMPASS tutorial documentation [22].

• 4.5 Simulating a Model

• 4.9 Model Checking a Property

• 5.6 Simulating the Extended Model

• 5.7 Model Checking the Extended Model

• 5.8 Fault Tree Analysis

• 5.9 Fault Tree Evaluation

• 7.3 Safety Analysis Revisited

• 7.5 FDIR Effectiveness Analysis

– 7.5.1 Fault Detection Analysis– 7.5.2 Fault Isolation Analysis– 7.5.3 Fault Recovery Analysis

Most of these analyses were performed, resulting in a confirmation that the model performed thetest successfully. Or an expected error was shown with a corresponding counter example as of whya property was not met. Three kinds of analysis are described in more detail, following the outputdiagrams of these tests. Subsection 4.5.1 describes the first step in analyzing the model. This ransimulations on the model to analyze whether it behaves correctly. Subsection 4.5.2 shows and dis-cusses fault trees. Subsection 4.5.3 shows the fault isolation diagrams created by the model using theanalytical steps described in Subsection 7.5.2 of the COMPASS tutorial document [22]. All analysisperformed resulted in the same results compared to the provided example model, thus proving that theSysML model was correctly transformed into the intended SLIM code.

4.5.1. Simulating the ModelThe first analysis to be performed in the COMPASS toolset was to simulate the model. Simulating themodel gives the first insight into the behavior of the model. Three options are present in the COMPASStoolset:

1. Random simulation

2. Guided by transition simulation

3. Guided by values simulation

The first option was selected for the battery-sensor system. Random events were triggered in themodel and the response observed by the trace stack output of the simulation. Figure 4.12 shows a partof the stack trace of the battery-sensor system random simulation.

All components and their data component, such as ports, are listed in the first column. Error modelsand their values are colored red. The trace stack of each value was plotted in the other columns. Eachcolumn is a different, increased time step. Boolean values were plotted as a line which could have alow value (false) and a high value (true). Modes and states of components are plotted as the namebetween triangle brackets.

Analyzing this trace stack gave information on how the system behaved and whether the intendedresponse was produced. Errors in the model can be found at this point. The trace stack gives a goodindication of where such an error occurs and provides the modeler with insight needed to change this.For the battery example, this was also the case. The simulations showed that a connection was notcorrectly defined for the first iteration of the automatically generated model. Using this information thesolution of the problem was easily found and implemented in the SysML. After re-transforming andimporting the updated model in the COMPASS tool the simulation showed the expected behavior.

58 4. SSTM Methodology Verification

Figure 4.12: Random simulation stack trace of the battery-sensor system

4.5.2. Fault Tree AnalysisSeveral fault trees of the model could be generated:

• Before reactive behavior is introduced into the model.

• After reactive behavior is introduced into the model.

Probabilities for both options can be set, all resulting in different fault tree diagrams. Figure 4.13 shows afault tree diagram exported by the COMPASS tool of the final automatically generated reactive battery-sensor model. This fault tree was generated from the property stating that the system was not alive.Probabilities of several failures were modeled in this test. The probability of a sensor failure was set to0.3, the probability of a generator failure was set to 0.2.

The fault tree shows that two AND branches were present, fault_cfg_1 and fault_cfg_2. Thefirst branch is the probability of both sensors failing. The second branch is the probability of bothgenerators failing. The overall probability of the system failing was the probability that either one of thebranches would fail, !sys.is_alive. The overall probability of failure was calculated to be 0.126.

These fault trees will not only calculate the failure probability, but also gives a good indication ofwhether the system was modeled correctly. During the experiment of the automatically generatedmodel the first fault tree analysis resulted in an unexpected fault tree. Further investigation showedthat the reactive model was not set correctly. This made the system not react correctly to a generatorfailure. This was not found out before the fault tree was generated. Fixing this incorrect modeling partresulted in the fault tree representing the expected behavior.

4.5.3. FDIR Fault Isolation AnalysisFault isolations analysis can be performed on a model, this is described in detail in Subsection 7.5.2of the COMPASS tutorial document [22]. Three alarms were modeled in the battery-sensor system,alarm_battery, alarm_battery_1, and alarm_battery_2. During the fault isolation analysisdiagrams were created showing which faults may have triggered the selected alarm. Figure 4.14 showsthe fault isolation diagram for the alarm_battery alarm. A failure in the generator of either PSU1or PSU2 may have activated the alarm. The fault trees for fault isolation analysis do not show theprobability of a fault. The probabilities, P in the figures, were therefore set to 0.0. If the user wantsto calculate the probability of an alarm being activated the fault tree analysis should be performed. Aproperty should be created stating when the alarm is turned on.

4.5. Comparing COMPASS Results 59

Figure 4.13: Fault tree for automatically generated battery-sensor system model

Figure 4.14: FDIR fault isolation tree for alarm alarm_battery

60 4. SSTM Methodology Verification

Figure 4.15: FDIR fault isolation tree for alarm alarm_battery_1

Figure 4.15 shows the fault isolation tree for alarm_battery_1. It is a simple fault tree showingthat only a failure in the generator of PSU1 may result in the alarm being triggered.

Figure 4.16 shows the last fault isolation diagram. Almost identical to the diagram for alarm_battery_1this diagram shows that only a failure in the generator of PSU2 may trigger the alarm_battery_2alarm.

4.6. SSTM Methodology Requirements VerificationThe SSTM methodology was verified based on the battery-sensor system. Chapter 1 specified severalrequirements for the methodology, tool, and results. The requirements of the three categories were:

1. SSTM modeling method related requirements:

1.1. SSTM shall provide a profile that will be used to model systems with the SSTMmethodology.

1.2. SSTM shall give modeling steps, interpretable by a systems engineer, to model component-based systems.

1.3. SSTM shall give modeling steps, interpretable by a systems engineer, to model timed be-havior modeling for the system of interest.

1.4. SSTM shall give modeling steps, interpretable by a systems engineer, to model event-basederrors.

1.5. SSTM shall give modeling steps, interpretable by a systems engineer, to model injection oferrors in the nominal model.

2. SSTM transformation tool-related requirement:

4.6. SSTM Methodology Requirements Verification 61

Figure 4.16: FDIR fault isolation tree for alarm alarm_battery_2

2.1. The SSTM transformation tool shall be able to automatically transform SysMLmodels, madeusing the SSTM profile and method, into compilable SLIM models.

3. COMPASS result related requirement:

3.1. The results from the COMPASS toolset shall enable the refinement of the SysML model.

4.6.1. 1 Modeling Method RequirementsFive requirements were identified for the modeling method of the SSTM methodology. Each require-ment was verified by the modeling of the battery-sensor system.

1.1 SSTM shall provide a profile that will be used to model systems with the SSTMmethodology.The SSTM provides a custom profile for the Papyrus tool. This profile is discussed in Subsection 3.3.1.The battery-sensor system successfully used this profile to model the system. This satisfied the firstrequirement.

1.2 SSTM shall give modeling steps, interpretable by a systems engineer, to model componen-t-based systems. The battery-sensor system was a component-based system. This chapter hasshown that the method supports the modeling of such systems. Subsection 3.6.1 describes all thesupported SLIM components. This requirement is satisfied for the intended supported components.One of the improvements of the method and methodology is the support of data components, which isnot included in this requirement. The support for data components allows the modeler to easily modelconnections between subsystems that better represent the actual system. Buses can be modeledwhere a stream of data is connected to each subcomponent. This point of improvement is discussedin more detail in Chapter 6.

62 4. SSTM Methodology Verification

1.3 SSTM shall give modeling steps, interpretable by a systems engineer, to model timed behav-iormodeling for the system of interest. The SSTMmethod supports themodeling of timed behaviorfor nominal models. This is demonstrated with the battery-sensor system. The battery component inthis system is modeled using a clock. When the battery is being depleted, the clock tracks the amountof charge left. This demonstrates the use of timed behavior and with the successful transformation andthe results provided in this chapter it also verifies this requirement.

1.4 SSTM shall give modeling steps, interpretable by a systems engineer, to model event-basederrors. The battery-sensor system had one error component, used to inject errors into two compo-nents. The error model was event-based, as described in Subsection 4.2.5. The transformation of thiserror model was successful and the results in COMPASS showed the correct behavior of this errormodel. This verifies the third method-related requirement.

1.5 SSTM shall give modeling steps, interpretable by a systems engineer, to model injectionof errors in the nominal model. Two components of the battery-sensor system were injected witherrors. The components affected by the error model were the generators in each PSU and both sensors.The modeled error injections, described in Subsection 4.2.5, were successfully transformed into theSLIM model. The results from the COMPASS tool also showed that the error injections resulted in theintended function change of the components. All this verifies the error injection requirement.

4.6.2. 2 SSTM Tool RequirementsThe requirement for the SSTM tool can be divided into two parts which can be verified separately. Thefirst part of the requirement is that the SSTM tool should be able to automatically transform the SysMLmodel into SLIM code. The second part states that the output SLIM code should be a correct SLIMmodel that can be compiled.

The first part of the requirement was verified by looking at the produced code. This was done beforethe comparison described in Section 4.4. This part was verified early on in the modeling of this system.However, it did not verify that the produced SLIM code was a correct SLIM model.

The SLIM file was loaded in the COMPASS toolset to verify whether the code was a correct modelthat can be compiled. The COMPASS toolset notifies the user with a syntax error if it is an incorrectmodel. It is not possible to perform analysis on the model when these errors are detected. Loading themodel into the COMPASS toolset did not result in any errors. The COMPASS toolset notified that thecode was successfully compiled. Therefore, this verifies the second part of the tool related requirement.

Both parts of the requirement are verified, indicating that the tool requirement, Requirement 2.1, isalso verified.

4.6.3. 3 COMPASS Result RequirementsThe last requirement is a requirement set based on the use of the results from COMPASS. Designingandmodeling any system is an iterative process. With each iteration, the system is improved. Iterationsneed improvement points to be useful. The improvement points for modeling using the SSTM method-ology come from COMPASS analyzes. It is important for the SSTM methodology that the results giveindications on how the SysML model can be improved, otherwise no changes to the input model canbe made and the iterations stops.

While modeling and analyzing the battery-sensor system several improvement points were found.These points were found during COMPASS analyzes. The two improvement points, the incorrect nom-inal behavior and incorrect fault response, were found during the simulation of the model, described inSubsection 4.5.1, and in the fault tree results, described in Subsection 4.5.2.

The SSTMmethodology and tool uses the names of components and elements defined in the SysMLmodel for the creation of the SLIM model. Therefore the results from the COMPASS analysis show thesame names used in the SysML model. With the results of the analysis it is then easy to change theSysML model. This was done for the battery-sensor system. The changes were used in the sequen-tial iterations, which resulted in the final correct model. These together showed that the COMPASSresults can be used to iteratively improve the SysML model, therefore verifying the last requirement,Requirement 3.1.

4.7. Time, Ease-of-Use, and Error Comparison 63

4.7. Time, Ease-of-Use, and Error ComparisonThe main purpose of this first experiment was to verify the SSTM methodology and tool. The previoussections show the main results of the verification. Additional modeling-related information besidesverifying the model were also discovered during the experiment. Three main factors were found duringthe experiment:

1. The time it takes to model using the two different approaches.

2. The ease-of-use of modeling.

3. The eliminating syntax errors.

These factors are discussed in this section.

4.7.1. Modeling TimeFrom a systems engineering point of view, working with a graphical modeling language, such as SysML,is much easier and faster than programming an entire system in a text based programming language.Modeling the battery-sensor system also showed that less time was needed to model the system inSysML with the SSTMmethodology. Themodeling time decreases over time, due to experience gainedwith the methodology.

The time needed to manually model a SLIM model also decreases over time, but not as much asusing SysML with the SSTMmethodology. By increasing system complexity it is less easy to maintain ahigh-level overview of the system functionalities. Modeling in SLIMmakes it even harder tomaintain thisoverview but modeling with SysML allows the modeler to easily maintain it. The different diagrams andgraphical modeling tools support the modeler in this perspective. This ultimately reduces the modelingtime for larger systems.

An estimation of the time and costs saved by the use of SSTM is presented in Subsection 4.7.4

4.7.2. Modeling Ease-of-UseModeling a system in SysML with the SSTM methodology is much easier than modeling the system inSLIM. This is especially the case for systems engineers who do not necessarily have deep programmingknowledge and experience. Even if the systems engineer has the required programming knowledge,using a graphical language makes the creation of a model much easier. For simple systems, this doesnot always count, but larger systems starting with comparable or higher complexity than the battery-sensor system do benefit from a graphical tool. Having multiple views of the system limits the amountof content visible and gives more overview of the viewed content.

4.7.3. Error RemovalThe SSTM methodology guides the modeler in creating the model correctly. If elements need to beselected, only the correct types of elements are shown. Spelling mistakes are also eliminated because(only) references to elements are stored. The name of the referenced element is used during thetransformation. This ensures that the correct name is used, even if the referenced element changesnames.

Possible syntax errors are also eliminated because the transformation tool takes care of this. Thesyntax of the SLIM language is not always straight forward. For example setting a default value to trueis done as follows: Default => ”true”;. Another property that can be set for a port is typifies it asan observable, this is done in the following way: Observable => true;. Using the parenthesis is ofgreat importance for the language, but is easily modeled incorrectly, resulting in errors while compilingthe SLIM model in the COMPASS tool. Using SSTM removes these possible errors in incorrectlymodeling the SLIM model by incorporating these syntax rules in the transformation.

4.7.4. Time and Cost Savings EstimationIn order to quantify the saved time and cost by using the SSTM methodology, an estimated calculationwas made. Calculations on the development time and cost were made as well as the time and costsaved with the use of SSTM. This was compared to calculate the Return Of Investment (ROI). Thesecalculations are presented in this subsection.

64 4. SSTM Methodology Verification

Human labor cost In order to calculate the total cost of the development and while using the SSTMmethodology in production, the salaries of software engineers and space systems engineers are needed.Table 4.1 shows the salary indications for software engineers and space systems engineers. All salaryindications are for jobs in the United States of America. The salary per hour was calculated assuming2350 work hours per year [34]. The hourly rate was assumed to be three times the salary per hour.This includes taxes, other overhead costs and profit.

Table 4.1: Software engineer and space systems engineer salaries

Job title Annual salary ($) Salary ($/hour) Hourly rate ($/hour)Software engineer [36] 69,000 29.36 88.97

Senior software engineer [35] 100,000 42.55 128.95Space systems engineer [37] 103,000 43.83 132.82

Senior space systems engineer [40] 128,000 54.47 165.05

SSTMdevelopment cost The development cost of the full SSTMmethodology can be calculated withthe presented salaries of the software engineers and space systems engineers. For the developmentof version 1.0 of the SSTM methodology, an estimated 340 hours of effective work was performedonly on the development of the methodology and the transformation tool. Improvements to the SSTMmethodology are needed to have a full working methodology. These improvements are discussedin Chapter 6. It is estimated that version 1.0 of the SSTM methodology is 25% of the final SSTMmethodology, thus a total of 1,360 hours needs to be spent to create a full SSTM methodology. Thisis split equally between space systems engineering work and software engineering work.

A breakdown of the development cost is presented in Table 4.2. Both the hours for a space systemsengineer and a software engineer is set to 680 hours. The subtotal cost is the cost for both disciplines.Version 1.0 of the SSTMmethodology is created by a single person performing both the space systemsengineering work and the software engineering work. Therefore, no additional communication betweenthe two disciplines is required. For the continuation of the SSTMmethodology it is assumed that multiplepersons work on the development. This adds an additional communication time and cost, which isassumed to be 30% of the individual cost. This results in the total development cost of $196,064.47.

Table 4.2: SSTM development cost

SSTM development costSpace systems engineer 680 Hours

132.82 $/hour$90,315.93 Cost

Software engineer 680 Hours88,97 $/hour

$60,502.90 Cost

Subtotal development cost $150,818.83Total development cost $196,064.47 +30%

Saved time During the modeling of the battery-sensor, system several iterations were performed,both for the manually created code and the automatically generated code from the SysML model.These iterations came from the COMPASS results after running analyzes. Updating the SysML modelby a systems engineer would take no more than one minute. It is estimated that 15 minutes are neededif the systems engineer, analyzing the results, would have to communicate the improvement to a soft-ware engineer who then would have to change the manually created SLIM code.

It is assumed that for a project an estimation of eight improvements as described above can beexpected each day during the development of a space system. If the SSTM methodology is not used,

4.8. Answering First Sub-Research Question 65

Figure 4.17: SSTM Return Of Investment (ROI)

it result in 450 hours per year spent on adding these improvements in the SLIM code. Using the SSTMmethodology reduces this to 30 hours per year. Both calculations assume 225 billable days per year.

The hours needed without the use of the SSTM methodology are assumed to be equally distributedover space systems engineers and software engineers bringing the total cost of these iterations to$49,903.29 per project per year. If the SSTM methodology is used, the hours spent on the iterationare performed by a space systems engineer bringing the total to just $3,984.53 per project per year.These values are summarized in Table 4.3.

The cost estimation above is a simple assumption showing the difference in time and cost for asingle project per year. The saved cost per year for one project is $45,918.76. If only a single projectuses the SSTM methodology the development cost is saved within 4.27 years. Logically, when moreprojects use the SSTM methodology the ROI could be sooner, as can be seen in Figure 4.17. Figure4.17 shows the saved costs when one, two, three, or five projects are using the SSTM methodology,these are indicated by the orange, yellow, green, and purple dataset. The blue line dataset indicatesthe investment needed for the SSTM methodology. The ROI is at the point of intersection between theinvestment and one of the project datasets.

Table 4.3: Iteration cost per year, with and without the use of SSTM

Iteration cost per yearWithout SSTM With SSTM

Space systems engineer Software engineer Space systems engineer225 225 30 Hours

132.82 88.97 132.82 $/hour$ 29,883.95 $20,019.34 $3,984.53 Cost

$49,903.29 $3,984.53 Total cost per year

4.8. Answering First Sub-Research QuestionThe first sub-research questions, What are the minimal requirements to have a func-tional model to model transformation between SysML and SLIM?, is answered withthe first version of the SSTM methodology as described in Chapter 3 and the verification of it in thischapter. The requirements are set in Chapter 1 and verified in Section 4.6. The three intermediatequestions are also answered in the Chapter 3 and this chapter, they are summarized below.

66 4. SSTM Methodology Verification

1.1.1: Which methods are needed for a minimal functional model to model transformation?Chapter 3 describes the methods needed for the minimal transformation. Section 3.3 describes thesteps to perform to model a SysML model with the SSTM methodology. These steps were executedon the battery-sensor system as described in Section 4.2. Subsection 4.6.1 verifies the requirementsset for this sub-research question.

1.1.2: Which tools are needed for a minimal functional model to model transformation? Twotools are used for the transformation. The first tool is Papyrus to model the SysML model of a systemwith the provided SSTM profile. The use of Papyrus to model a SysML is described in Section 4.2.

The second tool to use is the newly created SSTM transformation tool. The use of the transfor-mation tool is described in Subsection 4.2.7. Subsection 4.6.2 verifies the requirement set for thetransformation tool.

1.1.3: How is the minimal transformation performed? The detailed steps on how the minimaltransformation is performed is answered in Sections 3.4, 3.5, and 3.6.

5ADCS Case Study

The SSTM methodology was tested and verified in Chapter 4 using a simple battery-sensor system.The next step in testing the methodology was to use a more complex case study. The case studychosen was an ADCS system.

The ADCS subsystem is a complex subsystem that makes use of sensors to determine and controlthe attitude of a spacecraft. A vast number of sensors can be used in the ADCS subsystems. Examplesof attitude sensors are: sen-sensors, start-trackers, magnetometer, gyroscopes, accelerometers andmany more.

The readings of the sensors are used in the ADCS processing units to determine the action requiredto keep the spacecraft at the intended attitude. The intended attitude is influenced by many factors suchas:

• The mission goal.

• The flight phase the spacecraft is in.

• The current position in the orbit.

• Failure of components.

The processing units control actuators once the intended attitude is determined. The actuatorscan change the attitude of the spacecraft. Like sensors, different kinds of actuators can be used in aspacecraft. Some examples are: reaction wheels, thrusters, magnetic torquers.

The complexity of the components in the ADCS subsystem and the numerous attitudes the space-craft needs to be in makes the ADCS subsystem a challenging system to model. This is a perfectsubsystem for a case study to discover the current limitations of the SSTM methodology.

The ADCS case study was modeled with two kind of sensors and one kind of actuator. The goalof the case study was to find the current limitations of the methodology and find improvement pointsfor future development of the methodology and tool. This chapter describes the process of creating,transforming, testing and evaluating the case study.

Section 5.1 provides the overview of the case study and defines its scope. A high level graphicaloverview is given defining all the components. The modeling of the nominal system is described inSection 5.2. Section 5.3 describes the error models of the system. The ADCS case study implementsmultiple error models. A specialized error model was modeled for each component that can fail. Thetransformation of the model using the tool is described in Section 5.4. The output SLIM code is com-pared to a reference code that is used to model the case study. Section 5.5 shows two parts of theSLIM code and the comparison with the SysML model. The last section, Section 5.6, presents theanalysis performed in the COMPASS tool and the results from these analyzes.

67

68 5. ADCS Case Study

5.1. Overview of the ADCS SystemThe case study modeled in this chapter was a ADCS subsystem of a spacecraft. The ADCS systemcomprises of a attitude determination part a [48]. For smaller satellites such as cubesats a selectamount of sensors and actuators are used [39][44][43][46]. The set of attitude sensors described are:

• Magnetometer [44][43][46][39]

• IMU[39]

– Accelerometer[46]– Gyroscope[46][44][43]

• Gps [39]

• Sun sensor [44][43]

As subset of actuators is also described:

• Reaction wheel [39] [46]

• Magnetorquer [39]

• Monopropellant thrusters [15]

The case study is modeled as a simplified ADCS system of a cubesat. Two sensors are chosen tomodel and one actuator. This limits the complexity of the system to model, which reduces the modelingtime to fit the modeling and testing of the case study within the scope of the thesis.

A high-level overview of the case study system is shown in Figure 5.1. The main ADCS systemused here had two types of sensors, GPS and IMU. The system had two instances of each sensor forredundancy. These sensors were connected to two identical ADCS computers: one called the mastercomputer and the other called the slave computer. The computers controlled two reaction wheels (RW).All components were powered by an Electrical Power System (EPS). For redundancy, two instancesof the EPS are present in the system, each powering half of the components. In Figure 5.1, the yellowconnections indicate the power lines from the EPS to the components, the green connections the dataconnections between components.

A system goal needed to be set to determine when the ADCS system is able to detect and controlthe attitude of the spacecraft. The constraint was set to be the following: At least one of thereaction wheels needs to work for the entire system to work. A reaction wheelworks if it has power and is controlled by one of the computers. A computer can control a reactionwheel when it has power and input from at least one GPS and one IMU. The sensors work when theyhave power. The set goal ensures that both the determination and the control of the attitude is satisfied.

The behavior described above is the nominal behavior. The modeling steps of this nominal modelare described in Section 5.2 below. Error models and effects were added to the system to establishmore complex behavior. This is described in Section 5.3.

The system was connected to the Command and Data Handling System (CDHS) component. TheCDHS subsystem in a spacecraft handles the command and data of the spacecraft. In the case studythe CDHS component was used to monitor the ADCS system and activate FDIR alarms. Because itwas modeled as an FDIR component it was given the name: FDIR_CDHS.

5.2. Modeling the Nominal SystemThe nominal system models the system as it reacts to normal events. This section is divided intoseveral subsections, one for each component.

5.2.1. EPSThe EPS component provides power. The nominal model of the EPS has one boolean output port,has_power. This port indicates whether the component is able to provide power. The default valueis set to true. In the nominal model the EPS always provides power. The error model and injectionintroduce the lack of power. This is presented in Section 5.3.

5.2. Modeling the Nominal System 69

Figure 5.1: Graphical representation of ADCS case study system

5.2.2. GPSThe GPS unit was the first sensor of this ADCS system. It had one input port and one output port. Theinput boolean port, has_power, determined whether the component had power. The output booleanport, reading, determined whether the components output a sensor reading.

Figure 5.2 shows the state machine diagram of the GPS component. The component had onestate. Two transitions to the same state were defined. An evaluation was made every time step. If thecomponent had power, then it had a reading. If it lost power, the reading is stopped.

5.2.3. IMUThe second sensor, the IMU, was modeled similar to the GPS component. The ports and the behaviorwere the same as previously described. As long as the IMU had power, it produced a reading.

5.2.4. Reaction WheelThe reaction wheel was the actuator component of this system. If the reaction wheel was working,the boolean output port, working, was true. The reaction wheel needed power and control in or-der to work. These two required inputs were modeled as two boolean input ports, has_power andhas_control. Figure 5.3 shows the state machine diagram of the reaction wheel. It shows that aslong as it had power and control the component stayed in the base state. When one of the requiredinputs was false, it moved into the dead state. In this state it no longer worked.

5.2.5. ADCS ComputerThe ADCS computer component had five input ports. One power port, has_power, two gps input ports,gps1_reading and gps2_reading, and two IMU input ports, imu1_reading and imu2_reading.The computer had one output port, rw_control, indicating whether the computer was able to controlthe reaction wheels. Figure 5.4 shows the IBD of the ADCS computer. Notice that the output port,rw_control, has two flows connected to it. The value of the output port was false if the state ofthe component was dead and equal to the power input port if the state was ok. Note that the statecondition on the flows are not visible in the figure but were modeled in the model. The two mentionedstates, ok and deadwere the two possible states of the component. The state machine of the computercomponent is shown in Figure 5.5. The states and all possible state transitions are shown.

An evaluation is made each time step. The ADCS component moved into the dead state when

70 5. ADCS Case Study

Figure 5.2: State machine of the GPS component

Figure 5.3: State machine of the reaction wheel component

5.2. Modeling the Nominal System 71

Figure 5.4: IBD of the ADCS computer component

both GPS sensors or both IMU sensors or the power failed. This was done by the three transitionsgoing from the ok state to the dead state. The other two transitions were needed to reset the timer,preventing it from growing unbounded.

5.2.6. The ADCS SystemThe system component houses all the components defined in the previous subsections. The IBD ofthe system is shown in Figure 5.6. The layout of the subcomponents corresponds to the layout shownin Figure 5.1 presented in the overview section of this chapter.

Power connections from the EPSs are indicated by yellow connections. Data connections are mod-eled by green connections. The figure shows no direct connection between the computers and thereaction wheels. This information flow was modeled using flows. Both reaction wheels had a controlinput when either the master or the slave computer was able to output control.

The flow placed at the bottom of the figure was connected to the is_working output port. Thisport indicated whether the system was able to control the attitude. The logic was modeled using theconnected flow element. As in a normal system, at least one reaction wheel needed to work for thewhole system to work.

Figure 5.6 also shows an output port for each subcomponent instance on the right side of the figure.These output ports conveyed working information about each subcomponent. These ports were usedto connect this information to the CDHS. This is described in the next two subsections.

5.2.7. CDHSThe FDIR_CDHS component wasmodeled as an FDIR component. It monitored the system and reactedby activating alarms. Figure 5.7 shows the IBD of the component. All the input ports are shown onthe left side. These input ports correspond to the output ports of the system component which outputthe working state of the subcomponents. All the alarms are shown on the right side of the figure. 10alarms were defined for the component:

1. alarm_master_computer was triggered if the master computer input signal was false.

2. alarm_slave_computer was triggered if the slave computer input signal was false.

3. alarm_eps was triggered when one of the two EPS input signals was false.

4. alarm_eps1 was triggered when the eps1_working input signal was false.

5. alarm_eps2 was triggered when the eps2_working input signal was false.

6. alarm_rw1 was triggered when the wr1_working input signal was false.

72 5. ADCS Case Study

Figure 5.5: State machine of the ADCS computer component

7. alarm_rw2 was triggered when the wr2_working input signal was false.

8. alarm_imu was triggered when one of the two IMU input signals was false.

9. alarm_gps was triggered when one of the two gps input signals was false.

10. alarm_save_state was triggered when the component was in the save_state state.

The first nine alarms were directly related to one or two input port values. This was modeled usingflows. The tenth alarm was activated when the save_state state was reached. Figure 5.8 showsthe state machine diagram of the FDIR_CDHS component. Two states were modeled. The initial basestate and the save_state state. The tenth alarm, alarm_save_state, was activated in the laststate. This state is a state when the spacecraft is set in save mode because a critical error occurred.In this mode, the spacecraft tries to recover from this error. Normal measurements are postponed untilthe error has been fixed. In the model, the component reached this save_state state when one ofthe computers or one of the EPS components failed to work. This normally puts the system in a criticalstate. The recovery procedure to exit this state was not modeled however. Modeling the recoveryprocedure was tried, but this illustrated the limitations of the SSTM methodology and tool. This madeit impossible to model this recovering procedure as intended. In order to create a working model thatwas compilable, the SysML was simplified to exclude the recovery procedure.

5.2.8. EnclosureThe last component to be modeled was the Enclosure component. This component encloses the en-tire model making it the root component. Figure 5.9 shows the IBD of the Enclosure. The System andFDIR_CDHS components were the two subcomponents of the Enclosure. The two subcomponentswere connected to each other through the status ports, described in the previous two subsections.

The Enclosure has no behavior therefore a state machine was not modeled for this component.

5.3. Modeling the Error ModelsFive error models were defined for the ADCS system. Each subcomponent in the System componenthad its specific error model. The five error models and the corresponding error injections are described

5.3. Modeling the Error Models 73

Figure5.6:

IBDofthesystem

component

74 5. ADCS Case Study

Figure 5.7: IBD of the CDHS component

5.3. Modeling the Error Models 75

Figure 5.8: State machine of the CDHS component

in this section.

5.3.1. EPS Error ModelThe error model of the EPS was one of the simplest error models. It had two states, ok and dead.The ok state was the initial state. The dead state was the only error state. This state was attained bya single transition. This transition was triggered by the epsFault error event port. Figure 5.10 showsthe state machine diagram of the EPS error model.

The EPS error model was used in the error injection for the EPS component. The EPS componentdid not output power when the error state reached the dead state.

5.3.2. Computer Error ModelThe computer error model was modeled with the same behavior of the EPS error model. However, thetransition to the dead state was triggered by the computerFault error event port.

The error injection in the adcsComputer component used the computer error model as input. Therw_control output port was set to false once the computer error model reached the dead error state.

5.3.3. GPS Error ModelThe initial GPS error model was intended to use timed behavior. The example GPS error model ofBruintjes [7] was used to model the initial GPS error model for the ADCS model. Figure 5.11 showsthe error model by Bruintjes.

The error model had three states. The initial ok state, an error state called hot in the figure andmodeled as dead in the model and a transient state. A transient event can occur that puts the errormodel in the transient state. This can happen when the GPS sensor has no signal from the GPSsatellites, for example when the satellite is spinning. The error model needs to recover from the tran-sient state within a specific amount of time. In the example model, this needed to be done between200 and 300 milliseconds after reaching the transient state. In the ADCS model, an extra transitionwas made from the transient state to the dead state after 300 milliseconds in the transient state.

76 5. ADCS Case Study

Figure5.9:IBD

oftheenclosure

5.3. Modeling the Error Models 77

Figure 5.10: State machine of the EPS error model

Figure 5.11: Simplified gps error model, Bruintjes [7].

A GPS error event also puts the error model into the dead state from the ok state. The activation tran-sition shown in the figure was not modeled in the ADCS model. This was not done due to the fact thatthis functionality was not supported by the first version of the SSTM methodology.

The corresponding SLIM code as presented in [7] was not possible with the SSTM methodology.The timed modeling in the SLIM model were not modeled in version 1.0 of the SSTM methodology andtool. An alternative modeling approach using only clocks was used. Unfortunately the transformedSLIM code of this simplification could not be compiled. More detail on these compilation errors is de-scribed in Section 5.4. The model was adapted to fix these compilation errors. This resulted in anevent-based error model similar to the EPS and computer error model. The transient state wasalso lost in this simplification step because timed behavior for error models is not supported in version1.0 of the SSTM methodology.

The GPS component had an error injection that was triggered when the GPS error model reachedthe dead state. The reading of the GPS component was set to be false.

5.3.4. IMU Error ModelThe first iteration of the IMU error model looked similar to the first iteration of the GPS error model.Only a need for calibration state was used instead of the transient state in the GPS errormodel, described in Subsection 5.3.3. This corresponded to the behavior of an IMU. The IMU errormodel needed the same simplification iterations as the GPS error model described in Subsection 5.3.3.This in the end resulted in an event-based error model the same as for the GPS error model.

78 5. ADCS Case Study

The reading of the IMU component was set to false once the IMU error model reached the deadstate. This was modeled with the error injection.

5.3.5. Reaction Wheel Error ModelThe reaction wheel error model was developed using error probabilities as defined in “Fault-TolerantAttitude Control for Spacecraft Under Loss of Actuator Effectiveness” by Hu et al. [17]. Hu et al.describe that a reaction wheel can suffer from partial loss-of-effectiveness. The reaction wheel doesnot perform as intended and needs to be recovered to be fully functional. The probability for the loss-of-effectiveness is time-dependent and occurs every time after a maneuver has been performed. Hu et alpresent the probabilities for the loss-of-effectiveness in the paper. This equation is shown in Equation5.1 [17].

𝑒 (𝑡) = 0.25, 𝑡 > 5𝑠𝑒 (𝑡) = 0.35, 𝑡 > 8𝑠𝑒 (𝑡) = 0.20, 𝑡 > 10𝑠

(5.1)

This behavior wasmodeled for the first iteration of the reaction wheel error model. Figure 5.12 showsthe state machine of the reaction wheel error model’s first iteration. The probabilities for the loss-of-effectiveness taken from Hu [17] were modeled using three transitions. Two possible transitions fromthe loss of effectiveness state were modeled. One transition leads back to the base state.This transition was activated when the reaction wheel recovered from the loss-of-effectiveness. Thesecond transition was activated after a certain amount of time without recovering. The reaction wheelwas then unable to perform and was set to the dead state.

Figure 5.12: Reaction wheel error model first iteration state machine

Unfortunately this error behavior could not be transformed to compilable SLIM code by the firstversion of the SSTM tool. Similar and new errors were found during the compilation of the code.These compilation errors are discussed in detail in Section 5.4.

The reaction wheel error model was simplified to have two states, the initial ok state and the deaderror state. One event-based transition set the behavior for the error model. When an error eventoccurred the state changed from ok to dead.

The reaction wheel had one error injection from this error model. When the error model reachedthe dead state, the output port of the reaction wheel , working, was set to false.

5.4. Transforming the Model 79

5.4. Transforming the ModelTransforming the SysML model into the SLIM model was performed with the SSTM transformation tool.The first iterations of the model produced SLIM code. However, the COMPASS toolset was unable tocompile the code. This was due to several syntax errors. The encountered errors are listed below:

• An error trigger should aways be modeled for a transition in the error model.

• Clocks in the error model do have a different syntax for defining time steps.

• Clocks need to be reset to 0.

• Transitions with probabilistic trigger event can not have a guard.

These encounter errors were not identified while verifying the model, as described in Chapter 4.The initial complexity of the case study presented in this chapter was higher than the SSTM method-ology and tool were built for. These errors indicate the specific limitations found during compiling themodel. Subsection 5.4.1 to Subsection 5.4.4 describe the encountered error and the improvement forthe SSTM methodology to support the intended modeling capabilities.

The SysML model needed to be simplified to remove the errors. The simplified model was success-fully transformed using the SSTM tool and successfully compiled and analyzed with the COMPASStoolset.

5.4.1. Trigger Required for Error TransitionThe initial error models for the GPS, IMU, and reaction wheel, required triggers from the transient-,need for calibration-, and loss of effectiveness states to the dead state after a certainamount of time. This was first modeled with a guard expression using a clock. After a set time the guardwas satisfied and the transition activated. During the compiling of the SLIM code, the COMPASS toolprompted an error. The error stated that a trigger event was required for an error transition. An errortrigger for all transitions was set, unfortunately this resulted in the incorrect behavior for the timedtransitions. This timed error is discussed in Subsection 5.4.2.

5.4.2. Error ClocksClocks used in error models are modeled slightly differently than clocks in the nominal component.This is not supported in version 1.0 of the SSTM methodology. This resulted in a compilation errorwhere the GPS error model used a clock with the time unit in milliseconds. This was not supportedand only a default clock could be compiled. Other timing features are not supported in version 1.0either. This resulted in incorrect behavior and ultimately the error models needed to be simplified. Thisprocess is described in Section 5.3. Improvements in the SSTM methodology allows the modeling oftimed behavior of error models as it was initially set out. More on these improvements is discussed inChapter 6.

5.4.3. Clock Reset to 0During the modeling of the system a transition was modeled that would reset a clock to a non-zerovalue. This was the case for the modeling of the reaction wheel error model. If the clock had beenreset to 0, the probabilistic events of loss-of-effectiveness would have also been possible due to thewritten guards on these transitions. See Subsection 5.3.5 for more detail. During the modeling atransition was made setting the clock back to 11. This is not a correct SLIM syntax and a syntax errorwas thrown while compiling this code. The solution to this error was to model an extra state where theother probabilistic transitions would not be modeled. This allowed the clock to be reset to 0 without thepossibility of the unintended transitions. This was not modeled in the final error model for the reactionwheel due to other unsupported features described in Subsection 5.3.5.

5.4.4. Transition with Probabilistic Event and GuardThe reaction wheel initial error model used probabilistic error events and guards stating the time periodin which these transitions could be activated. The combination of probabilistic events and guardsfor a transition is not allowed by the SLIM syntax. This could be solved by creating multiple states,

80 5. ADCS Case Study

one for each time interval. For the ADCS case study, a state was created for [𝑡 > 5 && 𝑡 <= 8],[𝑡 > 8 && 𝑡 <= 10], and [𝑡 > 10]. A single probabilistic event based transition to the error state is thenmodeled from each state. This is not modeled the final error model for the reaction wheel due to otherunsupported features described in Subsection 5.3.5.

5.5. ADCS SLIM CodeThe final SysML model was transformed into SLIM code. Listing B.3 in Appendix B shows this SLIMcode. This section takes two component implementations and compares them to the SysML model de-scribed in Section 5.2. The two parts that are presented are the implementation of the adcsComputerand the FDIR_CDHS. These two components have the most complicated behaviors of the system.

5.5.1. SLIM Code of the adcsComputer ComponentListing 5.1 shows the SLIM code for the implementation of the adcsComputer component. The con-nection definition defines two flows both controlling the output of the rw_control port. This behavioris described in Subsection 5.2.5. The states and transition definitions defined were transformed fromthe state machine of the adcsComputer component. The corresponding state machine is shown inFigure 5.5. The last important part of the code is the error injection modeled on lines 17 and 18.1 system implementat ion adcsComputer . Imp2 subcomponents3 delay : data c lock ;4 connect ions5 f low has_power > rw_con t ro l i n modes ( ok ) ;6 f low f a l s e > rw_con t ro l i n modes ( dead ) ;7 s ta tes8 ok : i n i t i a l s t a t e ;9 dead : s t a t e ;10 t r a n s i t i o n s11 ok [ when delay >= 2 and ( gps1_reading or gps2_reading ) and ( imu1_reading or

imu2_reading ) and has_power then delay := 0 ] > ok ; t r a n s i t i o n name :rese t delay ( ok )

12 dead [ when delay >= 1 then delay := 0 ] > dead ; t r a n s i t i o n name : rese tdelay ( dead )

13 ok [ when delay >= 1 and not gps1_reading and not gps2_reading then delay := 0] > dead ; t r a n s i t i o n name : no gps

14 ok [ when delay >= 1 and not imu1_reading and not imu2_reading then delay := 0] > dead ; t r a n s i t i o n name : no imu

15 ok [ when delay >= 1 and not has_power then delay := 0 ] > dead ; t r a n s i t i o nname : no power

16 p rope r t i e s17 ErrorModel => c l a s s i f i e r ( ComputerError . Imp ) ;18 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( rw_con t ro l ) ; E f f e c t =>” f a l s e

” ; ] ) ;19 end adcsComputer . Imp ;

Listing 5.1: adcsComputer component implementation code

5.5.2. SLIM Code of the FDIR_CDHS ComponentListing 5.2 shows the SLIM code for the implementation of the FDIR_CDHS component. Subsection5.2.7 describes the modeling of this component in SysML. Rows 5 to 14 define the flows of this com-ponent and all trigger an alarm, the definition of the alarms is described in Subsection 5.2.7. Thecomponent has one state besides this initial state. This state is the save_state state. In this statethe satellite is in a state where nominal operations are postponed, described in Subsection 5.2.7. Thelast important line of code is on line 23. This line states that the component is an FDIR component.This statement is used by COMPASS to perform FDIR analyzes using this component.1 system implementat ion FDIR_CDHS. Imp2 subcomponents3 delay : data c lock ;4 connect ions5 f low not master_working > alarm_master_computer ;6 f low not s lave_working > alarm_slave_computer ;7 f low not eps1_working or not eps2_working > alarm_eps ;

5.6. COMPASS Analysis and Results 81

8 f low not eps1_working > alarm_eps1 ;9 f low not eps2_working > alarm_eps2 ;10 f low not rw1_working > alarm_rw1 ;11 f low not rw2_working > alarm_rw2 ;12 f low not imu1_working or not imu2_working > alarm_imu ;13 f low not gps1_working or not gps2_working > alarm_gps ;14 f low t rue > alarm_save_state i n modes ( save_state ) ;15 s ta tes16 base : i n i t i a l s t a t e ;17 save_state : s t a te ;18 t r a n s i t i o n s19 base [ when delay >= 1 and master_working and slave_working and eps1_working

and eps2_working then delay := 0 ] > base ; t r a n s i t i o n name : rese t delay( base )

20 base [ go_to_slave when delay >= 1 and ( not master_working or nots lave_working or not eps1_working or not eps2_working ) then delay := 0 ] >save_state ; t r a n s i t i o n name : go_to_save_state

21 save_state [ when delay >= 1 then delay := 0 ] > save_state ; t r a n s i t i o nname : save_state > save_state

22 p rope r t i e s23 FDIR => t rue ;24 end FDIR_CDHS. Imp ;

Listing 5.2: FDIR_CDHS component implementation code

5.6. COMPASS Analysis and ResultsCOMPASS analyzes can be performed with the transformed model. This section shows the analyzesperformed on the ADCS system. The same kind of analyzes were performed as for the battery-sensorsystem described in Chapter 4. Simulation of themodel, fault tree analysis, and FDIR isolation analyzeswere executed. The results can be found in the following three sections.

5.6.1. Simulating the ModelSimulating the model was the first step in testing the system. Figure 5.13 shows part of the trace stackfor a random simulation on the ADCS model. The trace stack shows that after an epsFault, coloredred, the eps1 component did not output power. This event is triggered was the first step.

Figure 5.13: Random simulation stack trace of the ADCS case study

82 5. ADCS Case Study

5.6.2. Fault Tree AnalysisFault tree analysis shows which faults led to a certain failure of the system. The failure of the sys-tem tested in this analysis was whether neither of the reaction wheels were working, defined by the!sys.is_working expression. Probabilities for all possible fault events were modeled. This resultedin the calculation of the probability of system failure. The values used for fault events are shown inFigure 5.14. Note that an error model was used for multiple component instances. The probability of afault event can be set per component instance. This is also done for this analysis. The probability fora epsFault for eps1 was set to 0.01 and the probability for the same error event for eps2 was setto 0.015. The fault tree generated by the analysis is shown in Figures 5.15 and 5.16. The fault treeis split in two figures for readability purposes. The two figures need to be combined to create the longhorizontal fault tree.

Figure 5.14: Probabilities for ADCS fault tree analysis

5.6.3. FDIR Fault Isolation AnalysisFault isolation analyzes were performed to see which fault will triggered selected alarms. This wasdone by FDIR analyzes, which needed an FDIR component. The FDIR_CDHS component is an FDIRcomponent that activate the alarms. This component was used to produce the analyzes presented inthis subsection. The FDIR fault isolation trees do not normally calculate the probability of an alarmbeing activated. Therefore the probability P was set to 0.0.

Figure 5.17 shows the FDIR fault isolation tree for the alarm_eps. The figure shows that two faultscan activate this alarm, the epsFault for eps1 and eps2. This was expected and thus verified thecorrectness of the modeling for this alarm.

Figure 5.18 shows the FDIR fault isolation tree for the alarm_master_computer. This tree ismore complex than that of the alarm_eps alarm. It shows that a fault in eps1 (E1) or a fault in themasterComputer (E7) directly activates this alarm. Four combinations of faults also triggered thealarm, these combinations were:

1. eps2 fault (E2) + gps1 fault (E3).

2. eps2 fault (E2) + imu1 fault (E5).

3. gps1 fault (E3) + gps2 fault (E4).

4. imu1 fault (E5) + imu2 fault (E6).

This fault isolation tree verifies the expected behavior for the activation of the alarm.

Figure 5.19 shows the FDIR fault isolation tree for the alarm_rw1. Two faults directly activatedthe alarm that reaction wheel 1 was not working. These faults are the eps1 fault (E1) and the rw1 fault(E8). Six combinations of faults also activated the alarm. These combinations were:

1. eps2 fault (E2) + gps1 fault (E3).

2. eps2 fault (E2) + imu1 fault (E5).

3. eps2 fault (E2) + masterComputer fault (E7).

5.6. COMPASS Analysis and Results 83

Figure5.15:A

DCSfaulttreefora

failedsystem

,part1

84 5. ADCS Case Study

Figure5.16:AD

CSfaulttree

forafailed

system,part2

5.6. COMPASS Analysis and Results 85

cdhs.alarm_eps

fault_cfg_1 fault_cfg_2

sys.eps1._errorSubcomponent.__epsFault

E1

P = 0.0

sys.eps2._errorSubcomponent.__epsFault

E2

P = 0.0

Figure 5.17: FDIR fault isolation tree for alarm alarm_eps

4. gps1 fault (E3) + gps2 fault (E4).

5. imu1 fault (E5) + imu2 fault (E6).

6. masterComputer fault (E7) + slaveComputer fault (E10).

This also verifies the intended behavior of this alarm.

The last figure, Figure 5.20, shows the FDIR fault isolation tree for the alarm_save_state. Fourfaults directly activate this alarm;

1. eps1 fault (E1)

2. eps2 fault (E2)

3. masterComputer fault (E7)

4. slaveComputer fault (E10)

Two combinations of fault also activated the alarm:

1. gps1 fault (E3) + gps2 fault (E4).

2. imu1 fault (E5) + imu2 fault (E6).

An active alarm_save_statemeans the FDIR_CDHS component reached the save_state state.The fault isolation thus also shows the fault that puts the system in this mode. The result verifies thatthis is correct.

86 5. ADCS Case Study

cdhs.a

larm

_maste

r_computer

fau

lt_cfg_2

fau

lt_cfg_4

fau

lt_cfg_3

fau

lt_cfg_5

fau

lt_cfg_1

fau

lt_cfg_6

sys.eps2._errorS

ubcom

ponent.__ep

sFault

E2

P =

0.0

sys.gps1._errorS

ubcom

ponent.__g

psF

ault

E3

P =

0.0

sys.eps2._errorS

ubcom

ponent.__ep

sFault

E2

P =

0.0

sys.imu1._errorS

ubcom

ponent.__im

uF

ault

E5

P =

0.0

sys.gps1._errorS

ubcom

ponent.__g

psF

ault

E3

P =

0.0

sys.gps2._errorS

ubcom

ponent.__g

psF

ault

E4

P =

0.0

sys.imu1._errorS

ubcom

ponent.__im

uF

ault

E5

P =

0.0

sys.imu2._errorS

ubcom

ponent.__im

uF

ault

E6

P =

0.0

sys.eps1._errorS

ubcom

ponent.__ep

sFault

E1

P =

0.0

sys.masterC

omputer._errorS

ubcom

pon

ent.__com

puterF

ault

E7

P =

0.0

Figure5.18:FD

IRfaultisolation

treeforalarm

alarm_master_computer

5.6. COMPASS Analysis and Results 87

cdh

s.ala

rm_r

w1

fau

lt_c

fg_2

fau

lt_c

fg_4

fau

lt_c

fg_6

fau

lt_c

fg_3

fau

lt_c

fg_5

fau

lt_c

fg_8

fau

lt_c

fg_1

fau

lt_c

fg_7

sys.eps2._errorSubcomponent.__epsF

ault

E2

P =

0.0

sys.gps1._errorSubcomponent.__gpsF

ault

E3

P =

0.0

sys.eps2._errorSubcomponent.__epsF

ault

E2

P =

0.0

sys.imu1._errorSubcomponent.__imuF

ault

E5

P =

0.0

sys.eps2._errorSubcomponent.__epsF

ault

E2

P =

0.0

sys.masterCom

puter._errorSubcompon

ent.__computerFault

E7

P =

0.0

sys.gps1._errorSubcomponent.__gpsF

ault

E3

P =

0.0

sys.gps2._errorSubcomponent.__gpsF

ault

E4

P =

0.0

sys.imu1._errorSubcomponent.__imuF

ault

E5

P =

0.0

sys.imu2._errorSubcomponent.__imuF

ault

E6

P =

0.0

sys.masterCom

puter._errorSubcompon

ent.__computerFault

E7

P =

0.0

sys.slaveC

omputer._errorSubcompone

nt.__computerFault

E1

0

P =

0.0

sys.eps1._errorSubcomponent.__epsF

ault

E1

P =

0.0

sys.rw

1._errorSubcomponent.__rw

Fau

lt E8

P =

0.0

Figure5.19:F

DIR

faultisolationtreeforalarm

alarm_rw1

88 5. ADCS Case Study

cdh

s.ala

rm_sa

ve_sta

te

fau

lt_cfg_3

fau

lt_cfg_4

fau

lt_cfg_1

fau

lt_cfg_2

fau

lt_cfg_5

fau

lt_cfg_6

sys.gps1._errorS

ubcom

ponent.__g

psF

ault

E3

P =

0.0

sys.gps2._errorS

ubcom

ponent.__g

psF

ault

E4

P =

0.0

sys.imu1._errorS

ubcom

ponent.__im

uF

ault

E5

P =

0.0

sys.imu2._errorS

ubcom

ponent.__im

uF

ault

E6

P =

0.0

sys.eps1._errorS

ubcom

ponent.__ep

sFault

E1

P =

0.0

sys.eps2._errorS

ubcom

ponent.__ep

sFault

E2

P =

0.0

sys.masterC

omputer._errorS

ubcom

pon

ent.__com

puterF

ault

E7

P =

0.0

sys.slaveCom

puter._errorS

ubcom

pone

nt.__com

puterF

ault

E1

0

P =

0.0

Figure5.20:FD

IRfaultisolation

treeforalarm

alarm_save_state

6Discussion and Roadmap

With the SSTM methodology and transformation tool developed, tested and verified in this thesis, sim-ple up to complex component-based SysML models can be transformed into SLIM models.

In addition to the testing and verification, limitations and improvements for both the methodologyand the tool have also been identified. These improvements are presented in this chapter.

The Sections 6.1 to 6.15 discuss in detail the identified limitations and improvements. Section 6.16provides a roadmap for improvements to the SSTM methodology and transformation tool, which areranked based on importance.

With the improvements discussed in this chapter the second sub-research question can be an-swered. This is presented in Section 6.17. With the second sub-research question answered in thischapter and the first one in CHapter 4, the main research question can be answered. The answeringof the main research question is presented in Section 6.18.

6.1. Option to Select Physical Nodes for TransformationCurrently, in version 1.0 of the SSTM tool, the entire SysML model is transformed at once. Eachelement typified with a SLIM component stereotype is transformed and saved in the created SLIMfile. For simple models, containing only a single physical node, this is not a big problem. However,with larger models it is not always desirable to transform the entire model. For example, if only onesubsystem of a spacecraft needs to be analyzed and not every subsystem.

Adding a selection option, to select one or multiple physical nodes to be transformed, advances thetransformation tool. Such an improvement needs to go hand in hand with the automatic creation of anenclosure component, as described in Section 6.2. This improvement eases the logic needed to selectonly a subset of the components to be transformed.

6.2. Automatic Creation of an Enclosure ComponentAn enclosure component is needed in SLIM code. This allows the COMPASS tool to have a singleentry point to perform analysis on the model. In version 1.0 of the transformation tool the modelerneeds to manually model such a component. In practice this is always the only direct child part of aphysical node.

Adding a feature to the transformation tool that automatically creates this enclosure component,improves the SysML model quality. Unnecessary elements do not need to be created in the SysMLmodel. Making it more consistent with the actual spacecraft and more readable by systems engineers.The automatically created enclosure component needs to be typified with the «System» stereotype.

6.3. Automatic Direction Detection for ConnectionsConnections between ports of a component need to be created in a specific way, the source portalways need to be selected first, followed by the target port. This is not a very big problem, except thatno visual indication is given once the connection is created. This makes it almost impossible to verifyif a connection is created in the right direction.

89

90 6. Discussion and Roadmap

Automatic detection in the transformation tool of the direction of a connection, solves this problem,making the modeling, using the SSTM methodology, less error prone. If this feature is present in thetool then the direction of the connection in the SysML model is not of importance.

The supposed direction of a connection can be determined by looking to the direction of the source-and target port of the connection. Three connections are possible:

1. From an in port of the component to an in port of a subcomponent

2. From an out port of a subcomponent to an in port of another subcomponent

3. From an out port of a subcomponent to an out port of the component

These options are unique allowing the direction of the connection to be determined automatically.

6.4. Removing Shallow References in Multiple Modeling ElementsIn version 1.0 of the SSTM tool, multiple elements use shallow references to other elements. A shallowreference is a reference to a subcomponent for example that does not linking to the element with anID but only by name. This happens when creating guards, effects, and flows. An expression is usedto model specific information. The name of the referenced element is used here which has no otherinformation about the referenced element. Multiple errors and limitations are introduced at this point.Misspelling a name of an element results in an error once the transformed SLIM code is loaded in theCOMPASS tool. Working with shallow references also means that once an element changes its name,all shallow references to this element have to be changed manually. This problem is one of the bigadvantages of MBSE and therefore important to improve on.

Removing all shallow references out of SSTM is one of the biggest and complicated improvementpoints, which is a time-consuming process. The current approach of shallow references was chosento limit the development time of the modeling elements using shallow references.

6.5. Creating Custom Stereotypes for Flows and ConnectionsFlows and connections have the ability to be active in specific modes and not active in other modes. Inversion 1.0 of SSTM this can be modeled by adding an owned comment to the flow or connection. Linksin this owned comment refer to states of the component to which the flow or connection belongs to.This information is used in the transformation tool. The disadvantage of this method is that commentsare used to model a structure, for which they are not designed for. In version 1.0, this strategy waschosen to limit the development time.

Creating custom stereotypes for flows and connections removes the need for comments to typify inwhich modes these elements are active. A property in these stereotypes allows the modeler to selectthe states of the model, where the flow or connection is active. This has another advantage, besidesnot misusing comments. The property can be set to only accept states, this guides the modeler to onlyselect state elements. In the current situation any element can be referred.

6.6. Using Multiplicity in Part AssociationPart associations are created to define subcomponents. If multiple instances of the same componentare a subcomponent of another component then multiple part associations need to be created, one foreach instance.

Using multiplicity in part associations improves the methodology. This is the default way of modelingmultiplicities in SysML. From a systems engineering point of view this would be the preferred way ofmodeling multiple identical subcomponents.

Investigations to implement the option for usingmultiplicity in part associations were performed. Thisshowed that the IBD of the parent component, having multiple instances of a subcomponent createdusing a multiplicity in the part association, does not show multiple instances but set the multiplicity ofthat instance to themultiplicity modeled in the part association. This does not allow themodeler to makedifferent connections with the parent component or other subcomponents for each instance. Modelingwith more than one part association resulted in multiple instance in the IBD of the parent component.Therefore the second option was chosen, deviating from the preferred SysML modeling process, infavor of less development time.

6.7. Using Constraints for Modeling Flows 91

When this point has be improved, future modelers will be well advised to first look how multipleinstances of a subcomponent can be present in the IBD of the parent component, once multiplicity inthe part association is used. This is the most important factor for this improvement point.

6.7. Using Constraints for Modeling FlowsFlows are currently modeled using comments. This again misuses the comments. The same reasonapplies to this compromise as for the other uses of comments, reducing development time.

Using constraints elements to model flows is more in line with SysML modeling. Flows are expres-sions connected to ports, constraints are used to model expressions and are a better modeling elementfor flows. This improvement has close correlation with the improvement to create custom stereotypesfor flows and connections, described in Section 6.5. Changing the modeling element for flows has aninfluence on the custom stereotype created to type the constraint as a flow.

6.8. Data ComponentsAdding data components to the SSTM methodology drastically improves the methodology. It allowsthe modeling of complex space systems. Data components are special components in SLIM. Datacomponents only have other data subcomponents, unlike normal SLIM components. Version 1.0 doesnot support the creation of data components. In the ADCS case study, this limited the creation of someneater modeling constructions whereby the System and FDIR_CDHS components were connected toeach other via multiple status ports. Each status ports conveyed information from the System com-ponent to the FDIR_CDHS component about the status of a single subcomponent in the System com-ponent. This resulted in a total of 10 individual ports per component and 10 individual connectionsconnecting these ports.

When data components are supported by the SSTM methodology, these 10 ports and connectionscould be substituted by a single port for the system and FDIR_CDHS component. Also only a singleconnection, connecting these ports, is then required. This greatly increases the readability of themodel.

Not only bus-like data bundles, like the one above, can be modeled using the data component.Vectors can also be modeled using a data component. In the current version of the SSTMmethodologya port for each dimension of the vector needs to be created. For an IMU six ports need to be created.Three angular velocity ports, one for each spatial dimension, and three acceleration ports, again onefor each spatial dimension.

A data component can be created for the angular velocity and for the acceleration. This reducesthe number of ports from six to two.

6.9. Bus-Modeling Using Data ComponentsThe next step to improve the SSTM methodology to model complex space systems is to model busesusing complex data component, such as described in Section 6.8.

Spacecraft subsystems and components in each subsystem connect to a central bus to obtainrequired data. This data is added by other components. Adding this functionality to SSTM is a bigpoint of improvement allowing more advanced modeling of spacecraft systems.

It is important to define a detailed concrete method on modeling buses. This will strengthen themethodology for space related modeling work.

6.10. Deactivating and Reactivating ComponentsSLIM allows components to be deactivated and reactivated. Using this concept, components can bemodeled that return to a specific state. This corresponds to reseting a component.

Adding the de- and reactivation of components to the SSTM methodology allows the modeling ofcomponents and systems that can be reset. An essential feature for the modeling of space systems.

6.10.1. Adding an Activation StateA SLIM component having states needs to have exactly one initial or activation state. An initialstate is the state the component starts with, after deactivation and reactivation it is not reset to this

92 6. Discussion and Roadmap

state. If an activation state is set for the component, then that state is the state the component startsin after every activation.

When deactivation and reactivation is added to the methodology, the ability to model activationstates is also required.

6.11. Generic PropertiesProperties are modeled in SLIM and used by the COMPASS toolset for several analyzes. Patternproperties are already supported by version 1.0 of the SSTM methodology. They are used to modellogical properties which can be tested by the COMPASS tool.

Generic properties are also frequently used for COMPASS analyzes. The fault tree generation forexample uses a generic property to generate the fault tree. Currently, this generic property needs tobe created in the COMPASS toolset. If the model changes, the property needs to be recreated usingthe toolset.

Generic properties, like pattern properties, can be saved in the SLIM model. Adding the feature tomodel generic properties in the SysML model, which are automatically saved in the generated SLIMmodel, eases the analyzing steps, especially if the model is updated iteratively.

Adding this functionality is a relatively small task. The same principle for modeling and transformingpattern properties can be used. A custom stereotype needs to be created in the profile. The customstereotype needs to extend the property metaclass. Modeling a generic property is the same as mod-eling a pattern property and is done by adding a property to a nominal mode and typifying it with thegeneric property stereotype.

6.12. Better Timing Modeling CapabilitiesVersion 1.0 of the SSTM methodology supports the modeling of basic timed behaviors. The SLIMlanguage has more timing capabilities that are not yet supported by the SSTM methodology. Addingthese timed behaviors to nominal and error models is of great importance for the usability to model andanalyze space systems.

In order to add this feature to the SSTM methodology, a case study to verify the feature addition isrecommended. One of the more detailed examples from the COMPASS project that can be used forthis case study is the GPS example. The GPS model described by Hu et al [17] is also a recommendedexample to be used for this case study.

6.13. Adding Reset Events to Error ModelsError injections change elements in the nominal model when a certain state in the error model isreached. This can be seen as information being transfered from the error model to the nominal model.The reset event is an event that can be triggered by the nominal model and, if used, it changes thebehavior in the error model. The reset event thus conveys information from the nominal mode to theerror model.

Adding the reset function to the SSTM methodology would allow the modeler to model temporaryerrors which the system can recover from. This would open a vast array of new systems and behav-iors that can be modeled thus improving the modeling of complex space systems, which often use thereseting behavior.

Adding this feature has a moderate complexity. The SLIM code needed for this feature is not asextensive as other features. However, this feature adds code to the error model as well as the nominalmodel. Both need to be modeled in SysML and need to be transformed.

6.14. Adding Error PropagationError propagations communicate error events to other components. This is used to model errors thatrespond to each other. Error propagation is currently not supported by the SSTM methodology.

Adding error propagation would allow the modeling of systems with complexer error models, in-creasing the systems that can be modeled using the methodology. Therefore an important improve-

6.15. Support All SLIM Components 93

ment to support a vast array of modeling capabilities.

6.15. Support All SLIM ComponentsThe first iteration of the SSTM methodology supports a subset of SLIM components. Subsection3.6.1gives an overview of the supported components for the first version of the SSTMmethodology. Improve-ment point 6.8 describes the support of the data component. This component is different comparedto other components. Therefore the implementation is a separate improvement point. The remainingcomponents that need to be supported are:

• Thread

• Network

• Node

• Subject

• Abstract

These five components need to be supported by the final version of the SSTMmethodology. Addingthese components is easier than adding the data component and are therefore combined.

6.16. Improvements RoadmapAdding the planned features described in the previous sections all at once would take a significantamount of time and effort. Prioritizing the improvements allows the SSTM methodology to be improvedin several stages. In Subsection 6.16.1 the prioritization of the improvements is discussed. Subsec-tion 6.16.2 provides the different stages that are recommended. Each stage contains a subset of theimprovements.

6.16.1. Prioritizing ImprovementsAll the improvements are scored by two factors. The first factor is the simplicity of the improvement.Some improvements are easy to implement, others are complex and need more effort and time. Thesecond factor is the value for space engineering of the improvement. Some improvements have lowadditional value. Other improvements are needed directly to model correct space systems, these im-provements are scored high for the value factor.

Each improvement is scored from 1 to 5 for both factors. The higher the score, the simpler toimplement or the more value the improvement has. The result is shown in Table 6.1.

6.16.2. Improvement StagesFour improvement phases have been identified. The first phase contains the most urgent improve-ments, improvements that are either simple to implement or have a high value for the user. Eachimprovement phase following contains improvement points slightly less urgent than the phase before.

Improvement phase 1 The four most important improvement points are scheduled for the first im-provement phase. These improvement points are:

• 6.8 Data Components

• 6.12 Better Timing Modeling Capabilities

• 6.13 Adding Reset Events to Error Models

• 6.11 Generic Properties

The first three improvement points, Improvements 6.8, 6.12, and 6.13, all have the highest valuescore. These three are essential for modeling spacecraft systems at a desired level and must beimplemented in the SSTM methodology as soon as possible.

The last improvement, Improvement 6.11, adds generic properties modeling to the SSTM method-ology. This improvement is not as valuable for the modeling process, but saves a lot of time while

94 6. Discussion and Roadmap

Table 6.1: SSTM improvement scoring

Improvement Simplicity Value Total6.1 Option to Select Physical Nodes for Transformation 3 2 56.2 Automatic Creation of an Enclosure Component 4 3 76.3 Automatic Direction Detection for Connections 3 4 76.4 Removing Shallow References in Multiple Modeling Elements 1 4 56.5 Creating Custom Stereotypes for Flows and Connections 4 2 66.6 Using Multiplicity in Part Association 1 3 46.7 Using Constraints for Modeling Flows 3 4 76.8 Data Components 3 5 86.9 Bus-Modeling Using Data Components 3 4 76.10 Deactivating and Reactivating Components 3 4 76.11 Generic Properties 5 4 96.12 Better Timing Modeling Capabilities 2 5 76.13 Adding Reset Events to Error Models 3 5 86.14 Adding Error Propagation 3 3 66.15 Support All SLIM Components 3 4 7

analyzing the system. It is also the easiest improvement to implement and has therefore been includedin the first improvement phase.

Improvement phase 2 The improvements for phase 2 are:

• 6.2 Automatic Creation of an Enclosure Component

• 6.3 Automatic Direction Detection for Connections

• 6.9 Bus-Modeling Using Data Components

• 6.10 Deactivating and Reactivating Components

• 6.14 Adding Error Propagation

• 6.15 Support All SLIM Components

These improvement points all are relatively easy to implement into the SSTMmethodology and providea relative high added value to it. They are therefore included in the second improvement phase.

Improvement phase 3 The improvements for phase 3 are:

• 6.1 Option to Select Physical Nodes for Transformation

• 6.5 Creating Custom Stereotypes for Flows and Connections

• 6.7 Using Constraints for Modeling Flows

These improvement points all add minor features to the SSTM methodology. The changes are im-provements on current modeling steps to better conform to SysML modeling standards and to makethe methodology more robust. These improvements do not have top priority and are therefore placedin the third improvement phase.

Improvement phase 4 The last improvement phase consists of two improvement points. They areput in the last phase because the are hard to implement in the SSTM methodology. The last improve-ment points are:

• 6.4 Removing Shallow References in Multiple Modeling Elements

• 6.6 Using Multiplicity in Part Association

6.17. Answering Second Sub-Research Question 95

Both improvement points need a different method of modeling regarding the referred elements inSysML. The specific function required for modeling the references and the multiplicity are not present ortoo simple in SysML. Therefore, new SysMLmodeling elements need to be added to properly model theimprovements. This is an extremely difficult and time-consuming task. Due to this the two improvementpoints are included in the last improvement phase.

6.17. Answering Second Sub-Research QuestionThe second sub-research question, Which improvements to the minimal transformationwill allow a full model to model transformation?, is answered in this section. Thework presented in Chapters 4 and 5 identified a set of improvement points, all presented in this chapter.

Some of the mentioned improvements are missing functionalities of the first version of the SSTMmethodology. The improvements describing the missing features are:

• 6.8 Data Components

• 6.9 Bus-Modeling Using Data Components

• 6.10 Deactivating and Reactivating Components

• 6.11 Generic Properties

• 6.12 Better Timing Modeling Capabilities

• 6.13 Adding Reset Events to Error Models

• 6.14 Adding Error Propagation

• 6.15 Support All SLIM Components

6.18. Full Model to Model TransformationVersion 1.0 of the SSTM methodology is not able to fully transform a SysML model into a SLIM model.The minimal capabilities are described in Chapter 3 and verified in Chapter 4. The improvement points,described in this chapter, are needed to add missing functionality to the SSTM methodology. If all theimprovements are incorporated in the SSTM methodology then a full model to model transformationbetween SysML and SLIM is possible. Answering the main research question: Is it possible toachieve a full model to model transformation between SysML and SLIM?.

7Conclusion and Recommendations

This chapter is divided into two sections. Section 7.1 presents the conclusion of this thesis. Section7.2 presents the recommendations for the continuation of the work of this thesis.

7.1. ConclusionThe goal of this thesis was to develop, verify, and test the SysML to SLIM Transformation Methodology(SSTM). This SSTM methodology fills the void between systems engineering architectural modelingand software engineering modeling. The methodology holds steps to model a system in SystemsModeling Language (SysML). This SysML model is automatically transformed into a System-Level In-tegrated Modeling (SLIM) model using the newly developed transformation tool. The generated SLIMcode can, without any additional effort, be compiled and analyzed using the Correctness, Modeling andPerformance of Aerospace Systems (COMPASS) toolset.

The SysMLmodel should bemodeled in Papyrus. Therefore, a custom SSTM profile was developedfor the modeling. Stereotypes defined in the SSTM profile were used to typify the elements of thesystem, adding the required information to the SysML model. The SysML model was loaded in theSSTM transformation tool, which automatically generated SLIM code, by using the information addedby the SSTM profile.

The profile, required modeling method, and transformation tool of which the SSTM methodology isbuilt, were developed from scratch. The modeling method and profile are based on the Object-OrientedSystems Engineering Method (OOSEM) method. This provided a strong engineering background forthe modeling method. The newly created modeling steps were created for the systems engineer,making it possible to model the architectural model without much programming and software knowledgeand experience.

The transformation tool is a stand-alone program. Absolutely no programming or software knowl-edge or experience is need to transform the SysML model, thus making it useful for any systemsengineer.

The generated model can be imported and analyzed in the COMPASS toolset without any modifica-tions, bringing the ability to analyze and verify any system early in the design phase to all systems en-gineers independently of software knowledge. This brings Model-Based Systems Engineering (MBSE)and Model Based Embedded Software Engineering (MBESE) closer together and ultimately reducingdevelopment time and costs for space systems.

The verified SSTMmethodology was verified in seven requirements categorized in three categories:

1. SSTM modeling method related requirements:

1.1. SSTM shall provide a profile that will be used to model systems with the SSTMmethodology.1.2. SSTM shall give modeling steps, interpretable by a systems engineer, to model component-

based systems.

97

98 7. Conclusion and Recommendations

1.3. SSTM shall give modeling steps, interpretable by a systems engineer, to model timed be-havior modeling for the system of interest.

1.4. SSTM shall give modeling steps, interpretable by a systems engineer, to model event-basederrors.

1.5. SSTM shall give modeling steps, interpretable by a systems engineer, to model injection oferrors in the nominal model.

2. SSTM transformation tool-related requirement:

2.1. The SSTM transformation tool shall be able to automatically transform SysMLmodels, madeusing the SSTM profile and method, into compilable SLIM models.

3. COMPASS result related requirement:

3.1. The results from the COMPASS toolset shall enable the refinement of the SysML model.

The verification was done by modeling a battery-sensor system using the SSTM methodology. Allseven requirements for the verification of the SSTM methodology were satisfied.

A second, more complex space related case study, system was modeled. This case study modeledthe Attitude Determination and Control System (ADCS) subsystem of a satellite. Modeling this com-plex ADCS system using the SSTM methodology identified important improvement points for the saidmethodology. The case study proved that the SSTM methodology was able to model and transform aspace related model.

The improvement points identified while verifying the SSTM methodology using the battery-sensorsystem, and modeling the case study, were scored based on simplicity to implement and added valueto the SSTM methodology. These two factors together determined the importance of the improvement.

Four improvement stages were established categorizing all improvement points in improvementstages. The first, most important, improvement stage has four improvements:

• 6.8 Data Components

• 6.11 Generic Properties

• 6.12 Better Timing Modeling Capabilities

• 6.13 Adding Reset Events to Error Models

These four improvements are vital improvements for the SSTM methodology. Once these fourimprovements are added to the SSTM methodology, modeling of complex space systems can be doneusing the SSTM methodology.

7.1.1. Answering Research QuestionThe primary research question to be answered is: “Is it possible to achieve a full model to model trans-formation between SysML and SLIM?”. This thesis shows that it is possible to develop, verify, and testa model to model transformation between SysML and SLIM. This transformation is possible using thedeveloped SSTM methodology and the transformation tool. However, it also shows that a full transfor-mation is currently not possible. Improvement point were identified that, once incorporated, will allowfull model to model transformation.

7.2. RecommendationsThe SSTM methodology is able to model and transform simple-component based systems with event-based error models. However, complex systems are not yet supported by the SSTM methodology.

7.2. Recommendations 99

7.2.1. Recommendations for the Improvement Process of SSTMImprovements that enable the SSTM methodology to model complex systems have been described.Four improvement stages are needed to implement all improvements. The first stage is the mostimportant stage. These improvements need to be added to the SSTMmethodology and transformationtool.

Several skills and experiences are required to implement these changes:

1. Strong understanding of systems engineering.

2. Strong understanding of Model-Based Systems Engineering (MBSE).

3. Years of experience in programming and software engineering, specifically objected orientedprogramming.

4. Strong understanding of space systems.

It is recommended that researchers implementing the improvement points in the SSTMmethodologyhave the skills and experience described above. These requirements are the minimum requirementsto efficiently continue the SSTM project.

7.2.2. Solving theGapBetweenCOMPASS and TheAutomated proof-basedSys-tem and Software Engineering for Real-Time applications (ASSERT) Set ofTools for Engineering (TASTE)

During the Model-Based System and Software Engineering - future direction workshop held by Eu-ropean Space Agency (ESA) on December 8th 2016 [19] two main gaps were identified surroundingCOMPASS. This thesis proposes a solution for the first gap between SysML and SLIM/COMPASS.The second gap identified is between COMPASS and TASTE. The former uses SLIM models and thelatter Architecture Analysis & Design Language (AADL) models.

Solving the second gap might be possible by developing an addition to the SSTM methodologyand transformation tool that makes it possible to generate AADL models. This will connect both tools,COMPASS and TASTE, to a central systems engineering model. Utilizing both tools to their full extend.

This future step is a big improvement where besides systems engineering and software engineer-ing knowledge more cooperation between embedded software engineering is needed to successfullydevelop such a proposed addition.

ASSTM SysML Modeling Steps

This chapter gives detailed steps to model a SysML model that can be transformed using the SSTMtool into SLIM models using the SSTM tool.

A.1. Creating a New Project and Adding an SSTM ProfileThe first step is to create a SysML 1.4 project I Papyrus and add the SSTM profile to it. This is doneusing the following steps.

1. Import SSTM profile to the workspace.

2. New Papyrus project -> SysML 1.4.

(a) Naming the model is advised.(b) Only one model per project is supported.

3. Add SSTM profile to root element.

(a) In the profile properties tap of the root element add the profile.(b) Select all the packages in the profile to be added.

A.2. Create Starter PackageStructure Following anAdaptedOOSEMStrategy

The second thing to do is create the package structure. An adapted OOSEM structure is used to keepthe modeling directory as clean as possible.

1. Make “model” package in rootElement.

2. Create model organization “package” diagram in model package.

3. Create “Model Domain-to-be” and “Value Type” packages in model.

4. Create more inner packages for Model Domain to-be, according to OOSEM:

• Operational– System

⋄ 1-Black Box Specification· 1-Requirements· 2-Structure

⋄ 4-Node Physical Design· 1-Structure· 2-Behavior

101

102 A. SSTM SysML Modeling Steps

A.3. Create Black Box Specification and Node Block Definition Di-agram (BDD)

The first modeling blocks for the system are the Black Box Specifications and the systems node physicaldesign overview.

1. Create black box of system (BDD) in “Model Domain to-be/Operational/System/1-Black Box Specifications/2-Structure”, give it the «system of interest» stereotype.

2. Create BDD in “Model Domain to-be/Operational/System/4-Node Physical Design/1-Structure” todefine all nodes, begin with importing Black Box specifications and make a generalization fromit called the system node Physical. The black Box Specification block can be dragged from themodel explorer (on the left side) to the diagram, an arrow is displayed in the corner of the blockwhen it is imported from another package than the package of the diagram. This block will houseall the different nodes. Give this imported Black Box block the stereotype «system of interest» aswell.

A.4. Create Value TypesCreate a BDD in the Value type package. This diagram is used to view all value types of the project.At least one value type needs to be created for the SSTM methodology. This is a block with the Signalstereotype added to it, used to type event ports. For the battery example an enumeration for the Systemmode selector was created as well with three literals: Primary, Secondary1, and Secondary2. Literalscan be added in the property window of the enumeration.

A.5. Create Node Specific Package StructureFor each node a package is created in the 4-Node Physical Design package following this structure foreach node:

• Node name

– 1-Requirements– 2-Structure

⋄ 1-Hardware⋄ 2-Software⋄ 3-Utility

· Clocks⋄ 4-Errors

A.6. Node BDD1. For each node, create a BDD Node Physical Decomposition diagram in the 2-Structure folder.

The base element in the diagram is the «nodephysical» block created before, see second pointin Section A.3.

2. The node BDD allows the modeler to model all elements of the node. Ordering each elementin the correct package, hardware, software, utility or error, keeps the node package clean andorganized.

3. Part associations can be used to make subcomponents for elements. In the battery example twosensors, two PSUs, and one bus are all a subcomponent of the system element. All modeledusing part associations. The name of the members end of the association determines the nameof the subcomponent in the parent element.

4. In order to analyze themodel using COMPASS an enclosing element needs to be the root elementfor a node. In the battery example the enclosing element is named Enclosure. The Enclosureelement holds the system and a FDIR monitor.

A.7. Creating Nominal Elements 103

5. Clocks can also be created and stored in the 3-Utility/clocks package. Other elements can havepart associations to these clocks. Each clock instance will be transformed into a clock subcom-ponent in the SLIM model.

A.7. Creating Nominal ElementsElements are created in the node BDD. Part associations are used to determine subcomponents foreach element. A Internal Block Diagram (IBD) needs to be created for each element. The IBD is used tocreate ports of the element, import subcomponents, connect ports, and create flows. A StateMachineDiagram is used to model the behavior of the element. The behavior is modeled using states andtransitions, which can reference to other modeling elements. Both the IBD and the StateMachinediagram modeling steps are described below.

A.7.1. Element IBDThe Internal Body Diagram of the element models the structure of the element or component to be.The outside visible structure as well as the inside structure is modeled using the IBD.

Creating PortsPorts are used to convey data or event in or out of the element. Flow ports are used for this purpose.The data type of the port determines whether the port is a data or an event port. Typing the port witha block that has the «Signal» stereotype makes it an event port. All other types result in a data port.Each flowport needs to have a direction. The supported directions are in and out. Note inout is not asupported direction for the flowport. Data ports can also be typed with a default value these can be aLiteralBoolean, LiteralInteger, LiteralReal, or a Literal from the Enumeration the port is typed with.

Importing SubcomponentsSubcomponents can be dragged from the model explorer to the IBD. This results in the subcomponentinstance in the IBD of the element. Right clicking the subcomponent and selecting filter->synchronizewith model, synchronizes the subcomponent and any port created in the subcomponent element isvisible in the IBD of the parent element.

Creating ConnectionsConnections between ports of the component and its subcomponents are created using connectors.Connecting two ports create the connections. It is important to start the connection on the source portand end the connection on the target port. No visual indication is present in the SysML editor andcurrently the transformation tool needs to have the specific order to work. Future steps can be taken toidentify the direction of the ports and make the modeling of connections less error prone. It is possibleto have connections only be available in a specific state. This is modeled by adding an owned commentto the connection and in this comment link to the state of the element. Multiple states can be selectedwhen the connection is to be made available in more than one state.

Creating FlowsFlows are created using comments. Comments are used in version 1.0 of the SSTM methodology.Future work can change this to use constraints. The condition for the flow is typed in the comment.The comment is then connected to the port that is affected by the flow using a link connection. If theflow affects a subcomponent port a second link to the subcomponent instance needs to be created.

A.7.2. Element State MachineState machines model the behavior of the element. Only a single state machine with a single re-gion can be present in each element. When right-clicking an element and selecting New Diagram->StateMachine Diagram a state machine diagram, one state machine with one region is automaticallycreated. Three modeling elements can be created in the state machine these are: states, transitionsand pseudostates (only the start state).

104 A. SSTM SysML Modeling Steps

StatesStates are the most basic behavior elements and translate to states in the SLIM model. The name ofthe state is used for naming the SLIM state or mode. A state can be stereotyped by a «SstmState»stereotype. One of the added properties to this stereotype, which can be changed in the profile tab ofthe properties view, is a while variable. This variable allows the modeler to add a string that representsa while condition for the state.

TransitionTransitions connect states with each other and can be triggered by an event, by a guard and can havean effect, besides changing the state when activated.

Trigger A trigger can be added to the transition by adding it in the property menu. A port needs to beselected which will trigger the transition in the pop-up menu. Note that the port needs to be an eventport for the transformation to work correctly.

Guard A guard can be added to the transition in the properties menu as well. When adding a guardseveral options are presented. The constraint needs to be selected. Next in this constraint a Opaque-Expression needs to be added to the specification of the constraint. The language of the OpaqueEx-pression needs to be selected. No computation is done with the selected language, but for future workthe Object Constraint Language (OCL) language should be selected. The actual guard can be modeledin the body of the expression.

Effect An effect can be added to the transition by selecting OpaqueBehavior from the effect optionmenu. Similar to the guard the language needs to be selected. OCL is the preferred language. Theeffect can be modeled in the body of the OpaqueBehavior.

Pseudo StateThe SSTM methodology and tool support a single pseudo state, the initial state. This pseudo state,together with a transition name initial, links to the initial state of the model. Both the pseudo state andthe transition needs to be named “initial” for the transformation tool to recognize it. A future addition tothe tool is to have an activation pseudo state to have an activation state instead of an initial state. Thisstate will always be activated once a component is reactivated. An initial state is only the first statewhen the component is created but when deactivated and reactivated the state before the deactivationwill be the state after reactivation.

A.8. Creating Error ElementsError elements are created in the same way as nominal elements, but some differences in modelingthem are required.

A.8.1. Error ModelsAn error model models the error: four main subparts of an error model can be modeled using the SSTMmethodology. These parts are the following:

• Events: Events can be triggered manually or have a random occurrence when they trigger.

• Clocks: Clocks can be used for timing of transitions in the error model.

• States: Error states determine the state of the error which can control the effect on other elements.

• Transitions: Transitions connect different states. Triggering a transition will change the state.Transitions can be triggered by events or guard, which might include clock expressions.

An error model is modeled using a block with the «ErrorModel» stereotype connected to it. To keepthe modeling repository as clean as possible, users are advised to store all error models of a specificnode in the “4-Errors” package.

A.8. Creating Error Elements 105

Error EventsError events are modeled using ports with the «ErrorEvent» stereotype connected to them. The prop-erties of the stereotype allow the modeler to add a probability of the event and a possible time unitfor the probability. When no probability is selected, the event is treated as a manual event. Similar towhen no time unit is chosen the default probability per time step is chosen for the transformation.

ClocksClock are modeled the same as clocks for nominal models, by adding the clock as a part associationof the error model.

Error StatesError states are modeled in a state machine diagram, as in the nominal model. The exception is thatan error state needs to have the «ErrorState» stereotype.

Error TransitionsError transitions are modeled the same as nominal transitions, in the state machine. The initial pseudostate and transition are also needed in the modeling of the error behavior.

A.8.2. Error InjectionErrors are injected into nominal models using a property of the nominal part. The property needs tobe typed by the «ErrorEffect» stereotype. This stereotype allows the modeler to model the effect ofa specific state of an error model. Four properties need to be set using the property options of thestereotype.

Error ModelThe error model to which the effect refers needs to be selected. This needs to be an error model andcannot be another nominal model.

Error StateThe error state of the references error model needs to be selected. The effect takes place once thestate has the active state in the error model.

Error TargetThe target element that is changed by the effect needs to be selected using this property. The elementneeds to be a port of the nominal model to which the effect is attached to.

Error EffectThe effect on the error target is modeled using this property. This needs to be a valid SLIM expression.

BSource code

Listing B.1 shows the source code of the battery-sensor experiment, which was automatically generatedusing the SSTM methodology and transformation tool.

1 system Sensor2 fea tu res3 reading : out data po r t bool De fau l t => ” t r ue ” ; ;4 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;5 end Sensor ;67 system Bat te ry8 fea tu res9 has_power_out : out data po r t bool De fau l t => ” t r ue ” ; ;10 has_power_in : i n data po r t bool De fau l t => ” t r ue ” ; ;11 double_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;12 zero_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;13 low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;14 end Ba t te ry ;1516 system Generator17 fea tu res18 has_power : out data po r t bool De fau l t => ” t r ue ” ; ;19 end Generator ;2021 system PSU22 fea tu res23 has_power : out data po r t bool De fau l t => ” t r ue ” ; ;24 double_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;25 zero_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;26 low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;27 end PSU;2829 bus Bus30 end Bus ;3132 system System33 fea tu res34 i s _ a l i v e : out data po r t bool Observable => t rue ; ;35 mode_selector : out data po r t enum( Primary , Secondary1 , Secondary2 ) De fau l t =>

” Primary ” ; Observable => t rue ; ;36 go_to_secondary1 : i n event po r t ;37 go_to_secondary2 : i n event po r t ;38 bat tery1_ low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;39 bat tery2_ low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;40 end System ;4142 system Enclosure43 end Enclosure ;4445 system Moni tor46 fea tu res

107

108 B. Source code

47 bat tery1_ low : i n data po r t bool De fau l t => ” f a l s e ” ; ;48 bat tery2_ low : i n data po r t bool De fau l t => ” f a l s e ” ; ;49 go_to_secondary1 : out event po r t ;50 go_to_secondary2 : out event po r t ;51 a larm_bat tery1 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;52 a larm_bat tery2 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;53 a la rm_bat te ry : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;54 p rope r t i e s55 FDIR => t rue ;56 end Moni tor ;57585960 system implementat ion Sensor . Imp61 subcomponents62 delay : data c lock ;63 s ta tes64 base : i n i t i a l s t a t e wh i le ( delay <= 1) ;65 t r a n s i t i o n s66 base [ when delay >= 1 and has_power then delay := 0 ; reading := t rue ] > base

; t r a n s i t i o n name : has_power_got_reading67 base [ when delay >= 1 and not has_power then delay := 0 ; reading := f a l s e ] >

base ; t r a n s i t i o n name : has_no_power_no_reading68 p rope r t i e s69 ErrorModel => c l a s s i f i e r ( PermanentFai lure . Imp ) ;70 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( reading ) ; E f f e c t =>” f a l s e ” ; ] )

;71 end Sensor . Imp ;7273 system implementat ion Ba t te ry . Imp74 subcomponents75 delay : data c lock ;76 s ta tes77 f u l l : i n i t i a l s t a t e wh i le ( delay <= 3) ;78 empty : s t a t e wh i le ( delay <= 1) ;79 low_s ing le : s t a te wh i le ( delay <= 2) ;80 low_double : s t a te wh i le ( delay <= 1) ;81 t r a n s i t i o n s82 f u l l [ when delay >= 1 and ( has_power_in or zero_consumption ) then delay := 0 ;

has_power_out := t rue ] > f u l l ; t r a n s i t i o n name : f u l l > f u l l83 f u l l [ when delay >= 3 and not has_power_in and not double_consumption and not

zero_consumption then delay := 0 ; has_power_out := t rue ; low := t rue ] >low_s ing le ; t r a n s i t i o n name : f u l l > low_s ing le

84 f u l l [ when delay >= 3 and not has_power_in and double_consumption and notzero_consumption then delay := 0 ; has_power_out := t rue ; low := t rue ] >low_double ; t r a n s i t i o n name : f u l l > low_double

85 low_s ing le [ when delay >= 1 and zero_consumption then delay := 0 ;has_power_out := t rue ] > low_s ing le ; t r a n s i t i o n name : low_s ing le >low_s ing le

86 low_s ing le [ when delay >= 2 and not zero_consumption then delay := 0 ;has_power_out := f a l s e ] > empty ; t r a n s i t i o n name : low_s ing le > empty

87 low_double [ when delay >= 1 and zero_consumption then delay := 0 ;has_power_out := t rue ] > low_double ; t r a n s i t i o n name : low_double >low_double

88 low_double [ when delay >= 1 and not zero_consumption then delay := 0 ;has_power_out := f a l s e ] > empty ; t r a n s i t i o n name : low_double > empty

89 empty [ when delay >= 1 then delay := 0 ; has_power_out := f a l s e ] > empty ;t r a n s i t i o n name : empty > empty

90 end Bat te ry . Imp ;9192 system implementat ion Generator . Imp93 p rope r t i e s94 ErrorModel => c l a s s i f i e r ( PermanentFai lure . Imp ) ;95 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( has_power ) ; E f f e c t =>” f a l s e

” ; ] ) ;96 end Generator . Imp ;9798 system implementat ion PSU. Imp99 subcomponents100 ba t t e r y : system Bat te ry . Imp ;101 generator : system Generator . Imp ;

109

102 mybus : bus Bus . Imp ;103 connect ions104 po r t generator . has_power > ba t t e r y . has_power_in ;105 po r t ba t t e r y . has_power_out > has_power ;106 po r t double_consumption > ba t t e r y . double_consumption ;107 po r t zero_consumption > ba t t e r y . zero_consumption ;108 po r t ba t t e r y . low > low ;109 p rope r t i e s110 Accesses => ( re ference (mybus ) ) app l i es to generator , ba t t e r y ;111 end PSU. Imp ;112113 bus implementat ion Bus . Imp114 end Bus . Imp ;115116 system implementat ion System . Imp117 subcomponents118 mybus : bus Bus . Imp ;119 psu2 : system PSU. Imp ;120 psu1 : system PSU. Imp ;121 sensor2 : system Sensor . Imp ;122 sensor1 : system Sensor . Imp ;123 connect ions124 po r t psu1 . has_power > sensor1 . has_power i n modes ( pr imary , secondary1 ) ;125 po r t psu1 . has_power > sensor2 . has_power i n modes ( secondary2 ) ;126 po r t psu2 . has_power > sensor2 . has_power i n modes ( pr imary , secondary2 ) ;127 po r t psu2 . has_power > sensor1 . has_power i n modes ( secondary1 ) ;128 po r t psu1 . low > bat te ry1_ low ;129 po r t psu2 . low > bat te ry2_ low ;130 f low sensor1 . reading or sensor2 . reading > i s _ a l i v e ;131 f low t rue > psu1 . double_consumption i n modes ( secondary1 ) ;132 f low t rue > psu1 . zero_consumption i n modes ( secondary2 ) ;133 f low t rue > psu2 . double_consumption i n modes ( secondary2 ) ;134 f low t rue > psu2 . zero_consumption i n modes ( secondary1 ) ;135 modes136 pr imary : i n i t i a l mode ;137 secondary1 : mode ;138 secondary2 : mode ;139 t r a n s i t i o n s140 pr imary [ go_to_secondary1 then mode_selector := Secondary1 ] > secondary1 ;

t r a n s i t i o n name : go_to_secondary1141 pr imary [ go_to_secondary2 then mode_selector := Secondary2 ] > secondary2 ;

t r a n s i t i o n name : go_to_secondary2142 p rope r t i e s143 Accesses => ( re ference (mybus ) ) app l i es to psu2 , sensor2 , psu1 , sensor1 ;144 end System . Imp ;145146 system implementat ion Enclosure . Imp147 subcomponents148 mon: system Moni tor . Imp ;149 sys : system System . Imp ;150 connect ions151 po r t sys . bat te ry1_ low > mon. bat tery1_ low ;152 po r t sys . bat te ry2_ low > mon. bat tery2_ low ;153 po r t mon. go_to_secondary1 > sys . go_to_secondary1 ;154 po r t mon. go_to_secondary2 > sys . go_to_secondary2 ;155 p rope r t i e s156 Pat te rns => (157 [ Name => ” always System i s _ a l i v e ” ; Pa t te rn => ” Globa l ly , i t i s always the

case t ha t sys . i s _ a l i v e holds ” ; ] ,158 [ Name => ” always Generator . has_power ” ; Pa t te rn => ” Globa l ly , i t i s always the

case t ha t sys . psu1 . generator . has_power holds ” ; ] ,159 [ Name => ” always ALARM_B1 imp l i es B1_LOW” ; Pat te rn => ” Globa l ly , i t i s always

the case t ha t mon. a larm_bat tery1 imp l i es sys . psu1 . ba t t e r y . low holds ” ;] ,

160 [ Name => ” never PSUA Low ” ; Pat te rn => ” Globa l ly , i t i s never the case t ha t sys . psu1 . ba t t e r y .mode = mode : low_s ing le holds ” ; ] ,

161 [ Name => ” never PSUA empty ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t sys . psu1 . ba t t e r y .mode = mode : empty holds ” ; ] ,

162 [ Name => ” never NOT i s _ a l i v e ” ; Pa t te rn => ” Globa l ly , i t i s never the caset ha t not sys . i s _ a l i v e holds ” ; ] ,

163 [ Name => ” never Secondary1 ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t

110 B. Source code

sys .mode = mode : secondary1 holds ” ; ] ,164 [ Name => ” never Low_double ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t

sys . psu1 . ba t t e r y .mode = mode : low_double holds ” ; ] ,165 [ Name => ”B1_LOW > ALARM_B1 ” ; Pat te rn => ” Globa l ly , i f sys . psu1 . ba t t e r y . low

has occurred then in response mon. a larm_bat tery1 even tua l l y holds ” ;] ,

166 [ Name => ”ALARM_B1 > SECONDARY2” ; Pat te rn => ” Globa l ly , i f mon.a larm_bat tery1 has occurred then i n response sys .mode = mode : secondary2 even tua l l y holds ” ; ] ,

167 [ Name => ” Ba t te ry low responded by reconf ” ; Pa t te rn => ” Globa l ly , i f sys .psu1 . ba t t e r y . low or sys . psu2 . ba t t e r y . low has occurred then i n response sys .mode = mode : secondary1 or sys .mode = mode : secondary2 even tua l l y holds” ; ]

168 ) ;169 end Enclosure . Imp ;170171 system implementat ion Moni tor . Imp172 subcomponents173 delay : data c lock ;174 connect ions175 f low t rue > a la rm_bat te ry i n modes ( recovery ) ;176 s ta tes177 base : i n i t i a l s t a t e wh i le ( delay <= 1) ;178 recovery : s t a te wh i le ( delay <= 1) ;179 t r a n s i t i o n s180 base [ when delay >= 1 and not bat te ry1_ low and not bat te ry2_ low then delay :=

0 ] > base ; t r a n s i t i o n name : base > base181 base [ go_to_secondary1 when delay >= 1 and bat te ry1_ low then delay := 0 ;

a larm_bat tery1 := t rue ] > recovery ; t r a n s i t i o n name : go_to_secondary1182 base [ go_to_secondary2 when delay >= 1 and bat te ry2_ low then delay := 0 ;

a larm_bat tery2 := t rue ] > recovery ; t r a n s i t i o n name : go_to_secondary2183 recovery [ when delay >= 1 then delay := 0 ] > recovery ; t r a n s i t i o n name :

recovery > recovery184 p rope r t i e s185 FDIR => t rue ;186 end Moni tor . Imp ;187188 e r r o r model PermanentFai lure189 end PermanentFai lure ;190191 e r r o r model implementat ion PermanentFai lure . Imp192 events193 f a u l t : e r r o r event ;194 s ta tes195 ok : i n i t i a l s t a t e ;196 dead : e r r o r s t a t e ;197 t r a n s i t i o n s198 ok [ f a u l t ] > dead ; t r a n s i t i o n name : f a u l t199 end PermanentFai lure . Imp ;

Listing B.1: Automatically generated battery-sensor SLIM code

Listing B.2 shows the code which is manually written for the battery-sensor system.

1 system Sensor2 fea tu res3 reading : out data po r t bool De fau l t => ” t r ue ” ; ;4 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;5 end Sensor ;67 system Bat te ry8 fea tu res9 has_power_out : out data po r t bool De fau l t => ” t r ue ” ; ;10 has_power_in : i n data po r t bool De fau l t => ” t r ue ” ; ;11 double_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;12 zero_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;13 low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;14 end Ba t te ry ;1516 system Generator17 fea tu res

111

18 has_power : out data po r t bool De fau l t => ” t r ue ” ; ;19 end Generator ;2021 system PSU22 fea tu res23 has_power : out data po r t bool ;24 double_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;25 zero_consumption : i n data po r t bool De fau l t => ” f a l s e ” ; ;26 low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;27 end PSU;2829 bus Bus30 end Bus ;3132 system System33 fea tu res34 i s _ a l i v e : out data po r t bool Observable => t rue ; ;35 mode_selector : out data po r t enum( Primary , Secondary1 , Secondary2 ) De fau l t =>

” Primary ” ; Observable => t rue ; ;36 go_to_secondary1 : i n event po r t ;37 go_to_secondary2 : i n event po r t ;38 bat tery1_ low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;39 bat tery2_ low : out data po r t bool De fau l t => ” f a l s e ” ; Observable => t rue ; ;40 end System ;4142 system Enclosure43 end Enclosure ;4445 system Moni tor46 fea tu res47 bat tery1_ low : i n data po r t bool De fau l t => ” f a l s e ” ; ;48 bat tery2_ low : i n data po r t bool De fau l t => ” f a l s e ” ; ;49 go_to_secondary1 : out event po r t ;50 go_to_secondary2 : out event po r t ;51 a larm_bat tery1 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;52 a larm_bat tery2 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;53 a la rm_bat te ry : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;54 p rope r t i e s55 FDIR => t rue ;56 end Moni tor ;57585960 system implementat ion Sensor . Imp61 subcomponents62 delay : data c lock ;63 s ta tes64 base : i n i t i a l s t a t e wh i le ( delay <= 1) ;65 t r a n s i t i o n s66 base [ when delay >= 1 and has_power then delay := 0 ; reading := t rue ] > base

; t r a n s i t i o n name : has_power_got_reading67 base [ when delay >= 1 and not has_power then delay := 0 ; reading := f a l s e ] >

base ; t r a n s i t i o n name : has_no_power_no_reading68 p rope r t i e s69 ErrorModel => c l a s s i f i e r ( PermanentFai lure . Imp ) ;70 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( reading ) ; E f f e c t =>” f a l s e ” ; ] )

;71 end Sensor . Imp ;7273 system implementat ion Ba t te ry . Imp74 subcomponents75 delay : data c lock ;76 s ta tes77 f u l l : i n i t i a l s t a t e wh i le ( delay <= 3) ;78 empty : s t a te wh i le ( delay <= 1) ;79 low_s ing le : s t a te wh i le ( delay <= 2) ;80 low_double : s t a t e wh i le ( delay <= 1) ;81 t r a n s i t i o n s82 f u l l [ when delay >= 1 and ( has_power_in or zero_consumption ) then delay := 0 ;

has_power_out := t rue ] > f u l l ; t r a n s i t i o n name : f u l l > f u l l83 f u l l [ when delay >= 3 and not has_power_in and not double_consumption and not

112 B. Source code

zero_consumption then delay := 0 ; has_power_out := t rue ; low := t rue ] >low_s ing le ; t r a n s i t i o n name : f u l l > low_s ing le

84 f u l l [ when delay >= 3 and not has_power_in and double_consumption and notzero_consumption then delay := 0 ; has_power_out := t rue ; low := t rue ] >low_double ; t r a n s i t i o n name : f u l l > low_double

85 low_s ing le [ when delay >= 1 and zero_consumption then delay := 0 ;has_power_out := t rue ] > low_s ing le ; t r a n s i t i o n name : low_s ing le >low_s ing le

86 low_s ing le [ when delay >= 2 and not zero_consumption then delay := 0 ;has_power_out := f a l s e ] > empty ; t r a n s i t i o n name : low_s ing le > empty

87 low_double [ when delay >= 1 and zero_consumption then delay := 0 ;has_power_out := t rue ] > low_double ; t r a n s i t i o n name : low_double >low_double

88 low_double [ when delay >= 1 and not zero_consumption then delay := 0 ;has_power_out := f a l s e ] > empty ; t r a n s i t i o n name : low_double > empty

89 empty [ when delay >= 1 then delay := 0 ; has_power_out := f a l s e ] > empty ;t r a n s i t i o n name : empty > empty

90 end Bat te ry . Imp ;9192 system implementat ion Generator . Imp93 p rope r t i e s94 ErrorModel => c l a s s i f i e r ( PermanentFai lure . Imp ) ;95 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( has_power ) ; E f f e c t =>” f a l s e

” ; ] ) ;96 end Generator . Imp ;9798 system implementat ion PSU. Imp99 subcomponents100 ba t t e r y : system Bat te ry . Imp ;101 generator : system Generator . Imp ;102 mybus : bus Bus . Imp ;103 connect ions104 po r t generator . has_power > ba t t e r y . has_power_in ;105 po r t ba t t e r y . has_power_out > has_power ;106 po r t double_consumption > ba t t e r y . double_consumption ;107 po r t zero_consumption > ba t t e r y . zero_consumption ;108 po r t ba t t e r y . low > low ;109 p rope r t i e s110 Accesses => ( re ference (mybus ) ) app l ies to generator , ba t t e r y ;111 end PSU. Imp ;112113 bus implementat ion Bus . Imp114 end Bus . Imp ;115116 system implementat ion System . Imp117 subcomponents118 mybus : bus Bus . Imp ;119 psu2 : system PSU. Imp ;120 psu1 : system PSU. Imp ;121 sensor2 : system Sensor . Imp ;122 sensor1 : system Sensor . Imp ;123 connect ions124 po r t psu1 . has_power > sensor1 . has_power i n modes ( pr imary , secondary1 ) ;125 po r t psu1 . has_power > sensor2 . has_power i n modes ( secondary1 ) ;126 po r t psu2 . has_power > sensor2 . has_power i n modes ( pr imary , secondary2 ) ;127 po r t psu2 . has_power > sensor1 . has_power i n modes ( secondary2 ) ;128 po r t psu1 . low > bat te ry1_ low ;129 po r t psu2 . low > bat te ry2_ low ;130 f low sensor1 . reading or sensor2 . reading > i s _ a l i v e ;131 f low t rue > psu1 . double_consumption i n modes ( secondary1 ) ;132 f low t rue > psu1 . zero_consumption i n modes ( secondary2 ) ;133 f low t rue > psu2 . double_consumption i n modes ( secondary2 ) ;134 f low t rue > psu2 . zero_consumption i n modes ( secondary1 ) ;135 modes136 pr imary : i n i t i a l mode ;137 secondary1 : mode ;138 secondary2 : mode ;139 t r a n s i t i o n s140 pr imary [ go_to_secondary1 then mode_selector := Secondary1 ] > secondary1 ;

t r a n s i t i o n name : go_to_secondary1141 pr imary [ go_to_secondary2 then mode_selector := Secondary2 ] > secondary2 ;

113

t r a n s i t i o n name : go_to_secondary2142 p rope r t i e s143 Accesses => ( re ference (mybus ) ) app l i es to psu2 , sensor2 , psu1 , sensor1 ;144 end System . Imp ;145146 system implementat ion Enclosure . Imp147 subcomponents148 mon: system Moni tor . Imp ;149 sys : system System . Imp ;150 connect ions151 po r t sys . bat te ry1_ low > mon. bat tery1_ low ;152 po r t sys . bat te ry2_ low > mon. bat tery2_ low ;153 po r t mon. go_to_secondary1 > sys . go_to_secondary1 ;154 po r t mon. go_to_secondary2 > sys . go_to_secondary2 ;155 p rope r t i e s156 Pat te rns => (157 [ Name => ” always System i s _ a l i v e ” ; Pa t te rn => ” Globa l ly , i t i s always the

case t ha t sys . i s _ a l i v e holds ” ; ] ,158 [ Name => ” always Generator . has_power ” ; Pa t te rn => ” Globa l ly , i t i s always the

case t ha t sys . psu1 . generator . has_power holds ” ; ] ,159 [ Name => ” always ALARM_B1 imp l i es B1_LOW” ; Pat te rn => ” Globa l ly , i t i s always

the case t ha t mon. a larm_bat tery1 imp l i es sys . psu1 . ba t t e r y . low holds ” ;] ,

160 [ Name => ” never PSUA Low ” ; Pat te rn => ” Globa l ly , i t i s never the case t ha t sys . psu1 . ba t t e r y .mode = mode : low_s ing le holds ” ; ] ,

161 [ Name => ” never PSUA empty ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t sys . psu1 . ba t t e r y .mode = mode : empty holds ” ; ] ,

162 [ Name => ” never NOT i s _ a l i v e ” ; Pa t te rn => ” Globa l ly , i t i s never the caset ha t not sys . i s _ a l i v e holds ” ; ] ,

163 [ Name => ” never Secondary1 ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t sys .mode = mode : secondary1 holds ” ; ] ,

164 [ Name => ” never Low_double ” ; Pa t te rn => ” Globa l ly , i t i s never the case t ha t sys . psu1 . ba t t e r y .mode = mode : low_double holds ” ; ] ,

165 [ Name => ”B1_LOW > ALARM_B1 ” ; Pat te rn => ” Globa l ly , i f sys . psu1 . ba t t e r y . low has occurred then i n response mon. a larm_bat tery1 even tua l l y holds ” ;] ,

166 [ Name => ”ALARM_B1 > SECONDARY2” ; Pat te rn => ” Globa l ly , i f mon.a larm_bat tery1 has occurred then i n response sys .mode = mode : secondary2 even tua l l y holds ” ; ] ,

167 [ Name => ” Ba t te ry low responded by reconf ” ; Pa t te rn => ” Globa l ly , i f sys .psu1 . ba t t e r y . low or sys . psu2 . ba t t e r y . low has occurred then in response sys .mode = mode : secondary1 or sys .mode = mode : secondary2 even tua l l y holds” ; ]

168 ) ;169 end Enclosure . Imp ;170171 system implementat ion Moni tor . Imp172 subcomponents173 delay : data c lock ;174 connect ions175 f low t rue > a la rm_bat te ry i n modes ( recovery ) ;176 s ta tes177 base : i n i t i a l s t a t e wh i le ( delay <= 1) ;178 recovery : s t a t e wh i le ( delay <= 1) ;179 t r a n s i t i o n s180 base [ when delay >= 1 and not bat tery1_ low and not bat te ry2_ low then delay :=

0 ] > base ; t r a n s i t i o n name : base > base181 base [ go_to_secondary2 when delay >= 1 and bat te ry1_ low then delay := 0 ;

a larm_bat tery1 := t rue ] > recovery ; t r a n s i t i o n name : go_to_secondary1182 base [ go_to_secondary1 when delay >= 1 and bat te ry2_ low then delay := 0 ;

a larm_bat tery2 := t rue ] > recovery ; t r a n s i t i o n name : go_to_secondary2183 recovery [ when delay >= 1 then delay := 0 ] > recovery ; t r a n s i t i o n name :

recovery > recovery184 p rope r t i e s185 FDIR => t rue ;186 end Moni tor . Imp ;187188 e r r o r model PermanentFai lure189 end PermanentFai lure ;190191 e r r o r model implementat ion PermanentFai lure . Imp

114 B. Source code

192 events193 f a u l t : e r r o r event ;194 s ta tes195 ok : i n i t i a l s t a t e ;196 dead : e r r o r s t a t e ;197 t r a n s i t i o n s198 ok [ f a u l t ] > dead ; t r a n s i t i o n name : f a u l t199 end PermanentFai lure . Imp ;

Listing B.2: Manually written battery-sensor SLIM code

Listing B.3 shows the generated SLIM code for the ADCS case study.

1 system System2 fea tu res3 master_working : out data po r t bool De fau l t => ” t r ue ” ; ;4 s lave_working : out data po r t bool De fau l t => ” t r ue ” ; ;5 go_to_slave : i n event po r t ;6 is_work ing : out data po r t bool ;7 reset_master : i n event po r t ;8 system_mode : out data po r t enum(Master , Slave ) De fau l t => ” Master ” ; ;9 rw1_working : out data po r t bool De fau l t => ” t r ue ” ; ;10 rw2_working : out data po r t bool De fau l t => ” t r ue ” ; ;11 gps1_working : out data po r t bool De fau l t => ” t r ue ” ; ;12 gps2_working : out data po r t bool De fau l t => ” t r ue ” ; ;13 imu1_working : out data po r t bool De fau l t => ” t r ue ” ; ;14 imu2_working : out data po r t bool De fau l t => ” t r ue ” ; ;15 eps1_working : out data po r t bool De fau l t => ” t r ue ” ; ;16 eps2_working : out data po r t bool De fau l t => ” t r ue ” ; ;17 end System ;1819 system implementat ion System . Imp20 subcomponents21 eps1 : device EPS. Imp ;22 eps2 : device EPS. Imp ;23 imu1 : system IMU . Imp ;24 imu2 : system IMU . Imp ;25 gps1 : system GPS. Imp ;26 gps2 : system GPS. Imp ;27 masterComputer : system adcsComputer . Imp ;28 slaveComputer : system adcsComputer . Imp ;29 rw1 : device ReactionWheel . Imp ;30 rw2 : device ReactionWheel . Imp ;31 connect ions32 po r t eps1 . has_power > rw1 . has_power ;33 po r t eps2 . has_power > rw2 . has_power ;34 po r t eps2 . has_power > slaveComputer . has_power ;35 po r t eps1 . has_power > masterComputer . has_power ;36 po r t eps1 . has_power > gps1 . has_power ;37 po r t eps1 . has_power > imu1 . has_power ;38 po r t eps2 . has_power > gps2 . has_power ;39 po r t eps2 . has_power > imu2 . has_power ;40 po r t gps1 . reading > masterComputer . gps1_reading ;41 po r t gps1 . reading > slaveComputer . gps1_reading ;42 po r t gps2 . reading > masterComputer . gps2_reading ;43 po r t gps2 . reading > slaveComputer . gps2_reading ;44 po r t imu1 . reading > masterComputer . imu1_reading ;45 po r t imu1 . reading > slaveComputer . imu1_reading ;46 po r t imu2 . reading > masterComputer . imu2_reading ;47 po r t imu2 . reading > slaveComputer . imu2_reading ;48 po r t masterComputer . rw_con t ro l > master_working ;49 po r t reset_master > masterComputer . r ese t_po r t ;50 po r t slaveComputer . rw_con t ro l > slave_working ;51 po r t rw2 . working > rw2_working ;52 po r t rw1 . working > rw1_working ;53 po r t gps1 . reading > gps1_working ;54 po r t gps2 . reading > gps2_working ;55 po r t imu1 . reading > imu1_working ;56 po r t imu2 . reading > imu2_working ;57 po r t eps2 . has_power > eps2_working ;58 po r t eps1 . has_power > eps1_working ;

115

59 f low rw1 . working or rw2 . working > is_work ing ;60 f low masterComputer . rw_con t ro l or slaveComputer . rw_con t ro l > rw1 . has_cont ro l ;61 f low masterComputer . rw_con t ro l or slaveComputer . rw_con t ro l > rw2 . has_cont ro l ;62 modes63 master : i n i t i a l mode ;64 s lave : mode ;65 t r a n s i t i o n s66 master [ go_to_slave ] > s lave ; t r a n s i t i o n name : go to s lave ( t r i gge red )67 end System . Imp ;686970 device EPS71 fea tu res72 has_power : out data po r t bool De fau l t => ” t r ue ” ; ;73 end EPS;7475 device implementat ion EPS. Imp76 p rope r t i e s77 ErrorModel => c l a s s i f i e r ( EpsError . Imp ) ;78 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( has_power ) ; E f f e c t =>” f a l s e

” ; ] ) ;79 end EPS. Imp ;808182 system GPS83 fea tu res84 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;85 reading : out data po r t bool De fau l t => ” t r ue ” ; ;86 end GPS;8788 system implementat ion GPS. Imp89 subcomponents90 delay : data c lock ;91 s ta tes92 base : i n i t i a l s t a t e ;93 t r a n s i t i o n s94 base [ when delay >= 1 and has_power then delay := 0 ; reading := t rue ] > base

; t r a n s i t i o n name : has_power > reading = t rue95 base [ when delay >= 1 and not has_power then delay := 0 ; reading := f a l s e ] >

base ; t r a n s i t i o n name : no power > reading = f a l s e96 p rope r t i e s97 ErrorModel => c l a s s i f i e r ( GpsError . Imp ) ;98 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( reading ) ; E f f e c t =>” f a l s e ” ; ] )

;99 end GPS. Imp ;100101102 system IMU103 fea tu res104 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;105 reading : out data po r t bool De fau l t => ” t r ue ” ; ;106 end IMU ;107108 system implementat ion IMU . Imp109 subcomponents110 delay : data c lock ;111 s ta tes112 base : i n i t i a l s t a t e ;113 t r a n s i t i o n s114 base [ when delay >= 1 and has_power then delay := 0 ; reading := t rue ] > base

; t r a n s i t i o n name : has_power > reading = t rue115 base [ when delay >= 1 and not has_power then delay := 0 ; reading := f a l s e ] >

base ; t r a n s i t i o n name : no power > reading = f a l s e116 p rope r t i e s117 ErrorModel => c l a s s i f i e r ( ImuError . Imp ) ;118 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( reading ) ; E f f e c t =>” f a l s e ” ; ] )

;119 end IMU . Imp ;120121122 system adcsComputer

116 B. Source code

123 fea tu res124 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;125 rese t_po r t : i n event po r t ;126 gps1_reading : i n data po r t bool De fau l t => ” t r ue ” ; ;127 gps2_reading : i n data po r t bool De fau l t => ” t r ue ” ; ;128 imu1_reading : i n data po r t bool De fau l t => ” t r ue ” ; ;129 imu2_reading : i n data po r t bool De fau l t => ” t r ue ” ; ;130 rw_con t ro l : out data po r t bool De fau l t => ” t r ue ” ; ;131 end adcsComputer ;132133 system implementat ion adcsComputer . Imp134 subcomponents135 delay : data c lock ;136 connect ions137 f low has_power > rw_con t ro l i n modes ( ok ) ;138 f low f a l s e > rw_con t ro l i n modes ( dead ) ;139 s ta tes140 ok : i n i t i a l s t a t e ;141 dead : s t a t e ;142 t r a n s i t i o n s143 ok [ when delay >= 2 and ( gps1_reading or gps2_reading ) and ( imu1_reading or

imu2_reading ) and has_power then delay := 0 ] > ok ; t r a n s i t i o n name :rese t delay ( ok )

144 dead [ when delay >= 1 then delay := 0 ] > dead ; t r a n s i t i o n name : rese tdelay ( dead )

145 ok [ when delay >= 1 and not gps1_reading and not gps2_reading then delay := 0] > dead ; t r a n s i t i o n name : no gps

146 ok [ when delay >= 1 and not imu1_reading and not imu2_reading then delay := 0] > dead ; t r a n s i t i o n name : no imu

147 ok [ when delay >= 1 and not has_power then delay := 0 ] > dead ; t r a n s i t i o nname : no power

148 p rope r t i e s149 ErrorModel => c l a s s i f i e r ( ComputerError . Imp ) ;150 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( rw_con t ro l ) ; E f f e c t =>” f a l s e

” ; ] ) ;151 end adcsComputer . Imp ;152153154 device ReactionWheel155 fea tu res156 has_power : i n data po r t bool De fau l t => ” t r ue ” ; ;157 has_cont ro l : i n data po r t bool De fau l t => ” t r ue ” ; ;158 working : out data po r t bool De fau l t => ” t r ue ” ; ;159 end ReactionWheel ;160161 device implementat ion ReactionWheel . Imp162 subcomponents163 delay : data c lock ;164 connect ions165 f low f a l s e > working i n modes ( dead ) ;166 f low has_power > working i n modes ( base ) ;167 s ta tes168 base : i n i t i a l s t a t e ;169 dead : s t a t e ;170 t r a n s i t i o n s171 base [ when delay >= 1 and has_cont ro l then delay := 0 ] > base ; t r a n s i t i o n

name : power + con t r o l = working172 base [ when delay >= 1 and not has_cont ro l then delay := 0 ] > dead ;

t r a n s i t i o n name : no power or no con t r o l = not working173 p rope r t i e s174 ErrorModel => c l a s s i f i e r ( RwError . Imp ) ;175 Fau l tE f f e c t s => ( [ State =>”dead ” ; Target=>re ference ( working ) ; E f f e c t =>” f a l s e ” ; ] )

;176 end ReactionWheel . Imp ;177178179 system Enclosure180 end Enclosure ;181182 system implementat ion Enclosure . Imp183 subcomponents

117

184 cdhs : system FDIR_CDHS. Imp ;185 sys : system System . Imp ;186 connect ions187 po r t cdhs . go_to_slave > sys . go_to_slave ;188 po r t sys . master_working > cdhs . master_working ;189 po r t sys . s lave_working > cdhs . s lave_working ;190 po r t sys . eps1_working > cdhs . eps1_working ;191 po r t sys . eps2_working > cdhs . eps2_working ;192 po r t sys . imu1_working > cdhs . imu1_working ;193 po r t sys . imu2_working > cdhs . imu2_working ;194 po r t sys . gps1_working > cdhs . gps1_working ;195 po r t sys . gps2_working > cdhs . gps2_working ;196 po r t sys . rw1_working > cdhs . rw1_working ;197 po r t sys . rw2_working > cdhs . rw2_working ;198 end Enclosure . Imp ;199200201 system FDIR_CDHS202 fea tu res203 go_to_slave : out event po r t ;204 master_working : i n data po r t bool De fau l t => ” t r ue ” ; ;205 slave_working : i n data po r t bool De fau l t => ” t r ue ” ; ;206 eps1_working : i n data po r t bool De fau l t => ” t r ue ” ; ;207 eps2_working : i n data po r t bool De fau l t => ” t r ue ” ; ;208 gps1_working : i n data po r t bool De fau l t => ” t r ue ” ; ;209 gps2_working : i n data po r t bool De fau l t => ” t r ue ” ; ;210 rw1_working : i n data po r t bool De fau l t => ” t r ue ” ; ;211 rw2_working : i n data po r t bool De fau l t => ” t r ue ” ; ;212 imu1_working : i n data po r t bool De fau l t => ” t r ue ” ; ;213 imu2_working : i n data po r t bool De fau l t => ” t r ue ” ; ;214 alarm_save_state : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;215 alarm_master_computer : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ;

;216 alarm_slave_computer : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ;

;217 alarm_eps : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;218 alarm_eps1 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;219 alarm_eps2 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;220 alarm_rw1 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;221 alarm_rw2 : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;222 alarm_imu : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;223 alarm_gps : out data po r t bool De fau l t => ” f a l s e ” ; Alarm => t rue ; ;224 p rope r t i e s225 FDIR => t rue ;226 end FDIR_CDHS;227228 system implementat ion FDIR_CDHS. Imp229 subcomponents230 delay : data c lock ;231 connect ions232 f low not master_working > alarm_master_computer ;233 f low not s lave_working > alarm_slave_computer ;234 f low not eps1_working or not eps2_working > alarm_eps ;235 f low not eps1_working > alarm_eps1 ;236 f low not eps2_working > alarm_eps2 ;237 f low not rw1_working > alarm_rw1 ;238 f low not rw2_working > alarm_rw2 ;239 f low not imu1_working or not imu2_working > alarm_imu ;240 f low not gps1_working or not gps2_working > alarm_gps ;241 f low t rue > alarm_save_state i n modes ( save_state ) ;242 s ta tes243 base : i n i t i a l s t a t e ;244 save_state : s t a t e ;245 t r a n s i t i o n s246 base [ when delay >= 1 and master_working and slave_working and eps1_working

and eps2_working then delay := 0 ] > base ; t r a n s i t i o n name : rese t delay( base )

247 base [ go_to_slave when delay >= 1 and ( not master_working or nots lave_working or not eps1_working or not eps2_working ) then delay := 0 ] >save_state ; t r a n s i t i o n name : go_to_save_state

248 save_state [ when delay >= 1 then delay := 0 ] > save_state ; t r a n s i t i o n

118 B. Source code

name : save_state > save_state249 p rope r t i e s250 FDIR => t rue ;251 end FDIR_CDHS. Imp ;252253254 e r r o r model EpsError255 end EpsError ;256257 e r r o r model implementat ion EpsError . Imp258 events259 epsFaul t : e r r o r event ;260 s ta tes261 ok : i n i t i a l s t a t e ;262 dead : e r r o r s t a t e ;263 t r a n s i t i o n s264 ok [ epsFaul t ] > dead ; t r a n s i t i o n name : ok > dead ( f a i l u r e event )265 end EpsError . Imp ;266267268 e r r o r model ImuError269 end ImuError ;270271 e r r o r model implementat ion ImuError . Imp272 events273 imuFaul t : e r r o r event ;274 s ta tes275 ok : i n i t i a l s t a t e ;276 dead : e r r o r s t a t e ;277 t r a n s i t i o n s278 ok [ imuFaul t ] > dead ; t r a n s i t i o n name : ok > dead ( imuFaul t )279 end ImuError . Imp ;280281282 e r r o r model GpsError283 end GpsError ;284285 e r r o r model implementat ion GpsError . Imp286 events287 gpsFaul t : e r r o r event ;288 s ta tes289 ok : i n i t i a l s t a t e ;290 dead : e r r o r s t a t e ;291 t r a n s i t i o n s292 ok [ gpsFaul t ] > dead ; t r a n s i t i o n name : f a t a l event293 end GpsError . Imp ;294295296 e r r o r model ComputerError297 end ComputerError ;298299 e r r o r model implementat ion ComputerError . Imp300 events301 computerFaul t : e r r o r event ;302 s ta tes303 ok : i n i t i a l s t a t e ;304 dead : e r r o r s t a t e ;305 t r a n s i t i o n s306 ok [ computerFaul t ] > dead ; t r a n s i t i o n name : ok > dead ( computer event )307 end ComputerError . Imp ;308309310 e r r o r model RwError311 end RwError ;312313 e r r o r model implementat ion RwError . Imp314 events315 rwFaul t : e r r o r event occurrence poisson 0 .02 ;316 s ta tes317 ok : i n i t i a l s t a t e ;318 dead : e r r o r s t a t e ;

119

319 t r a n s i t i o n s320 ok [ rwFaul t ] > dead ; t r a n s i t i o n name : ok > dead ( f a i l u r e event )321 end RwError . Imp ;

Listing B.3: Generated SLIM code for the ADCS case study

CCurrent Methodologies and Evaluation

CriteriaThis chapter discusses the most used MBSE methodologies for different sides of the MBSE spectrum.Both the hardware/architecture modelling and embedded software modelling methods are elaboratedupon in the first two sections. The third section follows the discussed methods and proposes possiblesolutions to start combining the methods into one methodology.

Estafan [12] published in 2008 a survey on MBSEmethodologies. The survey discussed six leadingMBSE methodologies at the time. These methodologies were:

1. International Business Machines Corporation (IBM) Telelogic Harmony-SE

2. International Council on Systems Engineering (INCOSE) Object-Oriented Systems EngineeringMethod (OOSEM)

3. IBM Rational Unified Process for Systems Engineering (RUP SE) for Model-Driven Systems De-velopment (MDSM)

4. Vitech Model-Based Systems Engineering (MBSE) Methodology

5. Jet Propulsion Laboratory (JPL) State Analysis (SA)

6. Dori Object-Process Methodology (OPM)

Not all methodologies are currently supported or well documented. The two methodologies most welldocumented and used at this time are the first two mentioned. INCOSE OOSEM is the best docu-mented with several examples. Due to this, OOSEM was chosen to be the baseline for the architecturemethodology and is further explained in this chapter. OOSEM uses SysML as its modelling language.

Estafan’s survey mainly focused on MBSE methodologies for architectural models. ESA currentlyfunds the TASTE, a toolset for modelling real-time embedded systems. TASTE is focuses on modellingembedded systems using AADL as its main modelling language, whereas Estafan’s survey focused onhardware and architecture modelling. TASTE is also be discussed in this chapter.

Elaboration on combining these two methodologies follows after the discussion of OOSEM andTASTE.

C.1. INCOSE Object-Oriented Systems Engineering MethodWork on OOSEM started in the mid to late 1990’s by the Software Productivity Consortium in combina-tion with Lockheed Martin [12]. In 2000, INCOSE formed a working group to further evolve the method-ology. “OOSEM is a top-down, scenario-driven process that uses SysML to support the analysis,specification, design, and verification of systems.” [14]. The main artifact of the OOSEM methodologyis the system model. This model is created and refined throughout the modeling process, starting withstakeholder needs to eventually a complete system model with many intermediate steps to advancefrom a simple model to a detailed product.

121

122 C. Current Methodologies and Evaluation Criteria

OOSEM uses the traditional “Vee”, or V-model, life cycle process. The six steps in the process are:

1. Analyze stakeholder needs

2. Define system requirements

3. Define logical architecture

4. Synthesize candidate allocated architectures

5. Optimize and evaluate alternatives

6. Validate and verify system [12]

In practice, an extra step is performed before these six, which is to set-up the model.In order to focus the work of the thesis project far more time was spend on the down-hill steps of

the “Vee” diagram. Only the first four steps of the OOSEM process were investigated in full detail, aswell as the set-up step. These steps are elaborated in the following sections.

The information presented in this section is acquired by following the explanation of Friedenthal’sbook “A practical guide to SysML: The systems modelling language” [14] and using this to model asimple example project, not directly related to space, to gain hands-on experience with the method.

C.1.1. Model Set-UpTwo main activities need to be performed during the mode set-up step. The first is to create customstereotypes. SysML has several stereotypes but OOSEM also introduces multiple custom stereotypes.These need to be created and/or imported into the project. Project specific stereotypes can also becreated besides the OOSEM stereotypes. It is useful to import stereotypes from previous projects andhave a separate repository for all custom stereotypes used in an organization. This allows the modelerto easily import all of them and not recreate the entire set of stereotypes at the beginning of each newproject. The second activity is to create the basic model structure. OOSEM dictates five top levelpackages for a project, these are:

1. Process Guidance

2. Model Domain as-is

3. Model Domain to-be

4. Value Types

5. Viewpoints

The first package, process guidance, is the container to store information about the process itself.The ”model domain as-is” package holds the current situation models. This includes the organizationstructure and other models. This package also holds the current system model (high level) if a currentsystem is already present and needs to be improved. As expected the third package, model domainto-be, holds the system to be designed. Value types holds all custom created value types, units, andquantity types. The last package, viewpoints, stores different views of the system specifically createdfor stakeholders who need a different view of the system.

Especially the model domain to-be package is divided into many subpackages. Requirements,structure, use cases, behavior, parametrics, and interface definitions are subpackages to hold corre-sponding views and modelling elements. Besides these packages a subpackage named according tothe name of the system of interest is housed in the model domain to-be package. This package holdsthe actual model elements and views of the to be designed model and is constructed in the later stepsof the methodology. The model domain as-is and the other subpackages of the model domain to-bepackage is filled with modelling elements and views in the earlier steps of the process.

C.1. INCOSE Object-Oriented Systems Engineering Method 123

C.1.2. Analyze Stakeholder NeedsDuring this step the domain as-is is modeled, focusing on the points to be improved. The missionrequirements and measurements of effectiveness need to be defined. These will dictate the preciseimprovement points and how good the new system needs to perform. The measurements of effective-ness are important to determine how good a system is reaching certain requirements or goals.

With these created mission requirements the domain to-be structure can be modeled (in the modeldomain to-be package). Important is to not model any design possibilities but with what and who thenew system is connected in the new domain. In OOSEM the system of interest is modeled as a singleblock in the BDD of the structure with the custom ”system of interest” stereotype. By modelling thesystem as a single block at this stage, no design options can be forced into the model, but iteration ona more detailed level can be performed later on (using IBD for example).

Once the domain to-be structure is created, time can be spend on modelling use cases that thestakeholders want for the entire domain, with the system of interest being the ”glue” to satisfy eventuallythe use cases. These use cases are stored in the use case sub directory of the model domain to-bepackage.

C.1.3. Define System RequirementsAt this stage of the process the enterprise use cases created need to be refined. Lower level re-quirements and functions of the system are defined by refining these requirements, which is done bycreating activity diagrams of the different use cases. In these activity diagrams the actions and activitiesbetween different domain elements needed for each case are created and displayed.

During this step the beginning of flow, input and output specifications need to be defined. This isto define what kind of flow or signal connect different, at this point functional, elements in the model.The flow specifications and input and output specifications are stored in separate packages in themodel domain to-be/interface definition subpackage. Modelling these specifications ensures that thecomponents are connected correctly and allows for verification of the model.

C.1.4. Define Logical ArchitectureOOSEM uses separate logical and physical system composition. To accomplish this two subclasses ofthe system are created, one for the logical composition and one for the physical composition. Logicalcomponents have the «logical» stereotype. There are three logical classes: external interface com-ponents, application components, and infrastructure components. Operations of the logical block areinherited from the (system of interest) block. The logical decomposition has activity diagrams to definethe internal operations. They have the same in- and output ports as in the domain activity diagrams forthe (system of interest) lane in those activity diagrams.

IBDs are created to link the internal logical connections. Ports on the outer logical block correspondto the ports of the system in the domain context.

Specifications of each logical block need to be defined. Actions in the activity diagram are translatedto operations for that particular block. Controller behavior is often complex, which applies to moreapplication components that hold the business logic. It is desirable to have state-machines that showthe states and behavior of these components. This is because the behavior depends on the state ofthe component or system.

C.1.5. Synthesize Candidate Allocated ArchitecturesThe creation of candidate architectures is done in three parts. First partitioning criteria are defined.Followed by defining logical nodes and then the physical node architecture is created.

Define Partitioning Criteria Partitioning criteria are made to group components that are designed inthe following parts. By partitioning components, a coherent system that is easy to update is created.A near unlimited number of criteria for partitioning can be created, some examples are: componentshaving the same update rate, partitioning in repositories with the same security level [14].

Define Node Logical Architecture At this point the global logical architecture is defined and criteriato group components that have been defined. The first step is followed by the definition of the nodearchitectures. Friedenthal describes a node as follows: “A node often represents a partitioning of

124 C. Current Methodologies and Evaluation Criteria

components and associated functionality, control, and persistent data based on the physical locationof the components.” [14] ”In OOSEM, a logical node represents an aggregation (or set) of logicalcomponents at a particular location. A physical node represents an aggregation (or set) of physicalcomponents at a particular location.” [14] Traditionally, a node location is a larger physical place likea house or an airplane. Logical nodes are assigned the «node logical» stereotype. Logical nodesare part of the node physical block which in turn is a subclass of the overall system of interest. Oftennew interfaces are needed on each node to communicate with other nodes. These interfaces are notdefined before creating the nodes because the system is treated as one instance without nodes before.A logical node is partitioned in multiple logical components using BDDs.

Activity diagrams show the activities these nodes need to perform. These activities are the sameas or part of the previously defined behavior of the system. The logical node activity diagrams showhow the logical components of the node are connected and behave in these defined cases. IBDs arecreated for each node to show the connection of interfaces. The logical node is an internal block of theIBD the ports on the edge of the IBD are the ports of the system. This means that it is not necessaryfor a single logical node to connect with every edge port. It is however required that all the IBDs,representing each logical node, together connect to each outside port of the system. This is needed tomake sure that the more detailed model behaves as defined earlier on a higher level of modelling. TheIBD also show connections interfaces to connect to other nodes. In summary, the activity diagramsshow which components in the different nodes are connected while the IBDs show the ports.

Define Node Physical Architecture After the allocation of logical components in logical nodes it istime to start with allocating the logical components and nodes to physical components and nodes. Sim-ilar to the decomposition of logical nodes, the node physical block, a subclass of the high level systemof interest, is decomposed in physical nodes having the «node physical» stereotype. Trade-off analy-sis is performed and enforced as part of the allocation of logical components to physical components.Design constrains such as using Commercial Of The Shelf (COTS) components, legacy componentsused in earlier versions of the system or others defined in the requirements phase are used as wellduring the allocation phase.

Alternatives are created by allocating logical components to different physical components. Trade-off on different Measure Of Effectiveness (MOE) is needed to select the best option.

When a logical component is allocated to a software component, it is important that this softwarecomponent must be allocated a hardware component to run on. This also counts for persistent datathat needs to be stored on hardware storage.

Allocation tables that allocate logical components to hardware and software components can nowbe created to show the allocation. Similar tables for the allocation of software on hardware componentscan be made after.

When the allocation trade-off studies have resulted in the preferred allocation of logical to physicalcomponents, the composition of these components into physical nodes can be created using BDDs.Each component has a stereotype applied to it, indicating what kind of physical component it is. Ex-amples of these stereotypes are for instant «hardware» and «software».

After the composition diagrams, activity diagrams are created which indicate the behavior of thephysical components. These activity diagrams must display the same behaviors as defined in the log-ical and node logical diagrams of the system, including the inputs and outputs of the diagram. Similarto the node logical IBDs, the node physical IBDs show the internal connections of the node, connectingall components. The same principles discussed in the node logical architecture paragraph, apply to thenode physical IBDs. However, on these IBDs, the allocation of the software components to hardwarecomponents is also shown. Another difference to the node logical IBDs is the use of physical portson the edges of each IBD. Every physical IBD represents the node physical blocks’ internal structure.Different diagrams show different parts of the overall system. This is the reason every IBD has thesame edge ports. However, while these ports have the same name they do not have the same typeas for the logical architecture and the node logical architecture. This is because at this point the modelrepresents physical components whereas before everything modeled was logical components. The dif-ficulty arises in the inheritance and allocation. The physical edge ports correspond to the logical ports.Defining the logical ports as a multiplicity of 0..1 is an option to allow the connection between logicaland physical ports. Each physical port is still connected to the logical part but redefining the multiplicity

C.2. Catalogue of System and Software Properties 125

of the logical part as 0 and redefining a new part is a valid modeling solution for this problem. A sec-ond option is to have logical ports and physical ports defined in the black box specification of the system.

The node physical design package inside the system of interest package holds all the componentsand diagrams. Inside this package a structure and a behavior folder is created to store the correspond-ing information. Besides these two folders, folders for each node are present in this package eachholding requirements and structure data which again is structured in hardware, software, persistentdata, procedures, and internal operations. These packages stores all the related components. Ad-ditional methods, such as the use of Unified Modelling Language (UML) for software development orComputer-Aided Design (CAD) programs for hardware design, not described by OOSEM can be usedto refine these components even further.

The last step in the OOSEM method is the specification of component requirements. These com-ponent requirements specifications are the final artifacts produced by the design method. Similar tothe systems black box specification, a black box specification is created for each component: software,hardware, data, or procedure. Each component black box describes the components operations andinterfaces. Hardware components also have properties added to them such as mass, which is usedduring component trade-off studies to determine the optimal product for the component. Interfacesto the component are represented by ports specifying the protocol- (hardware components) or signalinterfaces (software components).

C.2. Catalogue of System and Software PropertiesBos, Bruintjes, and Tonetta describe the Catalogue of System and Software Properties (CSSP) intheir paper [4]. Specifying formal properties is a difficult task due to ambiguity of textual requirements.CSSP derives a set of design attributes from European Cooperation for Space Standardization (ECSS)requirements specifications. Bos et al. classify requirements found in various ECSS documents in fivecategories:

1. Context requirements

2. Configuration requirements

3. Interface requirements

4. Functional requirements

5. Quality requirements [4]

Context requirements define the context the system will operate in, such as assumptions of theenvironment or processor power and clock speed for software systems.

Configuration requirements describe the configuration of the system. For space systems configu-ration requirements specify the different subsystems such as Power subsystem, thermal subsystem,and ADCS subsystem.

Interface requirements define in input and output interfaces of a system, what data is required andprovided.

Functional requirements define what should be done by the system. Functional requirements canbe categorized in subcategories, these subcategories are:

1. Input/output functional requirements

2. Mode requirements

3. Data handling requirements

4. Monitoring requirements

5. Operational requirements [4]

126 C. Current Methodologies and Evaluation Criteria

Quality requirements define how good the system should perform, including characteristics the sys-tem should have for active stakeholders to perform their job using the system. Quality requirementsare sub-categorized as well:

1. Performance requirements

2. Dependability requirements

3. Reliability requirements

4. Availability requirements

5. Maintainability requirements

6. Safety requirements

CSSP extracts design attributes for each requirements type and maps it to AADL architectures andproperties.

Bibliography[1] David Alexander, Soroush Sadeghain, Thomas Saltysiak, and Siroos Sekhavat. Quicklook final

report Version 1.19. Technical report, Tactical Science Solutions, Inc., 2007.

[2] Louise Anderson, Bjorn Cole, Rose Yntema, Manas Bajaj, Sara Spangelo, David Kaslow, Christo-pher Lowe, Eric Sudano, Mary Boghosian, Robin Reil, Sharan Asundi, and Sanford Frieden-thal. Enterprise modeling for CubeSats. IEEE Aerospace Conference Proceedings, 2014. ISSN1095323X. doi: 10.1109/AERO.2014.6836343.

[3] Todd Bayer, Seung Chung, Bjorn Cole, Brian Cooke, Frank Dekens, Chris Delp, Ivair Gontijo, KariLewis, Mehrdad Moshir, Robert Rasmussen, and David Wagner. Early Formulation Model CentricEngineering on NASA’s Europa Mission Concept Study. 2012.

[4] Victor Bos, Harold Bruintjes, and Stefano Tonetta. Catalogue of system and software properties.Proc. of the 35th Int. Conf. on Computer Safety, Reliability and Security (SAFECOMP), 9922 LNCS(4000111828):88–101, 2016. ISSN 16113349. doi: 10.1007/978-3-319-45477-1_8.

[5] M. Bozzano, H. Bruintjes, V.Y. Nguyen, T. Noll, and S. Tonetta. SLIM 3.0 - Syntax and Semantics.Technical report, RWTH Aachen, Fondazione Bruno Kesseler, 2016.

[6] Barclay Brown and IBM Rational. Model-Based Systems Engineering : Revolution or Evolution?(December), 2011.

[7] Harold Bruintjes, Joost-pieter Katoen, and David Lesens. A Statistical Approach for Timed Reach-ability in AADL Models. 2015.

[8] Robert Cloutier and Mary Bone. Compilation of SysML RFI- Final Report. Technical report,Stevens Institute of Technology, 2010.

[9] Bjorn Cole, Chris Delp, and Kenny Donahue. Piloting model based engineering techniques forspacecraft concepts in early formulation. JPL and INCOSE. July, 2010.

[10] Consortium COMPASS. COMPASS Correctness, Modeling and Performance of Aerospace Sys-tems, 2016. URL http://www.compass-toolset.org/.

[11] ESA. Statement of Work Model-based Software Development Lifecycle. 31(1):1–16, 2012.

[12] JA Estefan. Survey of Model-Based Systems Engineering (MBSE) Methodologies. Technicalreport, ModelBased Systems Engineering (MBSE) Initiative International Council on Systems En-gineering (INCOSE), 2008.

[13] P H Feiler. Model-based validation of safety-critical embedded systems. 2010 IEEE AerospaceConference, pages 1–10, 2010. ISSN 1095-323X. doi: 10.1109/AERO.2010.5446809.

[14] Sanford Friedenthal, Alan Moore, and Rick Steiner. A practical guide to SysML: The systemsmodeling language. 2008. ISBN 0123743796.

[15] Alfredo Garro, Johannes Groß, Marius Riestenpatt gen. Richter, and Andrea Tundis. Reliabilityanalysis of an Attitude Determination and Control System (ADCS) through the RAMSAS method.Journal of Computational Science, 5(3):439–449, 2014. ISSN 18777503. doi: 10.1016/j.jocs.2013.06.003. URL http://dx.doi.org/10.1016/j.jocs.2013.06.003.

[16] Matthew Hause. The SysML Modelling Language. Fifteenth European Systems EngineeringConference, (September):12, 2006.

127

128 Bibliography

[17] Qinglei Hu, Bing Xiao, and Yuomin Zhang. Fault-Tolerant Attitude Control for Spacecraft UnderLoss of Actuator Effectiveness. Journal of Guidance, Control, and Dynamics, 34(3):927–932,2011. ISSN 0731-5090. doi: 10.2514/1.49095. URL http://arc.aiaa.org/doi/abs/10.2514/1.49095.

[18] Dustin B. Jepperson. Using Model Based Systems Eegnineering and the Systems Modeling Lan-guage to Develop Space Mission Area Architectures. PhD thesis, Naval Postgraduate School,2013.

[19] A. Jung, M. Verhoef, and M. Perrotin. Model-based System and Software Engineering – FutureDirections. (December), 2016.

[20] David Kaslow, Grant Soremekun, Hongman Kim, and Sara Spangelo. Integrated model-basedsystems engineering (MBSE) applied to the Simulation of a CubeSat mission. IEEE AerospaceConference Proceedings, (April 2007), 2014. ISSN 1095323X. doi: 10.1109/AERO.2014.6836317.

[21] David Kaslow, Louise Anderson, Curtis Iwata, Sharan Asundi, Bradley Ayres, and Robert Thomp-son. Developing and Distributing a CubeSat Model-Based Systems Engineering (MBSE) Refer-ence Model. 2015.

[22] Fondazione Bruno Kessler. Compass Tutorial. Compass, pages 1–85, 2016.

[23] Fondazione Bruno Kessler. Correctness, Modeling, and Performance of AeroSpace SystemsManual. pages 0–143, 2016.

[24] Dorus De Lange, Jian Guo, and HPDe Koning. Applicability of SysML to the Early Definition Phaseof SpaceMissions in a Concurrent Environment. Complex Systems Design &Management, pages1–12, 2012.

[25] Sanda Mandutianu. Modeling Pilot for Early Design Space Missions. 7th Annual Conference onSystems Engineering Research 2009 (CSER 2009), 2009(April), 2009.

[26] SMazzini, E Tronci, C Paccagnini, and XOlive. AModel-Basedmethodology to support the SpaceSystem Engineering (MBSSE). pages 1–8, 2010.

[27] MBSE Wiki Metrics and Methodologies. Additional Methodologies Identified as GapsSince 2008 INCOSE Survey. URL http://www.omgwiki.org/MBSE/doku.php?id=mbse:methodology.

[28] Viet Yen Nguyen. Trustworthy Spacecraft Design Using Formal Methods. PhD thesis, RWTHAachen, 2013.

[29] Thomas Noll. Formal Techniques for Safety-Critical Systems. 476:125–141, 2015.doi: 10.1007/978-3-319-17581-2. URL http://link.springer.com/10.1007/978-3-319-17581-2.

[30] Dustin Nottage and Steve Corns. Application of model-based systems engineering on a universitysatellite design team. Procedia Computer Science, 8:207–213, 2012. ISSN 18770509. doi:10.1016/j.procs.2012.01.044.

[31] OMG. OMG Unified Modeling Language Specification. Management, (June), 1999. URL http://www.omg.org/spec/UML/1.3/PDF.

[32] OMG. UML for Systems Engineering. Request for Proposal. Ad/03-03-41, pages 1–56, 2003.URL http://syseng.omg.org/UML_for_SE_RFP.htm.

[33] Christiaan J.J. Paredis, Carlee Bishop, Douglas Bodner, and Paul R. Montgomery. Model-BasedSystem Integration (MBSI) – Key Attributes of MBSE from the System Integrator’s Perspec-tive. Procedia Computer Science, 16:313–322, jan 2013. ISSN 18770509. doi: 10.1016/j.procs.2013.01.033. URL http://www.sciencedirect.com/science/article/pii/S1877050913000343.

Bibliography 129

[34] Payscale. Aerospace Engineer Salary, . URL http://www.payscale.com/research/US/Job=Aerospace_Engineer/Salary.

[35] Payscale. Sr. Software Engineer / Developer / Programmer Salary, . URL http://www.payscale.com/research/US/Job=Sr._Software_Engineer_/_Developer_/_Programmer/Salary.

[36] Payscale. Software Developer Salary, . URL http://www.payscale.com/research/US/Job=Software_Developer/Salary.

[37] Payscale. Space Systems Engineer Salary, . URL http://www.payscale.com/research/US/Job=Space_Systems_Engineer/Salary.

[38] Raul Polit-Casillas and A. Scott Howe. Virtual construction of space habitats: Connecting BuildingInformation Models (BIM) and SysML. AIAA SPACE 2013 Conference and Exposition, pages 1–19, 2013. doi: 10.2514/6.2013-5508.

[39] Matthew Russell and Jeremy Straub. Software Design for an Intelligent Attitude Determinationand Control System. Research Experience for Undergraduates Poster Session at the AIAA/USUConference on Small Satellites, 2015.

[40] Salary.com. Aerospace Engineer V Salary. URL http://swz.salary.com/SalaryWizard/Aerospace-Engineer-V-Salary-Details.aspx?&fromevent=swz.jobdetails.freepop.

[41] Sara C. Spangelo, David Kaslow, Chris Delp, Bjorn Cole, Louise Anderson, Elyse Fosse,Brett Sam Gilbert, Leo Hartman, Theodore Kahn, and James Cutler. Applying model based sys-tems engineering (MBSE) to a standard CubeSat. IEEE Aerospace Conference Proceedings,pages 1–20, 2012. ISSN 1095323X. doi: 10.1109/AERO.2012.6187339.

[42] Sara C. Spangelo, James Cutler, Louise Anderson, Elyse Fosse, Leo Cheng, Rose Yntema,Manas Bajaj, Chris Delp, Bjorn Cole, Grant Soremekum, and David Kaslow. Model basedsystems engineering (MBSE) applied to Radio Aurora Explorer (RAX) CubeSat mission oper-ational scenarios. IEEE Aerospace Conference Proceedings, 2013. ISSN 1095323X. doi:10.1109/AERO.2013.6496894.

[43] John C. Springmann and James W. Cutler. Flight results of a low-cost attitude determinationsystem. Acta Astronautica, 99(1):201–214, 2014. ISSN 00945765. doi: 10.1016/j.actaastro.2014.02.026. URL http://dx.doi.org/10.1016/j.actaastro.2014.02.026.

[44] John C. Springmann, Alexander J. Sloboda, Andrew T. Klesh, MatthewW. Bennett, and JamesW.Cutler. The attitude determination system of the RAX satellite. Acta Astronautica, 75:120–135,2012. ISSN 00945765. doi: 10.1016/j.actaastro.2012.02.001. URL http://dx.doi.org/10.1016/j.actaastro.2012.02.001.

[45] Kevin Vipavetz, Douglas Murphy, and Samantha Infeld. Model-Based Systems Engineering PilotProgram at NASA Langley. (September):1–18, 2012. doi: 10.2514/6.2012-5165.

[46] Sasi Prabhakaran Viswanathan, Amit Sanyal, and Maziar Izadi. Mechatronics Architecture ofSmartphone-Based Spacecraft ADCS using VSCMG Actuators. 2015.

[47] Tim Weilkiens. Systems Engineering with SysML/UML. 2007. ISBN 9780123742742. doi: 10.1016/B978-0-12-374274-2.00001-8.

[48] James R. Wertz. Spacecraft Attitude Determination and Control. 1978. ISBN 978-90-277-1204-2.doi: 10.1007/978-94-009-9907-7.