Verification of SysML Models using Hybrid-Testbeds with Model-in-the-Loop Simulations

Verifikation von SysML-Modellen in einer hybriden Testumgebung mittels Model-in-the-Loop Simulationen

Master Thesis

by Praveen Kumar Ramachandran

August 12, 2020

Technische Universit¨atKaiserslautern, Department of Computer Science, 67653 Kaiserslautern, Germany

University Supervisor: Prof. Dr. KLAUS SCHNEIDER University Co-Supervisor: M.Sc. MARTIN KOHLER¨ Project Manager (DB): Mr. RALPH R MULLER¨ Project Supervisor (DB): Mr. RANDOLF BERGLEHNER Statutory Declaration

I, Praveen Kumar Ramachandran, declare that this thesis titled, ”Verification of SysML Models using Hybrid-Testbeds with Model-in-the-Loop Simulations” and the research presented in it are my own. I confirm that this work was done wholly while in candidature for a research degree at this University. All the points taken from the published and unpublished writings are cited as such.

Kaiserslautern, 12.8.2020

Praveen Kumar Ramachandran

ii Acknowledgements

I would like to express my gratitude to everyone who has helped me during my master thesis.

First of all, I would like to express my sincere gratitude to Prof. Dr. Klaus Schneider, my supervisor from the Department of Computer Science, Technical University of Kaiserslautern. I am sincerely thankful for his support and patience the entire time regarding doubts-clearing and answer- ing my questions. I would also like to extend my gratitude to M.Sc.Martin K¨ohler from the same department who is the co-supervisor for my thesis work.

I would also like to thank the experts from (Deutsche Bahn Netze AG), who were involved in validating my research work throughout the process:

Project manager: Mr. Ralph R M¨uller Project supervisor: Mr. Randolf Berglehner

Without their guidance and support, the research work could not have been successfully conducted.

Thank you

Praveen Kumar Ramachandran

iii “IoT has a total potential economic impact of $3.9 (3.18243e) trillion to $11.1 (9.05782e) trillion a year by 2025.”

–McKinsey & Company Abstract

Model-based systems engineering (MBSE) has been widely used in several domains such as aviation, automotive, and railways. This approach allows for checking the complete- ness of the requirements, checking for dead ends, and run- ning the simulations. In the European railways, EULYNX is used to standardize the architecture of technical signal- ing interfaces. In the current approach from DB Netz AG, EULYNX specification models of standardised system in- terfaces are created using SysML. They are verified and validated by means of simulation-based model testing. The tests are performed by Infrastructure managers based on the assumptions of real environment the final application has to be embedded upon. Although the simulation imi- tates the system’s intended behavior, it cannot detect all possible errors. Also, the behavior of the real hardware in the real-world is not entirely reflected in the model. For this reason, the specification model already should be em- bedded and tested within this real environment. In the scope of this master thesis, a different approach to ver- ify and validate executable SysML specification models is presented. Along with this, the modeling approach using SysML for the railway ”subsystem Point” (EULYNX) is presented. The model is tested on a hybrid testbed that involves the standard SySim test platform and the GUI. We achieve this by using IoT Platform - ThingWorx which helps us to develop a hybrid testbed to test the model. The behavior of the model is verified against the GUI, which reflects the behavior of the real hardware. Research and analysis of the integration of the developed model with the end-to-end technology Industrial Internet of things plat- form (IIoT) is carried out. Within this thesis, we consider a simpler model of the railway ”subsystem Point” to reduce the modeling complexities and integrate with other plat- forms. Later, results from the test cases that are created to check if it satisfies the intended behavior are discussed.

v Zusammenfassung

Modellbasiertes System-Engineering (MBSE) ist in ver- schiedenen Bereichen wie der Luftfahrt, der Automobil- und der Eisenbahnindustrie weit verbreitet. Dieser Ansatz erm¨oglicht es, die Vollst¨andigkeit der Anforderungen zu ¨uberpr¨ufen, Sackgassen zu erkennen und Simulationen durchzuf¨uhren. Bei den europ¨aischen Bahnen wir zurzeit im Rahmen der Initiative EULYNX eine Standardisierung der Architektur von Eisenbahnsignalsystemen und der rel- evanten Systemschnittstellen durchgef¨uhrt. Sie werden durch simulationsgest¨utzteModellversuche verifiziert und validiert. Die Tests werden von den Infrastrukturbe- treibern auf der Grundlage von Annahmen bez¨uglich der realen Umgebung durchgef¨uhrt,in die die endg¨ultigeAn- wendung eingebettet werden muss. Obwohl die Simulation das beabsichtigte Verhalten des Systems imitiert, kann sie nicht alle m¨oglichen Fehler erkennen. Auch das Verhalten der realen Hardware in der realen Welt wird im Modell nicht vollst¨andigwiedergegeben. Aus diesem Grund sollte das Spezifikationsmodell bereits in dieser realen Umgebung eingebettet und getestet werden. Im Rahmen dieser Mas- terarbeit wird der EULYNX-Ansatz zur Verifikation und Validierung ausf¨uhrbarerSysML Spezifikationsmodelle er- weitert. Parallel dazu wird der Modellierungsansatz mit SysML f¨urdas Eisenbahn- ”Subsystem Weiche” (EUL- YNX) vorgestellt. Das Modell wird auf einem hybriden Testbed getestet, das die Standard-Testplattform SySim und die reale Systemumgebung, emuliert durch eine GUI, umfasst. Wir erreichen dies durch die Verwendung der IoT-Plattform - ThingWorx, die uns bei der Entwick- lung eines hybriden Testbeds zum Testen des Modells hilft. Das Verhalten des Modells wird gegen die GUI verifiziert, die das Verhalten der realen Hardware wider- spiegelt. Forschung und Analyse der Integration des en- twickelten Modells mit der End-to-End-Technologie Indus- trial Internet of Things Platform (IIoT) wird durchgef¨uhrt. Im Rahmen dieser Arbeit betrachten wir ein einfacheres Modell des Eisenbahn-”Subsystems Point”, um die Kom- plexit¨atder Modellierung zu reduzieren und die Integration mit anderen Plattformen zu erm¨oglichen. Sp¨aterwerden Ergebnisse aus den Testf¨allendiskutiert, die erstellt wer- den, um zu ¨uberpr¨ufen, ob es das beabsichtigte Verhalten erf¨ullt.

vi Contents

List of Figures ix

List of Tables xiii

Abbreviations xv

1. Introduction1 1.1. Context...... 1 1.2. Motivation (Problem Area)...... 1 1.3. Thesis Statement and Contributions...... 3 1.4. Outline...... 3

2. Related Work5

3. Background7 3.1. Model-based Systems Engineering...... 7 3.1.1. Modeling using SysML...... 9 3.1.2. Verification and Validation...... 12 3.2. X-in-the-loop Testing...... 14 3.2.1. Model-in-the-loop...... 15 3.2.2. Software-in-the-loop...... 16 3.2.3. Hardware-in-the-loop...... 16 3.3. Hybrid Testbed...... 16 3.4. Internet of Things...... 18 3.4.1. IoT...... 18 3.4.2. Industrial Internet of Things...... 19 3.4.3. Applications/Tools used...... 21 3.4.3.1. Integrity Modeler...... 22 3.4.3.2. DOORS...... 22 3.4.3.3. SySim...... 22 3.4.3.4. ThingWorx...... 22 3.4.3.5. KepServerEX...... 23 3.4.3.6. GraphWorx64...... 23

4. Methodology - Railway Principles of Safety 25 4.1. Safety-critical Systems...... 25 4.1.1. EULYNX...... 26 4.2. Railway Signaling...... 28 4.2.1. Track Segment...... 30 4.2.2. Point/Turnout...... 31 4.2.3. Crossing...... 32

vii Contents

4.2.4. Interlocking...... 32 4.2.5. Railway Standards...... 34

5. Methodology - MiL Architecture 35 5.1. Model-in-the-loop Architecture...... 35 5.1.1. SysML Model Setup...... 36 5.1.2. Connecting SySim with ThingWorx Elements...... 46 5.1.3. Connecting GUI with ThingWorx using TIC...... 49 5.1.4. Connecting GUI to KEPServerEX...... 53 5.1.5. ThingWorx Mashup Build...... 58

6. Results - Simulation and Testing 67 6.1. Model Simulation on Hybrid Testbeds...... 67 6.1.1. GUI Simulation...... 67 6.1.2. SySim Model Execution...... 70 6.1.3. Mashup Visualization...... 78 6.2. Model Verification - Test Cases...... 80

7. Conclusion and Future Work 87 7.1. Conclusion...... 87 7.2. Future Work...... 88 7.3. Personal Thoughts...... 89

Bibliography 91

A. Visual Studio Code 101

B. Modeler Blocks 103

C. SySim Simulation 107 C.1. Scenario - No End Position...... 107

viii List of Figures

3.1. The approach of MBSE in brief...... 8 3.2. Relationship between UML and SysML...... 10 3.3. An example - Internal block diagram...... 11 3.4. V-model...... 13 3.5. Overview of the model validation steps...... 13 3.6. MiL testing in comparison with SiL and HiL...... 15 3.7. Hybrid Testbed overview...... 17 3.8. IoT and its application cluster...... 19 3.9. IIoT as a subset of IoT...... 20 3.10. Industrial railway sector...... 21

4.1. A generic approach to ensure safety...... 27 4.2. EULYNX System Architecture...... 29 4.3. A Railway signaling system...... 30 4.4. Track...... 30 4.5. Point machine...... 31 4.6. Point Variations...... 31 4.7. Types of Crossings...... 32 4.8. Railway Interlocking system in operation...... 33

5.1. Overview of the MiL approach with the integration of an IoT platform...... 36 5.2. Input and output ports of the ”PM” block...... 37 5.3. Input and output ports of the ”IXL” block...... 37 5.4. ”SySim DataTypes” profile in the Modeler...... 38 5.5. Internal Block diagram of ”subsystem Point”...... 39 5.6. Internal Block diagram of Interlocking...... 40 5.7. States of the block ”PM”...... 40 5.8. ”Events” that trigger the state machine...... 41 5.9. States of the block ”IXL”...... 42 5.10. State diagram of ”subsystem Point”...... 43 5.11. State diagram of Interlocking...... 44 5.12. ”Cmd” proxy port as an interface between ”PM” & ”IXL”.. 44 5.13. Simulation block of ”subsystem Point” and Interlocking interface 45 5.14. TWx block for ”Left” pushbutton...... 46 5.15. TWx block for ”Right” pushbutton...... 46 5.16. Assigning operation-”SetValue” to the TWx buttons...... 47 5.17. ”TWx Pushbuttons” replacing the simulation buttons..... 47 5.18. ThingWorx login credentials...... 49 5.19. ThingWorx Config.XML file...... 49

ix List of Figures

5.20. ThingWorx server interface to establish the connection..... 50 5.21. ”Connected to ThingWorx” event...... 50 5.22. ”Store and Forward” datastore in TWx Native Interface.... 51 5.23. Subscription info for ”LeftThing” with Script...... 52 5.24. Subscription info for ”RightThing” with Script...... 52 5.25. A digital Interlocking by HIMA...... 54 5.26. ”Buttons” created as tags in Kepware...... 54 5.27. Creating a database to connect...... 55 5.28. ”Successful” OPC connection...... 55 5.29. A ”Process point” entry with value ”0”...... 56 5.30. A ”Process point” entry with value ”1”...... 56 5.31. GUI emulating the operations of PLC...... 57 5.32. Tags for ”synchronous write” in OPC Quick client...... 58 5.33. Overview of entities in ThingWorx...... 59 5.34. Button1 denoting the ”Left” Point with Status display..... 61 5.35. Button2 denoting the ”Right” Point with Status display.... 61 5.36. Binding ”GetProperties” service to the Buttons...... 61 5.37. Adding ”SetProperties” service to the Buttons...... 62 5.38. Connection of ”SetProperties” service with the mashup.... 62 5.39. Connection of ”GetProperties” property with the mashup... 63 5.40. ”Setvalue” service assigned to ”LeftThing” and ”RightThing”. 64 5.41. ”Expression” service in script...... 64 5.42. ”ConvertButton1” expression added as a service to ”LeftThing” 65 5.43. ”ConvertButton2” expression added as a service to ”RightThing” 66

6.1. Testing on Hybrid Testbed...... 68 6.2. Command property ”True” for button ”Turn Left”...... 68 6.3. Command property ”True” for button ”Turn Left”...... 68 6.4. Command property ”True” for button ”Turn Left”...... 69 6.5. Command property ”True” for button ”Turn Right”...... 70 6.6. Command property ”False” for button ”Turn Right”...... 70 6.7. Command property ”True” for button ”Turn Right”...... 71 6.8. SySim simulator block to execute the models...... 72 6.9. Simulator displaying the status ”Left”...... 73 6.10. Animation of Point changing to ”Left” state...... 74 6.11. Simulator displaying the status ”Right”...... 75 6.12. Animation of IXL state ”Get Status”...... 75 6.13. Animation of Point changing to ”Right” state...... 76 6.14. Output log of the animation of state machines...... 77 6.15. Entities involved in this Project...... 78 6.16. Services in Mashup dashboard...... 80

A.1. An excerpt from the auto-generated VB code...... 101

B.1. System simulation block ready for visualization...... 104 B.2. BDD of System design with TWx blocks...... 105

x List of Figures

C.1. Simulator displaying the status ”NoEndposition”...... 107 C.2. Transition to the state ”NoEndposition”...... 108

xi

List of Tables

4.1. Fatalities in different transportation mode...... 25 4.2. Classification of safety-critical systems based on SIL levels... 26

5.1. Transitions from the state “No End Position”...... 40 5.2. Transitions from the state “Left”...... 41 5.3. Transitions from the state “Right”...... 41 5.4. ”When” conditions for the state “No End Position”...... 42 5.5. ”When” conditions for the state “Left”...... 42 5.6. ”When” conditions for the state “Right”...... 42 5.7. Associated events and their actions for “IXL”...... 42 5.8. Signal-type triggers associated between ”PM” and “IXL”... 42 5.9. Mashup entities created for “PM”...... 52

xiii

Abbreviations

DB Deutsche Bahn Netz AG SysML Systems Modeling Language UML Unified Modeling Language MBSE Model-Based Systems Engineering MDE Model-Driven Engineering BDD Block Definition Diagram IBD Internal Block Diagram SMD State Machine Diagram CENELEC European Committee for Electrotechnical Standardization OMG Object Management Group V&V Verification and validation XiL X-in-the-Loop MiL Model-in-the-Loop HiL Hardware-in-the-Loop SiL Software-in-the-Loop EULYNX European initiative to standardise interfaces and elements of the signalling systems. IoT Internet of Things IIoT Industrial Internet of Things PLC Programmable Logic Controller EU European Union GoA Grades of Automation SIL Safety Integrity Level PFD Probability of dangerous Failure on Demand RRF Risk Reduction Factor SCS Safety Critical Systems FTA Fault Tree Analysis FMEA Failure Modes and Effects Analysis IM Infrastructure Manager SCI Standard Communication Interfaces SCI-LS Standard Communication Interface-Light signal

xv Abbreviations

SCI-P Standard Communication Interface-Point SCI-LX Standard Communication Interface-Level Crossing SCI-TDS Standard Communication Interface-Train Detection Systems IXL Railway Interlocking DSTW Digitales Stellwerk OC Object Controller GUI Graphical User Interface OPC UA Open Platform Communications United Architecture PM Point Machine TIC ThingWorx Industrial Connectivity TCG Test Case Generation VB Visual Basics TWx ThingWorx

xvi 1. Introduction

This chapter introduces the project by briefly revealing the context and the goals of the project. The contributions section gives an overview of the main topics involved in this project. An overview of the structure of this report is provided in the section Outline.

1.1. Context

The project “Verification of Systems Modeling Language (SysML)-models us- ing Hybrid testbed with Model-in-the-Loop simulations” was conducted by Praveen Kumar Ramachandran, as his final Master Thesis for the master’s degree program - Commercial vehicle technology. This program is offered by the graduate school-CVT from the Technical University of Kaiserslautern. This project was initiated by Deutsche Bahn Netz AG (DB), a company that is responsible for the German railway infrastructure. A railway signaling system is one of the main components in the infrastructure used to control railway traffic and provide safety. This includes preventing trains from collisions and derailment [Bui17]. One of the approaches to improve safety is by standardiz- ing and harmonizing the interfaces. The primary objective of EULYNX, which is an initiative in the area of railway signaling, is based on these parameters. A detailed explanation about this is presented in the section EULYNX. Mod- eling generally allows us to see the abstract behavior of the system. Thus the extracted model, including the simulation model, will have only some bearing on the real-life system provided it is represented good [Hil03]. The whole idea behind carrying out the verification and validation process involves doing the right things right. A detailed explanation about this is presented in the section Verification and Validation.

1.2. Motivation (Problem Area)

Evolving technologies today offer us many opportunities and advantages to comply with and adapt to. In the railway sector, especially, there are many opportunities to make use of the advancing technology. Some topics in the technologies include Cyber-security, capabilities of using Big data, enabling cloud platforms, and using Internet of Things. There is already enough expo- sure of railways to such advancements in the scope of Automated traffic man- agement, Automated train operations, automated train protection systems, and more. [AML19] The current endeavor of European railways is to adapt to ETCS (European Train control system) with the evolving telecommunication technology. Emerging innovative solutions such as these increase safety of the

1 Chapter 1: Introduction system, enables high-speed connectivity between different systems, increases efficiency, reduces risk by a considerable factor, mainly the risk of human- actors within the system, and enables the harmonization and standardization of distributed components in the system. Systems engineering plays a vital part in the early-developmental stages of any industry. This interdisciplinary engineering approach allows the system engineers to design, integrate, and manage complex systems, including their sub-systems, over their entire life- cycle. The industries that have been adapting to this newer approach by letting go of their traditional process-driven approach have improved func- tionality throughout the process [Kin16]. These improvements also bring in complex systems that have interactions with greater sub-systems. It has led to the need for quality system-engineering approaches that can be used in the development and integration of complex systems. The development process includes understanding the operational needs, analyzing the requirements, de- signing the model, and testing to deploy it. In this thesis work, we focus on developing the model and testing it to ensure the model fulfills the intended behavior with no errors. The testing is carried out on a hybrid testbed, which provides us with an accurate model without any faulty behavior. The motive of this thesis is to improve safety in railway operations by testing the model for its optimal operational behavior. This thesis’ primary goal is to develop and demonstrate an advanced rail- way specification approach by developing the SysML model and integrating the model with an IoT platform to maximize the quality of railway interface specifications. Also, to ensure safe communication of signals through the in- terfaces specified by EULYNX. The simulation approach currently undertaken by DB Netz AG and other European railways does not suffice for the verifi- cation process. This thesis presents a dynamic modeling approach in which a railway signaling component is tested upon. The objectives of this thesis work are as follows: • Research and analyze the behavior of the railway signaling components: digital Interlocking system and the ”subsystem Point.” • Understand and summarize the importance of safety-critical systems, mainly Control, command, and signaling in railways. • Develop the SysML model of ”subsystem Point” and digital Interlocking on a smaller scale. • Present the testing approach for the developed model in the domain of systems engineering. • Connect the specification model of ”subsystem point” to the GUI which emulates the real interlocking using ThingWorx. • Simulate the model on 2 test platforms, namely: SySim simulator for model behavior and GUI simulator for the intended behavior. • Create test cases and test on the platforms mentioned above as a testing approach on a Hybrid testbed.

2 1.3. Thesis Statement and Contributions

• With all this, also enable connectivity of the SysML model and GUI to KepserverEx using OPC UA standard.

• Formulate the results to visualize the simulation.

1.3. Thesis Statement and Contributions

• We provide a systematic methodology to analyze and verify the op- erational parameters of the ”subsystem Point” in the experimentation model.

• We use the efficient working model of Internet of Things and extend its usage to a new sector - railway signaling, ensuring safety and perfor- mance.

• We combine the methodology of the current modeling framework by EULYNX and the external add-on IoT-platform feature.

• The solution presented to the problem in this thesis can be applied not just specifically to railways, but also to most other domains which focuses on safety-criticality.

• The thesis’ formal analysis tries to prove that the combination of differ- ent approaches with the available new-age-methodologies can be more feasible.

• We provide an insight into the methodology that has not been widely used in the railway domain.

• The approach is demonstrated through experimentation, and the tested results are presented for a better understanding.

• We intend to provide this thesis work as a base for further research works in the domains which facilitate safety, connectivity, performance, and ease-of-use.

1.4. Outline

This thesis is organized into 7 different chapters:

1. Introduction - This chapter presents the context, motivation, and objec- tives of the thesis work. The problem area and the current challenges of the thesis work are described. Detailed goals & objectives are enumer- ated.

2. Related Work - This chapter presents the literature survey on the work done before in this regard. It includes a detailed explanation of the reports of similar work from various domains.

3 Chapter 1: Introduction

3. Background - This chapter is divided into 3 different sub-chapters. The 1st sub-chapter presents the modeling background. This chapter includes a detailed description of the introduction of the verification & validation approach. In the 2nd sub-chapter, testing methodologies are discussed. With this, the x-in-the-loop testing method is introduced. A brief understanding of the use of a hybrid testbed is presented. The 3rd sub-chapter presents the background on Internet of Things (IoT), its advancements into the industries (IIoT), and a brief expla- nation of the applications used in this thesis work.

4. Methodology - Railway Principles of Safety - This chapter is essential in understanding the basics of railway signaling elements. This chapter presents the principles of the operation of the railway interfaces, mainly: ”subsystem Point” and digital Interlocking.

5. Methodology - MiL Architecture - This chapter holds the core work of the thesis. The experimentation procedure is explained. The chapter includes the explanation of the process of developing models, integrating the models in IoT platform, and the development of a simulator.

6. Results - Simulation and Testing - The experimentation results are pre- sented in this chapter. This includes both visualizing the behavior of the model in simulation and also testing it by generating test-cases. The verification of the model is discussed.

7. Conclusion and Future Work - Summarizes the results. The extension and the conclusion of the thesis work are described.

4 2. Related Work

The literature work below summaries the earlier work that has been carried out until now. There has been some significant research conducted earlier in using MBSE for system design, testing the model using the Model-in-the-loop approach, and availing these methodologies in railways to ensure the systems are reliable and safety-critical. On the other hand, nonetheless, there has also been some research work being conducted with IoT for safety and automation, such as enabling IoT for home-applications. It is also used in stadiums with the sensors deployed all around to collect noise, temperature, and humidity [PTC20e]. [Mac18] focuses on combining these various applications from different do- mains and using it in railways to propose a safety and reliable functioning of Point machine. According to [RK18], verification and validation of railway Interlocking tables are done physically and are thus fault-prone and expen- sive. In this study, the authors propose using nuXmv as a modeling tool, and PyNuSMV as a verification tool to verify the safety properties. They also val- idate the developed model through counter-examples and custom CTL model checking algorithms. [LCW19] proposes to adopt the control method of “lock” for the Point, i.e., all trains passing through or switching a Point must first acquire the “lock” of it. According to this study, for formal verification, Simulation is incomplete in validating the model, and formal validation of the model is required by the validator. [Bou+19] proposes an approach consisting of graphical model- ing of systems and automatically generating formal specifications in Event-B. This study performs a model-to-model transformation to generate the Event- B model from the UML class diagram. The proposed approach allows us to formally verify the safety of railway signaling systems based on model checking and animator tool. [Ahm+18] proposes a method capable of controlling the rail gate for the level crossing, which is automated. This approach uses a couple of Sensors connected with Wemos D1 for autonomous rail-gate control with measuring distance and with the ThingSpeak server to control multiple rail gates cen- trally. According to [DVA19], the detailed models cannot be built at the beginning of a development process. The study shows that the Safety-critical complex hybrid systems (CHS) throughout their life-cycles (physical system dynamics and the environment) tend to change due to natural causes. The authors in this study suppose that the Model-based development methods are needed that integrate formal specification, verification, implementation level testing, and run-time validation. They also demonstrate a compositional so- lution approach based on the decomposition and hybridization of state-chart

5 Chapter 2: Related Work models (into hybrid automata-HA). [Ly-+18] propose a hybrid solution that combines the emulated testbed with a small-real world system. The authors set up a real-world system, in- cluding several physical devices available for virtual wireless nodes to connect to and establish data communications. [Boo+19] creates an event-based hy- brid testbed connected to traffic simulators. According to the authors, this Hybrid testbed enables test designers to encode the overall test setup (e.g., nodes and network topologies) and test scenarios (e.g., changing network con- ditions). [Chu+19] propose the advantage of combining virtual and physical network components to make Nextlab as realistic as possible. This approach demonstrates the significance contrary to the trend of using only the simula- tion environment. According to the authors, the integration of IoT devices will allow access to information from different environments, allowing almost real-time monitoring and control based on informed decision-making, enabling cost reduction and processes optimization. Authors use ThingWorx platform to receive the data such as noise, temperature, and humidity from the sensors deployed all around the stadium [Mac18]. [Ama+17] introduces a model-driven, Thing-In-the-Loop verification and validation approach n the context of a Smart Mobility case study. This study generates appropriate test cases that are executed in accordance with Model-in-the-Loop, Software-in-the-Loop, and Hardware-in-the-Loop tech- niques. With so many potential IoT platforms available in the market, [Yu16] answers the question of which IoT platform is the best fit for different scenarios by performing a quantitative comparison between SensibleThings and Thing- Worx. The study relies on the sensor data where the update data is quicker than 25 times/sec, and it is analyzed that it is better to choose ThingWorx. If the sensor does not have suitable hardware, it is better to use SensibleThings as it is lightweight enough. The study also shows that ThingWorx has better performance and is ideal for its security and graphical visualization service. The ThingWox platform used in this project is shown to be reliable with studies where According to [Mac18], the application employs modeling instead of coding, so the user does not need to debug, but only focus on the agility and composition of one’s solution. Similarly, [Per16] focuses on enabling industrial IoT (IIoT) for the industries that use a surplus of devices, sensors, and workers who operate in diverse environments.

6 3. Background

In this chapter, we will understand the background information of relevant domains needed for this thesis in detail. The topics include the Model-Based Systems Engineering (MBSE) background, SysML, testing methods generally used (x-in-the-loop), a brief introduction to the hybrid testbed, and the intro- duction, and significance of the applications used in this thesis work.

3.1. Model-based Systems Engineering

Systems engineering is an interdisciplinary systematic process for supporting the system throughout its life cycle. The increase in the complexity of systems, especially safety-critical systems, has led to the emergence of Model-based- systems-engineering. The downside in managing such complexities in software engineering means we do not know what information to leave out (YAGNI, “you ain’t gonna need it”). Model-Driven Engineering (MDE) helps mitigate this problem by raising the level of abstraction. Model-driven-engineering is not just the solution for higher Software complexity but also to detect more defects. Traditionally, finding these defects would require functional testing, which is very expensive [SL15]. Model-Based Systems Engineering (MBSE) introduces new capability into systems engineering practice. It is defined by INCOSE as “the formalized application of modeling to support system re- quirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases” [INC20]. This methodology has improved the systems engineering processes in terms of accuracy, time management, and cost reduc- tion. The MBSE is responsible for model specification, design, integration, testing, and functionality of a system. [Kap+19]. The foundation of this approach is making use of the models. Models are more precise, analyzable, adaptable, and easily understandable as compared to traditional text documentation. Especially in the railway signaling domain, models used to describe the behavior of rail signaling systems ensure safety analysis [Bou18]. According to [Ste18], ”A model is an abstract, usually graph- ical, representation of some aspect of a system.” Models, in general, could be either prescriptive or descriptive. Meaning: a model may include all the in- formation or only the information needed for a given purpose at a given time, which depends on the needs of stakeholders [Dij12]. A simplified view of the systems engineering technical process is shown in figure 3.1. The process starts with the stakeholders’ needs. The system spec- ifications are used to specify the system requirements. It includes the com- ponents and sub-system requirements. The system is designed using SysML,

7 Chapter 3: Background

Figure 3.1.: The approach of MBSE in brief and is later integrated for testing. Before the system solution is ready to be implemented, many iterations of feedback are given during the design and the testing phases. Systems engineering approach is best suited for transforming the stakeholder needs into a viable system solution. It also addresses and challenges the hardships of technical processes [FMS15a]. On a detailed note, the process-flow for most technical processes as described in [FMS15c] is as follows:

• Specify System Requirements.

• Capture the requirements in text-form that support the system goals.

• Model the use-case scenarios to specify the system behavior requirements (Activity diagram).

• Create the system context diagram to specify the system external inter- faces (Internal block diagram).

• Partition the system design into components that can satisfy the system requirements.

• Decompose the system (block definition diagram).

• Define the interaction among the parts using activity diagrams.

8 3.1. Model-based Systems Engineering

• Define the interactions among the system entities using the internal block diagram.

• Capture each analysis as a parametric diagram.

• Ensure the traceability is captured between the system requirements and the stakeholder needs (e.g., use cases, measures of effectiveness) on a requirements diagram.

• Identify the test cases needed to verify the system requirements on a requirements diagram or table and capture the verification results.

3.1.1. Modeling using SysML The SysML model represents the real-world system in the form of an ab- straction. SysML also provides graphical models representing requirements, structure, behavior, and properties of systems and their sub-systems. Accord- ing to [AP18], SysML can model component-based systems, which are used to tackle the system’s complexity. It also enhances the expressiveness and abstraction of the model. SysML is the new-age adaption and extension of Unified Modeling Language (UML) 2.0, which includes UML 2.0 features and has newer features like requirements, allocation, and parametric, as illustrated in figure 3.2. The figure illustrates the SyML-extension of a subset of the standard UML language. UML1 supports the graphical representations, while SysML extends UML for more general systems supporting both graphical and semantic repre- sentations [MS18]. SysML broadens the use of state machines, use cases, and interactions from UML 2.0. The blocks and activities are used in common, while SysML features new diagrams, namely requirements, allocation, and parametric. The below-mentioned diagrams are widely used in SysML, which defines the respective functionality. UML 2.0 provides a domain-specific ex- tensibility mechanism, Profiles [FV04], which allows users to add new concepts to the modeling language in the form of Stereotypes. The main pillars or the feature-diagrams of SysML, according to [ANS19] are:

1. Behavior diagram: describes the model behavior.

• Use case diagram - provides a high-level description of functionality achieved through user interactions with systems or system parts. • Activity diagram- represents the flow of data and control between activities. • Sequence diagram - represents the interaction between collaborat- ing constituencies of a system.

1Object Management Group (OMG) is a computer industry standards consortium that develops enterprise integration standards with the objective of a common portable and interoperable object model (https://www.omg.org/spec/UML).

9 Chapter 3: Background

Figure 3.2.: Relationship between UML and SysML, adapted from [Tut20]

• State Machine Diagram (SMD) - describes the state transitions and actions that a system or its parts perform in response to events. Transition based models like state machines are widely used for model-based testing [AL18]. The generation of test cases generally requires great effort both in terms of money and also time. In this context, Test cases are generated automatically based on state machines for various railway functionalities [GG19].

2. Structure diagrams: describes the system structure.

• Block Definition Diagram (BDD) - describes the hierarchy of the system, sub-systems, and all the system elements. Basic structural elements are used to define the structure of systems using system blocks, their features, and possible relations, including associations, generalizations, and dependencies, modeling system hierarchy, or a classification tree. • Internal Block Diagram (IBD) - depicts system parts, ports, and connectors. Figure 3.3 represents an example of IBD with block interfaces. • Package diagram - organize the dependencies between the compo- nents that make up the system. In this thesis work, we will be mainly interested in using BDD, IBD, and state diagrams.

3. Parametric diagram - represents constraints on system property values such as performance, reliability, and mass properties. It serves as a pro- vision to integrate the specification and design models with engineering analysis models.

10 3.1. Model-based Systems Engineering

Figure 3.3.: An example - Internal block diagram c Randolf B., DB Netz AG

4. Requirements diagram - The requirement diagram captures require- ments, hierarchies, and the derivation, satisfaction, verification, and re- finement relationships. The relationships provide the capability to relate requirements to one another and trace requirements to system design models and test cases [ANS19]. MBSE allows the developers to focus on designing the models with higher safety concerns rather than worry about redundant implementation details [MEW20]. MBSE is used in EULYNX for developing the specifications in the railway signaling system. The structure and functionality are defined by SysML, which also complies with the railway standards like CENELEC2 [MM19]. Detailed information on the use of SysML is explained in section 4.1.1. Finally, below are some of the advantages of using MBSE as mentioned by [FMS15b]: • Ease of understanding the behavior of systems. • Reduced development risk. • Improved quality. • Increased productivity. • Support the process through the system’s life-cycle. • Ease of exchange of data. We have various tools available in the market today to design and test the models. We use Windchill integrity Modeler to design and generate test cases through the state machines in this context. The detailed explanation about the modeling is explained in the chapter Methodology - MiL Architecture.

2European Committee for Electrotechnical Standardization

11 Chapter 3: Background

3.1.2. Verification and Validation

A model has its limitations in mirroring the performance and behavior of the real system. Although the model allows us to focus on the crucial elements, it is still abstract than the real system it is representing. This insufficiency calls for various testing methods to ensure the model fulfills the properties of correctness, consistency, and completeness [Hil03]. According to [SHC17], the features of a system are tested either in the field or lab. This approach ad- dresses the factors of safety, conformity, and serviceability. This is an essential approach in the systems which are safety-critical. In this thesis, particularly, we have extended the simulated model, which serves the purpose of model execution. Although the simulated model displays the system’s intended be- havior, it is essentially not enough to pick out errors in the system or run the extreme case scenarios that concern safety. Basically, the simulator animates the SysML models and helps find the early SysML model errors. The sim- ulator includes the animation of the real systems’ behavior in the graphical form. The degree of accuracy and the quality of the animation is very tool-specific. For example, in SySim, PTC Integrity Modeler simulation tool presents the simulation with state machines. The transitions are fired upon triggers to ensure the behavior of the system is reflected using state machines. The dis- play of expected behavior rather than the absolute behavior by the simulation models calls for additional testing for verification and validation of the model. Verification determines the correctness of the model implementation, while validation determines the level of accurate representation of the model com- pared to the real world. Simply put, the verification process asks, “Are we designing the model right?” and the validation asks, “Did we design the right model?” [sta]. For any activities of verification and validation to begin, the system design must be ready [WP19]. The entire process of verification and validation dur- ing the phases from requirement elicitation to system design and from code generation to high-level testing is illustrated by V-model. In this thesis, we focus on the system design using PTC Integrity Modeler, generating code in visual basics, and testing it on the hybrid testbed platform. Figure 3.4 highlights the major steps in the V-model, which also includes a small v-model during the initial phases. System design for railway signaling systems follows V-model according to the CENELEC standard. According to the EULYNX partners3, the models are implementation abstracts for the real system. A small V-model in the specification phase within a big V-model in the CENELEC phase is defined [Ini18]. The requirements are verified by the Infrastructure managers, and the state machines are verified by the domain experts. Figure 3.5 describes the overview of the process undertaken by the railway infrastructure managers to ensure the model verification. As the figure illustrates, a criterion is met at every step, and a yes/no output yields to a state until the final baseline is validated. Then the baseline (documents-ready

3https://www.EULYNX.eu/

12 3.1. Model-based Systems Engineering to publish) is set as a standard for the further process.

Figure 3.4.: V-model, adapted from [Par20]

Figure 3.5.: Overview of the model validation steps. Source: [Par20]

EULYNX calls for validation activities that involve the validation of the model against the basic principles of safe and reliable railway operations [Ini17]. Hence the recommendation is that EULYNX uses verification tech- niques (for ex: formal methods) to meet the higher safety standards [Bui17]. In this thesis, we will demonstrate a methodology to verify the SysML mod- els, which are highly safety-critical. This process includes the approach of

13 Chapter 3: Background generating test-cases and testing the models using the platforms outside the Modeler and the simulation tool. The testing of the simulation-model goes a step further in confirming the functionalities of the system. This approach is introduced in the next chapter, where a hybrid testbed is used to verify the model.

3.2. X-in-the-loop Testing

Testing is recommended for safety-critical systems by various standards in most domains. For example: ISO 26262[IS11] for testing for safety-critical software in the automotive domain and EN 14363 for Testing and Simulation to accept the running characteristics of railway vehicles - Running behavior and stationary tests. As finding errors is expensive and time-consuming, testing helps detect errors during the development phases.[Han+17][Cap+12][BK08] [Lam+04]. The left-hand side of the V-model includes the requirements and design phase leading to the software development. The tests are conducted using either only software or both the software and the hardware to test the designed model. These tests are conducted in a loop with the reference model. These tests are referred to as X-in-the-Loop (XiL) tests. “X” here denotes either or/and model, software, hardware, and processor, depending on the domain where these tests are usually performed [Tul+17]. In the XiL approach, the testing is performed corresponding to various attributes in the development phase. Model-in-the-Loop (MiL) testing is per- formed at an initial stage where the model is used to represent the behav- ior of the system. This approach helps in verifying the functionality of the system through simulations in the modeling framework [VDA13]. The satis- factory results during this phase sets up the benchmark for further non-MiL tests. Software-in-the-loop focuses on verifying the source code being gener- ated. This process takes place without any hardware being involved. Then comes the Hardware-in-the-Loop (HiL), where the verified source code is de- ployed on the hardware to complete the HiL verification process [MB07]. This approach is also referred to as virtual testing. The principle behind this pro- cedure is to assess whether the model is a valid representation of the real system. In-the-loop tests have the advantage of testing the virtual model concerning variability and uncertainty that can be expected in the real-world systems through simulations [DB19]. Model-in-the-loop approach is explained in detail as it is the Focal point of this thesis work. The principles of SiL and HiL are presented in brief. The safety-critical systems, such as railways, demand for accurate and logical testing results. The testing approach, especially the use of simulations, has an enormous potential to reduce the time to market and cost in the operational network of railways. These methods are considered vital so much so that the railway standards are formulated based on simulations. Some examples, as described by the author in [DB19], are: • EN 14067-4: Requirements and test procedures for aerodynamics of on open track.

14 3.2. X-in-the-loop Testing

• EN 14067-6: Requirements and test procedures for crosswind assess- ment.

3.2.1. Model-in-the-loop

Model-in-the-loop (MiL) testing is where the early design errors are captured. This approach also helps in testing and simulating the interactions with other models [Mat+14]. MiL approach is quite simple in nature that enables perform quick tests. However, the accuracy of the results is low for the implementation [KB19]. Figure 3.6, as adapted from [KB19], illustrates the differences in different levels of testing approaches.

Figure 3.6.: MiL testing in comparison with SiL and HiL, adapted from [KB19]

MiL allows for more freedom to design, as it is still abstract in nature. It is also not wholly complex as the unwanted details are ignored during this phase. On the other hand, HiL is highly complex as there is no more freedom to alter the system and its design. Here is where the integration of an additional testing platform boosts up the process. The testing is carried out on a hybrid testbed, which is explained in section Software-in-the-loop. The sub-systems which are being tested here are ”subsystem Point” and digital Interlocking. PTC Integrity Modeler, in this thesis, is used as the native-environment for the model development. During testing, we can test the models in modules, i.e., only the sub-systems can be tested, or the complete system can be tested at once [VDA13]. The connections between sub-system components are through the ports. These ports send and receive the data physically for the model to run in real-time [KB19]. The output values of the MiL test yields the output of simulation parameters. These results target the system configurations in the testing environment as it adds value to the verification process.

15 Chapter 3: Background

3.2.2. Software-in-the-loop The next step of the testing approach is Software-in-the-Loop (SiL) testing. Considering the MiL testing verifies the system successfully for its behavior and abstract functionality, the generated code is run on the model to ensure it is ready to be implemented on the hardware. The results in this testing process refers us to go back to the MiL approach and repeat the process or continue further to HiL testing methods [Mat]. SiL is considered the next testing step on its testing methods and its complexity level since the results are much more reliable [KB19]. In this step, the sub-system components are connected in the same nature as with MiL. However, the model is now compiled into the generated-code and run [NHC12]. The advantage of this approach is that the software test can be enabled even before the hardware is ready. The software developers have the freedom to follow the process of ‘de- velop–build–test–rectify’ to ensure the software is mature to be implemented on the hardware. The advantages include reduction in time as it enables to execute test-cases. On the other hand, the limitation of SiL lies in the field tests where the representation of the hardware components and its interfaces are inaccurate [DB19]. This brings us to HiL testing, where the field tests are done with real-world models.

3.2.3. Hardware-in-the-loop Hardware-in-the-loop (HiL) testing combines the real-world system with the model, which is simulated. This approach combines and compares the testing methods of the designed system both in real and the virtual world to check for its functionality, final-errors, if any, and ensure the fault-free operation in the real world when implemented. The execution environment makes it easier to detect more errors. The main significance of this testing approach is the testing of hybrid systems [Sch+13]. The sub-system level interfacing within the main system is more realistic. Hence a thorough testing on a modular level is possible [VDC17]. In general, the model is divided into the test-model and the actual-model. The test-model is where the generated code is run on, and the model is simulated to reflect the actual model. The actual model is used to compare the results with the test-model and check if it fulfills the requirements. The redundant components of the hardware, along with its non-linearities, can be ignored. The modular-components are replaced with the real hardware to increase the accuracy of the testing results. This way, the test results from HiL are more reliable than MiL and SiL [KB19].

3.3. Hybrid Testbed

The Hybrid-test approach is employed in this work as it is essential to reflect the real-world system performance with the simulation models. Although this concept is not entirely new in many sectors, railways are trying to adopt these methods as the railway-standards focus on safer and reliable systems in operation, as discussed in the section Hardware-in-the-loop[Kar+13].

16 3.3. Hybrid Testbed

In this section of the chapter, we introduce the architecture of the hybrid testbed, which is used for testing. The testbed includes the following compo- nents: • A GUI is created in GraphWorx64, which is the emulator of a real-world PLC interlocking. • A SySim specification model of the interface between interlocking and the ”subsystem Point” (SCI-P) is executed. • State machine animation is run parallelly in the background for testing by scenario-basis. The functionality of the GUI is kept simple by not including the com- plex components for a better understanding of the research work. Later, the methodology can be implemented to integrate other elements of the hardware and test the complete ”subsystem Point” and interlocking as specified by EU- LYNX. The test procedure generally follows a sequence where the verification of the designed model is performed first with model-execution. The testing is then carried out by creating test cases for testing the system in its entirety [WP19]. This approach of combining the model validation in a real-world system ensures the end-system to be flexible, reliable, and scalable [Bud+14]. Figure 3.7 presents a simple view of the working principle for the testbed. This illustration is a part of the total work in this thesis. A detailed presentation is given in the methodology chapter.

Figure 3.7.: Hybrid Testbed overview

As seen in figure 3.7, the behavior of the real system, which in our case is the interlocking system operating together with the ”subsystem Point,” is

17 Chapter 3: Background simulated by creating a GUI using Graphworx64 from the Iconics application. The GUI includes the buttons to trigger the SysML model in the Integrity Modeler. This allows for the simulation to start or change according to the commands given. SySim simulator illustrates the simulation scenario through the transitions in state machines. The next chapter presents the information on the hybrid testbed, which is used for testing the scenario mentioned above. In this thesis, we extend the model execution for further verification by trig- gering the model from an external platform that acts as a real world-system. With this, an extra level of assurance is ensured for the system to reflect the real-world conditions.

3.4. Internet of Things

As a second part of this thesis work, we present in this chapter the introduction to Internet of Things and its application in industries - Industrial Internet of Things. Later, in this chapter, we also list out the applications used in this thesis work.

3.4.1. IoT Internet of Things (IoT) is deemed to be one of the most vital areas of tech- nology for the future and proves its importance in a wide range of industrial sectors. It is seen as a new technology archetype that has the capability of machine-to-machine interaction [LL15]. Kevin Ashton coined the term ”In- ternet of Things” in 1998, which has become a widely used technology in a myriad of domains [Wu+10]. This technology is based on a concept called “things,” which are intelligent enough to connect within a global network of machines. The IoT-platform, ThingWorx Composer too, constitutes of Things and Thing shapes, which refer to the M2M connectivity, which is explained later in the section Methodology - MiL Architecture. In general, IoT refers to as “a world-wide network of interconnected objects uniquely addressable, based on standard communication protocols” [ZZ11][LHW11]. In this sense, the IoT can:

• Connect anyone to anything at any given time and any given place.

• Allow autonomous and secure data exchange between several devices [FC10].

• Measure, comprehend, and even modify the environment as it is always present for computations [Bot+16].

• Offer co-operative services like object identification, sensor and actuator connectivity, and interoperability [Jia+12].

The IoT technology is deployed (figure 3.8) through IoT-based services such as Radio frequency identification (RFID), middleware, Cloud computing, etc., [LL15]. Some of these services/products are used as a standalone technology

18 3.4. Internet of Things

Figure 3.8.: IoT and its application cluster. Source: [Ros20] or in combination with other services to enrich the benefits. Some benefits, as presented by [SS15] from IoT include:

• Connectivity (Machine to Machine and/or Machine to people).

• Intelligent systems

• Smart analytics

• Enhanced Security

• Increased productivity

• Smart inventory

This technology is growing more and more sophisticated and is also fore- casted to involve humans integrating and operating with things in a synergy [Sta14].

3.4.2. Industrial Internet of Things Industrial Internet of Things (IIoT) is considered the sub-set of IoT, where the industrial components such as machines, control systems, and controller devices are connected to information systems and the business processes. This new-age industrial approach helps in a better understanding of manufacturing, production, and automation processes. Furthermore, it improves the efficiency of industrial operations and sustainable productions [Sis+18]. With many definitions available over the internet, a definite way to define IIoT is not easy. However, [Hel+17] puts is simply as “Industrial Internet or Industrial Internet of Things (IIoT), it is built for bigger ‘things’ than smartphones and wireless devices. It aims at connecting industrial assets, like engines, power grids, and sensors to cloud over a network”.

19 Chapter 3: Background

Figure 3.9.: IIoT as a subset of IoT. Source: [Son20]

From the figure 3.9, we can see that IIoT is also a sub-set of industry 4.0. After the first three industrial revolutions of utilizing steam energy, mass production in automation, and computers & electronics, we have come to reap the benefits in the new-age-revolution from IoT, industrial internet, intelligent systems, and cloud computing [Onl]. A wide range of Industrial sectors have recognized the benefits of IIoT and have based their business operations and growth prospects accordingly. The industries have started to embed smarter components to enhance the conventional systems into IoT devices [Boy+18]. The applications of IoT has been fruitful in many industries from various sectors. In the transportation sector, this technology is mainly used to enhance the value of the operational and business processes. For example, services like vehicle tracking, vehicle monitoring, and predicting the conditions of the road and track are making the systems more and more intelligent [Qin+13]. The scope of this thesis work is to enhance the safety and operational features in railways using IoT. There are various domains in the railway industry sector, as we can see from the figure 3.10. There are no limitations for an industry to apply these new-age technologies to boost their performance and prove to be a capable competitor. In railways, there have been implementations of this technology in broad areas, especially for safety concerns. To name a few: • [Ahm+18] have proposed to use IoT and automate the controlling of the rail gate for level crossing. They have cited that the developed

20 3.4. Internet of Things

Figure 3.10.: Industrial railway sector

system will be cost-effective, real-time, and, importantly, reduces the rail accidents.

• [XLG18] has ensured the safe-driving of high-speed trains using IoT in supervision and maintenance.

• Besides just the safety, the IoT has been applied in other fields, as cited in [JKK17]. They introduce the IoT solution for smart railway infras- tructure, which can be widely used in many areas of the railway network.

3.4.3. Applications/Tools used In this chapter, we will introduce the applications used in this thesis work that help us achieve the following tasks:

• Importing the requirements

• Modeling

• Model execution

• Integrating the Industrial IoT capabilities

• Connecting to information systems

• Emulating real-world system

21 Chapter 3: Background

3.4.3.1. Integrity Modeler The Windchill Modeler from PTC, formerly known as the Integrity Modeler, helps in the engineering process of creating consistent, high-quality models to mirror the requirements, show the behavior, enable design opportunities and develop the functionalities in the early phases of the V-model. The Mod- eler brings in the systems and software engineers together in the develop- ment and automation of repetitive tasks. The potential in the tool to find the design-errors very early in the process reduces the design-time, cost, and time-to-market [PTC20g]. As is well suited in the development of complex safety-critical systems, DB Netz AG has shown great interest in using this tool to design and model-execution of railway interfaces for a long time. This tool supports the leading industry standards like OMG SysML, OMG UML, and other architectural frameworks. We will be using this tool to model our ”subsystem Point” and the Interlocking systems as it helps in complying with industry-standards [Mod20].

3.4.3.2. DOORS DOORS, officially known as Integration for IBM Rational DOORS, integrates the integrity Modeler tool with IBM Rational R DOORS R (DOORS). This tool enables us to capture and maintain the requirements, which later can be linked to the model elements being developed in the Modeler. It helps in the traceability of the requirements in SysML models in comparison with the objects created in the DOORS environment. The synchronization is bi- directional as it allows for the linking of both DOORS and SysML require- ments. With this tool, we can choose to include the model elements we need in the process of synchronization [PTC20b].

3.4.3.3. SySim Windchill Modeler SySim, also known as SySim, provides a way to see the model execution to see if the model does what it is specified to do. The systems simulation tool is used to test, verify, and simulate a SysML model to ensure the model can be well refined before moving onto the next phases [PTC20c]. It allows to sharpen the focus on important details, such as creating the intuitive simulation graphics from the toolbox. The code-generation is automatically done in Microsoft Visual studio. The user need not focus on the activities such as code-generation or target environments. The systematic checking of the model for its errors and inconsistencies right from the specification phase makes it useful [PTC20h].

3.4.3.4. ThingWorx PTC promises to turn the IIoT into reality by providing the industrial- application platform for specific purposes through the ThingWorx platform. With ThingWorx, we can display data from different applications by making use of mashups. This allows us to create web-based applications for better

22 3.4. Internet of Things visualization of the system performance. The SySim model-execution can be with the ThingWorx code to perform the next level of testing (SiL and HiL) [PTC20d]. As explained in [PTC20f], this IIoT platform enables:

• Connectivity of IT/OT systems and devices from edge to cloud.

• Automate the processes and provide insights for real-time applications.

• Improve the performance through Augmented reality support.

• Build data-driven applications to enrich them.

• Digitize the systems and improve the business processes.

3.4.3.5. KepServerEX As a next of connectivity, we move onto the platform from PTC that serves as a source of automation data for the industrial applications. KEPServerEX is also called ThingWorx industrial connectivity that provides secure and reliable access to the industrial data in real-time [Kep20]. This tool can be leveraged together with ThingWorx Composer and the GUI from a 3rd-party application to integrate the applications and make it IoT ready. The data access for client applications is provided via standard protocols such as OPC. In this thesis work, we use this protocol to ensure the communication between the real- world system and the model in ThingWorx. This connectivity to industrial data enriches the much needed digital transformation in industries, mainly railway signaling.

3.4.3.6. GraphWorx64 The graphical user interface, as needed to control the Point through Interlock- ing PLC4, is designed with GraphWorx64. It is a software package by Iconics that is useful for creating animated graphics and design the control screens. In this thesis work, mainly, we make use of the button feature to control the PLC. This environment displays the data in real-time, showing the state of the system. Furthermore, the tool is OPC compliant, making it easier to connect to the tools mentioned above, and enable the seamless operation [Gra20].

4Programmable Logic Controller (PLC) is a controller or an industrial computer designed and adapted to use it efficiently in manufacturing processes, such as assembly lines, or robotic devices, to ensure fault-free and reliable diagnostic results.

23

4. Methodology - Railway Principles of Safety

4.1. Safety-critical Systems

Safety is a major concern with the Software and hardware systems, especially if it can damage the environment, damage people through injuries, casualties, and economic loss [LD17], [Hat+14]. Today’s systems are more and more soft- ware dependent to the extent that an error in such systems can affect safety and be hazardous. This is the case in many fields, such as transportation, health-care, and defense. The growing technology is forcing the complex sys- tems to grow in terms of complexity for putting out improved performance. With this growth of complex systems, the sub-systems are increasing too. Safety and standards organizations are in constant lookout to keep up with the increasing size and complexity of the systems and ensure, at the same time, that the safety of these critical systems is kept at paramount importance.

Transportation mode Fatalities in EU (2018) Airways 8 Railways 885 Roadways 25,100

Table 4.1.: Fatalities in different transportation mode

The 4.1 above shows the deaths in different means of transportation in the year 2018123 within Europe. The fatalities include both the passengers and the vehicle operators. The casualties in Railways alone is more than 100 times compared to the airways. This is a severe concern for the transportation sector. The safety parameters are to be considered, and the operations of the components are to be made fail-safe to ensure no damage to the people during the system failure. Railways and other transport sectors are built to comply with the safety standards with up-to-date precautionary measures. Safety in the engineering domain is a vital factor to consider right from the specification phase by following all the safety standards. Any system which can cause all/or any one of the losses, as mentioned earlier, is considered to be a safety-critical system. Or simply put, “If the failure of a system could lead to unacceptable consequences, then the system is safety-critical” [Kni02].

1Air safety statistics in the EU, Eurostats statistics explained 2Rail accident fatalities in the European Union (EU), Eurostats statistics explained 32018 road safety statistics: what is behind the figures?, European commission Press corner

25 Chapter 4: Methodology - Railway Principles of Safety

To comply with the safety standards, various steps are taken from the system development’s initial phases. Safety instrumented function (SIF) is one such measure that requires the performance to be measured in terms of safety. This is measured in terms of safety integrity level (SIL) for specifying the safety requirements. Table 4.2 shows the Safety Integrity Level (SIL) levels and their probable numbers by which the safety-critical systems, in general, are classified.

SIL PFD PFD (Power) RRF 1 0.1-0.01 10−1 − 10−2 10-100 2 0.01-0.001 10−2 − 10−3 100-1000 3 0.001-0.0001 10−3 − 10−4 1000-10,000 4 0.0001-0.00001 10−4 − 10−5 10,000-100,000

Table 4.2.: Classification of safety-critical systems based on SIL levels. Source: Safety integrity level, Wikipedia

Table 4.2 shows the PFD4 and RRF5 of low demand operation for different SIL levels in Safety Critical Systems (SCS). There are tools and analysis meth- ods that are followed to ensure a system is safe before it is being implemented. Fault Tree Analysis (FTA) and Failure Modes and Effects Analysis (FMEA) are such techniques to analyze failures in the system beforehand. Besides, these various safety norms, certifications, standards, etc., are to be strictly followed to ensure the safe operation of the systems and reduce or nullify the errors build-up during the process. Verification and validation, among others, are among the systems during the initial phases of system development and are among the most widely used methods to ensure this process. Figure 4.1 illustrates the generic overview of the system cycle focusing on safety. As we can see from figure 4.1, good requirements are the key to start the development cycle for safety-critical systems. Further, in the next chapter, we will see the standardization approach taken by European railways to ensure the safe, consistent, and reliable operation of railways.

4.1.1. EULYNX As European railways operate through the international borders in Europe, interoperability is a primal factor to consider. Interoperability is a term, which has different meanings based on the domain it is used in. According to IEEE, interoperability is defined as the “ability of a system or a product to work with other systems or products without special effort on the part of the cus- tomer. Interoperability is made possible by the implementation of standards“. Standardization and harmonization of all the railway signaling systems enable

4Probability of dangerous Failure on Demand (PFD) as defined in IEC EN 61508 5Risk Reduction Factor (RRF) as defined in IEC EN 61508

26 4.1. Safety-critical Systems

Figure 4.1.: A generic approach to ensure safety. Source: [Hob17] them to maintain and manage interoperability. This results in higher efficiency in the operations and reduces cost input for the entire systems [EUL20a]. EULYNX - an initiative project in Europe provides the framework that al- lows the infrastructure managers of different railways to work together. Bob Janssen, Senior Data Architect at EULYNX, says, “EULYNX replaces a mo- saic of different national signaling interfaces by unified interface specifications in a standard reference system architecture” [Zas20]. The main significance of this initiative is to standardize the technical signaling interfaces to provide an exposure to the markets outside and bring in new innovative technolo- gies from other sectors. For example, the automotive sector is making use of such advancements in terms of communication technology, automation levels, using big data, and more. Besides, the railway components provided by dif- ferent railway-independent-suppliers causes the problem of interchangeability [MM19]. This also led to the emergence of EULYNX interface standard. EULYNX project allows the railways to contribute to the evolution at a higher pace. Currently, the European initiative consists of 13 infrastructure managers with common goals and objectives. Automatic train operation was recently im-

27 Chapter 4: Methodology - Railway Principles of Safety plemented in daily passenger operation of regional trains in Germany [20]. This installation will enable the trains to operate automatically, testing differ- ent Grades of Automation (GoA). EULYNX distributes the generic reference architecture of CCS (Control, command, and signaling) sub-systems to the infrastructure managers. The defined architecture provides the foundation for the development of EULYNX throughout the full V-cycle [Hei16]. Figure 4.2 represents the system architecture from EULYNX. Infrastructure managers use this architecture to develop the models of various interfaces. EULYNX, illustrated in figure 4.2, has specified a total of eleven so- called Standard Communication Interfaces (SCI). The interfaces constitute Standard Communication Interface-Light signal (SCI-LS), Standard Com- munication Interface-Point (SCI-P), Standard Communication Interface-Level Crossing (SCI-LX), and Standard Communication Interface-Train Detection Systems (SCI-TDS). An SCI is used to transmit data of a field element to the signaling system [MM19]. In the scope of this thesis work, we focus on the ”subsystem Point” and the Interlocking, which is highlighted in figure 4.2. The ”subsystem Point” is connected to the Interlocking through the SCI-P (Standard communica- tion interface of Point). Similarly, all the other sub-systems, like the Train detection system, level crossing, and light signal, are connected to the Inter- locking through their respective SCI’s. A detailed explanation of the relevant sub-systems and their operations are provided in section Railway Signaling.

4.2. Railway Signaling

The railway signaling operations are designed such that the railway instal- lations and operating personnel are operating in tandem. Signaling means monitoring and executing the railway operations with the help of all the in- stallations involved. Through the signaling rules, the process takes place whose signaling terms are standardized for the clear communication between all the involved entities. Railway entities, here, include the following [SUN15]:

• On-board devices, such as power, signaling, and mechanical devices.

• Safety-on-board devices such as brake system, Train protection system, and cab signaling.

• Safety-track-side installations such as Points, crossing, signals, and In- terlocking.

The railway installations are highly reliable and safe, falling into the SIL 4 safety standard. The objective is to replace all the manual operations and the involved human actors with the automated systems to ensure reduced errors. Figure 4.3 illustrates the signaling operation with the installations. The Interlocking system ensures the safe and no-conflict operation through Points and signals. The train receives the command through signals and/or on-board screen with further train route instructions. The signaling systems

28 4.2. Railway Signaling

Figure 4.2.: EULYNX System Architecture [ c EULYNX]

29 Chapter 4: Methodology - Railway Principles of Safety

Figure 4.3.: A Railway signaling system can also monitor and keep a record of the data, which helps in serving as a database for additional operational, security, and maintenance work [Bia+18]. In the further parts of this chapter, we will see the detailed explanation of the installations as the Focal point of this thesis work.

4.2.1. Track Segment A pair of rails over which the rails run and can be operated are the tracks. This is the fundamental and central component of a railway network maintained by the infrastructure manager. The track rails are designed so that the end-to-end continuous length of the track can run trains. They are installed with other railway installations such as Point, Balise 6 and speed detectors that help in the train operations. The tracks are divided into segments called “Zones.” It is always equipped with signaling for safety reasons, as shown in figure 4.4a. Figure 4.4b represents the track with two rails used for the train operation in both the directions. This part of the track with other track segments are called Point/Turnout [SUN15][Glo20].

(a) A schematic diagram of a track segment. (b) A track segment Source: [SUN15]

Figure 4.4.: Track

6an electronic beacon or transponder placed between the rails of a railway as part of an automatic train protection (ATP) system.

30 4.2. Railway Signaling

4.2.2. Point/Turnout As an essential component in the signaling system, the turnout, commonly referred to as Point, is used to change the track so that the train can change the travel direction. This change takes place before the train passes with the movement of rails accordingly. The Point is an assembly of the track segment, which is fixed and a moveable track segment. The moveable track segment is connected to the mechanical components through the control circuits, enabling the movement of the Point. Figure 4.5a shows the connection of the track segment with the mechanical component. Figure 4.5b shows the schematic representation of the Point, which changes the track and, eventually, the direction of travel. The Interlocking controls the circuits through the object controller. The object controller of the Point called “Point machine” receives the instructions from the Interlocking to change the position either to right or left. The switch is used to enable the Point change.

(b) A schematic representation of a Point. (a) A Point moving on track Source: [Gro20]

Figure 4.5.: Point machine

(a) Crossovers. Source: [SUN15]

(b) Ladder. Source: [SUN15]

(c) Junctions. Source: [SUN15]

Figure 4.6.: Point Variations

The Point can be operated either manually or digitally. Failure in oper- ating Point, meaning failure of operation by the Point machine, should be continuously monitored. In every Point operation, the Point has to reach a final position to ensure safe rail operation. The position of the Point is always

31 Chapter 4: Methodology - Railway Principles of Safety relayed back and forth to the Interlocking system. As seen from the figures 4.6a, 4.6b, and 4.6c, a switch in Point leads to different routes. The Point moved to “right,” or “disengaged” leads to route A and the Point moved to “left” or “engaged” leads to route “B.” The Point can lead to a combination of tracks that ensure faster and safer operation when systematically and effi- ciently used. The figure presents the schematic representations of the common combinations, such as crossovers, ladder, and junctions. As the name suggests, crossovers are the connections between the tracks, enabling the train to change lines. A ladder allows the train to change to any parallel tracks with a series of Points. It is mainly used in the terminals to enter and exit at the stations. A junction is where the another line joins with the track [SUN15][Bia+18].

4.2.3. Crossing The railway crossing is considered to be highly critical among all the railway systems. As shown in the figure, it is the intersection of the tracks. The intersection of the crossing is fixed or either operated and controlled by the Point machine. 4.7a presents the schematic diagram of the fixed crossing, and 4.7b provides the intersection controlled by the Point machine. The operation of the crossing is similar to that of the Point. The position must be fixed before the train passes through. The wheel rolling over the crossing section will first make contact with the outermost rail. The crossing nose takes the wheel’s load when the wheel reaches the crossing, thereby ensuring the ease-of-maneuver. There are various types of crossing, such as rigid crossing, movable crossing, single slip, and double slip.

(a) Rigid crossing. Source: [SUN15] (b) Double-slip crossing. Source: [SUN15]

Figure 4.7.: Types of Crossings

4.2.4. Interlocking In simple terms, the Railway Interlocking (IXL) is essential to prevent train collisions and prevent the trains from derailing. To ensure this, the IXL is used as a mechanism together with other installations by following the principles of railway signaling and safety. The IXL connects, operates, and arranges with the different available combinations of Points and signals to ensure the

32 4.2. Railway Signaling

Figure 4.8.: Railway Interlocking system in operation train movement is safe. Figure 4.8 shows a schematic representation of the Interlocking system. To enable better communication and ensure constant control of the trains and the installations, each of the divided sections will have an Interlocking system. When the train passes from one section to another, the control is transferred to the neighboring IXL. With this, the neighboring IXL receives the infrastructure data and authority-to-movement data. Usually, every main station has an Interlocking system to cover-up for the distance between stations. From the figure 4.8, we can see the connections between the installations: 1. Interlocking system 2. Signal 3. Point 4. Other installations like Balise Operating systematically as one topology is highly essential to enable the signaling application. Interlocking provides permission to trains for it move when the routes are set. The IXL, a computer device, is responsible for opera- tions such as route establishment, route auto-destruction, etc., [SUN15]. The IXL checks for the occupied routes or any conflicting movements by its algo- rithm and sends away commands for further operation. The control tables describe one of the standard algorithms of IXL through Boolean equations or Ladder diagrams. This logic is interpreted by the Programmable logic controllers (PLC)7 or by a device with standard processors [Bon+16]. The

7PLC is an industrial digital computer built for purpose-specific industrial applications.

33 Chapter 4: Methodology - Railway Principles of Safety modern-day’s Digitales Stellwerk (DSTW)8 is transforming the railway sig- naling network in Europe. The predecessors - Mechanical Interlocking, Relay Interlocking, Electro-mechanical Interlocking, and Electronic Interlockings are currently being replaced in Germany to make the signaling process more reli- able. DB Netz AG has already started-off with renewing the Interlocking with its first digital Interlocking installed at Annaberg-Buchholz in southeastern Germany [San+12].

4.2.5. Railway Standards The railway signaling operations are carried out with the help of various stan- dards. These regulations also support the introduction of new technologies, processes, and operating methods in railways safety. Standards like CEN9 and CENELEC aid in the interoperability of goods, services, and transport within Europe [CEN20]. The standards help analyze and certify the processes in val- idation, and testing of the systems. Among many, some important standards in consideration are:

• CENELEC - EN50128 specifies the procedures and the technical require- ments for developing programmable electronic devices. This standard refers to the software components that are to be used in railway control and signaling protection [Rs11].

• CENELEC - EN50126-1 specifies and demonstrates the availability, maintainability, and safety of railway applications. It defines the process based on the systems’ life-cycle and the tasks within it [50120].

8Digitales Stellwerk or Digital signal box uses IT and data network instead of the conven- tional cables and switches for control and command. 9European Committee for Standardization.

34 5. Methodology - MiL Architecture

5.1. Model-in-the-loop Architecture

Figure 5.1 represents the overview of the methodology in this thesis work. The entire part can be divided into the modeling part and the IoT part. The modeling part includes the SysML modeling of the ”subsystem Point” and IXL along with the connecting elements to the IoT platform. IoT part consists of the model enhancement with the help of a mashup builder. The platform is then connected to the Graphical User Interface (GUI) through the OPC standard. KEPServerEX1 is the industrial connectivity server, and the GUI is the client. The connection between the sections is enumerated for the ease of understanding and making the illustration more straightforward. Although the writing of methodology and the simulation results do not follow this sequence, this enumeration provides the knowledge of the connectivity between different entities from start to finish.

1. GUI is created with PLC interlocking features, mainly the buttons to allow the user to send commands to the ”subsystem Point.” The interface acts as a client and uses the Open Platform Communications United Architecture (OPC UA) standard to connect to the KEPServerEX.

2. KEPServerEX is connected to the ThingWorx platform to feed in the data from and to the GUI.

3. This establishes the connectivity from the PLC to the simulation model, which is also used in the Mashup build.

4. SySim simulator block is run to see the model execution with the en- hanced simulator view. In parallel, the model is run so that the Visual basic project is created to execute the SySim model. This generates the code automatically in visual basic.

5. We generate a Visual Studio project from the SySim Simulation Scenario through SySim. The toolbox in the Visual basic helps us to enhance the simulator view.

6. Once the code is generated automatically, and the simulator view is developed, the model is now ready to be executed in parallel with the Modeler’s state machines.

1KEPServerEX (Kepware server) is the connectivity platform that connects industrial data to all applications.

35 Chapter 5: Methodology - MiL Architecture

Figure 5.1.: Overview of the MiL approach with the integration of an IoT platform

7. The state machine is animated in the Modeler, along with the simula- tion from the SySim simulation toolbar. We can see the state machines change with the trigger in the SySim toolbar. The display bar in the SySim presents us with the display of the current state from the state diagrams.

8. The model execution in the Modeler can be visualized in the mashup from the ThingWorx Composer. This platform also serves as the inter- face for the end-to-end connectivity for the industrial application.

9. Finally, the test cases are generated to check for the model executing is valid. Also, GUI enhancement enables the data to be visualized in the end platform to keep an update of the status.

We will now understand how the modeling is done in detail and connect it to the platforms mentioned above.

5.1.1. SysML Model Setup From this section of the chapter, we will see the modeling steps with the Windchill integrity Modeler. We will be referring to the tool used as “Mod- eler,” although it is generally referred to as “Windchill Modeler” and “PTC integrity Modeler.” The focus is to show how the Modeler SySim can generate executable model simulations from a SysML specification. In this section, we also show how SysML designs are transformed into applications that can be executed to check, run, observe, and refine them.

36 5.1. Model-in-the-loop Architecture

1. Creating blocks:

In this section, we will design the behavior of ”subsystem Point” and In- terlocking as SysML models in the system design package. We will begin by creating two blocks named “Point Machine (PM),” referring to ”sub- system Point” and “IXL,” referring to the Interlocking. The ”subsystem Point” is designed to ease the complexity and enhance the connectiv- ity to other platforms. PM block takes the commands-“Left,” “Right,” and “No End position” as inputs. “Status output” is the output com- mand to display the status. Figures 5.2 and 5.3 present the package tree of the commands for PM and IXL in the form of input and outputs, respectively.

Figure 5.2.: Input and output ports of the ”PM” block

Figure 5.3.: Input and output ports of the ”IXL” block

Similarly, the IXL takes commands - “Button Left,” “But- ton Right,” and “Button No End Position” as inputs while the operational commands such as “Move Left,” “Move Right,” and “Move No End Position” as outputs. Along with this, the “status In” and “Status Out” serves as the commands for displaying the output. The blocks are applied with the stereotype << SySimControlblock >>. This stereotype lets the SySim know that these blocks should be a part of the simulation. It also allows us to choose the elements we want to see in the simulation.

2. Defining ports:

The blocks “PM” and “IXL” are populated as “owners” in the internal block diagram. After this, the ports can be defined on the blocks with

37 Chapter 5: Methodology - MiL Architecture

the predefined SySim data types. Figure 5.4 shows the list of predefined SySim data types that are available in the Modeler. Applying data types are intuitive in nature. The required data type from the list is dragged and placed on the port. We use the “Boolean” data type as the command is binary in operation. The data types can be chosen when we create the port. The ports used here are “Proxy port.” The main objective of using this port, among others like “Flow port,” is to allow bi-directional data. The same port can be used to send and receive the data. We assign the ports to all the input and output commands described in the previous section.

Figure 5.4.: ”SySim DataTypes” profile in the Modeler

The input ports are applied with << SySimInputport >> stereotype and the output ports are applied with << SySimOutputport >> stereo- type. Similar to the previous stereotype’s role, this stereotype allows the SySim to know that the input and output port will play the role of in- put and the output, respectively, in the simulation scenario. Again, with this stereotype, we can choose the ports to be included in the simulation part. We create and populate the “Status” block with the “string” data type as it displays the status of the Point. In the same manner, we create the “Status” block in the IXL with the “String” data type for the same purpose.

3. Adding Block property values:

Now we will add the SysML property values to the blocks created. With these property values, we can store the information needed for the out- puts in the blocks “PM” and “IXL.” From the operational point of view, the “PM” block requests an operation to “IXL” block. “IXL” responds with the permission to allow “PM” to move the Points to either “Left” or “Right.” Then, when the status button is pressed, the status of both “PM” and “IXL” is displayed in each of their display columns, respec- tively. Figures 5.5 and 5.6 present the internal block diagrams of “PM”

38 5.1. Model-in-the-loop Architecture

and “IXL,” respectively, with the ports and the block property. The next step is to specify the behavior of the system to make it work together.

Figure 5.5.: Internal Block diagram of ”subsystem Point”

4. Specify the model behavior with state machines:

Now that the structural elements are defined, we will specify the system’s behavior using state machines. As shown in figure 5.7, the state machine for a model can be created as an extension of the block. For the “PM,” we use three states - “No End Position,” “Left,” and “Right,” where the state “No End Position” is the default initial state, as seen in figure 5.10. With this, we create and assign events to the state machine. These events are based on the ”Signal” type, i.e., these events are the signal type triggers for the states to transit to another state. The events created are shown in figure 5.8. The transitions are arranged so that the states can change to any other state with the trigger. There is no initial guard condition for both the states. The condition events appear once the state machine reaches its initial state. Event Action block is created to respond to the associated event. The tables 5.1, 5.2, and 5.3 represent the associated events and their actions for the block “PM,” respectively. The transition between states is based on the signal type. “When” guard conditions are used to establish the transition of the states.

39 Chapter 5: Methodology - MiL Architecture

Figure 5.6.: Internal Block diagram of Interlocking

Figure 5.7.: States of the block ”PM”

Cmd Right Move Right := 1 Cmd Left Move Left :=1 Status Update IXL/Status12 “NO END POSITION”

Table 5.1.: Transitions from the state “No End Position”

Tables 5.4, 5.5, and 5.6 tabulate the guard conditions and the actions undertaken with the trigger of the mentioned events.

When each state is entered, the “Status Update IXL” command sends the signal to IXL, which is displayed in the simulation scenario. In the same manner, we specify the behavior for “IXL.” “IXL” has one

40 5.1. Model-in-the-loop Architecture

Figure 5.8.: ”Events” that trigger the state machine

Cmd Right Move Right := 1 Cmd No End Position Move No End Position := 1 Status Update IXL/Status12 “LEFT”

Table 5.2.: Transitions from the state “Left”

Cmd Left Move Left := 1 Cmd No End Position Move No End Position := 1 Status Update IXL/Status12 “RIGHT”

Table 5.3.: Transitions from the state “Right”

state called “Get Status” (Figure 5.9) as the scope of the “IXL” block is to permit the operations of the ”subsystem Point” and update the status. Table 5.7 shows the associated events and their actions for the block “IXL.”

Again, the trigger is based on the signal type. Table 5.8 presents the Guard and the conditions to it: Figures 5.10 and 5.11 illustrate all the states involved in the state ma- chine in both ”subsystem Point” and the Interlocking. We will connect the blocks in the next section to prepare it for the SySim Simulation scenario.

5. Connecting the system blocks:

The system blocks “PM” and “IXL” are connected with the respective ports. Proxy ports make the job easier by allowing us to combine the signals in one common port between the blocks. This port acts as an interface to the connecting blocks. This reduces the model’s complexity, and the data is sent and received consistently. Figure 5.12 shows the blocks whose ports are connected with the same name. Generally, the ports being connected must be compatible with each other. That is, the output port of a block with a name must be connected to the same name

41 Chapter 5: Methodology - MiL Architecture

When(Move Left) Move Left := 0 When(Move Right) Move Right := 0

Table 5.4.: ”When” conditions for the state “No End Position”

When(Move No End Position)) Move No End Position := 0 When(Move Right) Move Right := 0

Table 5.5.: ”When” conditions for the state “Left”

When(Move No End Position)) Move No End Position := 0 When(Move Left) Move Left := 0

Table 5.6.: ”When” conditions for the state “Right”

Figure 5.9.: States of the block ”IXL”

Ack PM Mem Status12 := Status; Status Out := Mem Status12

Table 5.7.: Associated events and their actions for “IXL”

When (Status In) Send Status update IXL to Cmd When (Button Left) Send Cmd Left to Cmd When (Button Right) Send Cmd Right to Cmd When (Button No End Position) Send Cmd No End Position to Cmd

Table 5.8.: Signal-type triggers associated between ”PM” and “IXL”

42 5.1. Model-in-the-loop Architecture

Figure 5.10.: State diagram of ”subsystem Point”

43 Chapter 5: Methodology - MiL Architecture

Figure 5.11.: State diagram of Interlocking

Figure 5.12.: ”Cmd” proxy port as an interface between ”PM” & ”IXL”

as the input port of the other block.

6. Creating the simulation scenario:

We can now improve the system design by adding more features to con- trol the system. This process is essential for the simulation viewer as it allows us to provide inputs and see the outputs when in operation. The operation we need is “Pushbuttons” to move the Points. We also need the display bar to visualize the status of the Point from both “PM” and “IXL” ends. From the ”SySim Profile” package in the Modeler, we select the” push- buttons” and “LED Display” options onto the blocks. Three pushbut- tons, namely “Sim Left,” “Sim Right,” and “Sim No End Position” are placed on the “IXL” block. The proxy ports are used as before with the data type as “Boolean.” These buttons are populated on the block to connect to “IXL”. Additionally, “Sim Status” button is populated to request for the status of the Point. We add “Sim Display” as the LED display on the “IXL” block to display the status of Interlocking. The block “PM” has only “Sim LED-Display” to output the status of the Point. Before simulation, we apply the << SySimSimulator >> stereotype for the simulation block in order to inform SySim that this simulation block will act as an execution scenario where the applica-

44 5.1. Model-in-the-loop Architecture

tion can be used to interact. At this point, the simulation block, which specifies the system’s behavior, looks like this (figure 5.13).

Figure 5.13.: Simulation block of ”subsystem Point” and Interlocking interface

45 Chapter 5: Methodology - MiL Architecture

5.1.2. Connecting SySim with ThingWorx Elements Modeler SySim is used to create early executables for the validation. This in- cludes creating an interface along with the connection to the simulation mod- els. We use the extension of SySim to connect to the ThingWorx platform. We create additional ThingWorx blocks in the Modeler to change how they are connected to other blocks in the model, which ensures the running con- nection between the Modeler and ThingWorx. In this section of the chapter, we demonstrate the steps to establish the connection between the Thingworx platform and SySim.

1. Create new TWx blocks:

SySim allows the Thingworx blocks to be created in addition to the native blocks. The addition and the eventual replacement of the SySim blocks in the model execution annotate the properties, services, and events to reflect in the SySim model. The objective of this step is to delegate the pushbutton task with a thing on Thingworx. SySim has the extensions, which allows us to create all the Thingworx elements. We start by creating new SysML blocks called “TWxPushuttonLeft” and ”TWxPushuttonRight” in the Modeler, as shown in the figures 5.14 and 5.15. We assign the stereotype << SySimcontrolblock >>, which makes it the block with controls on SySim. The block is also given a stereotype << SySimT W RemoteT hing >>, which tells ThingWorx that this is the block that corresponds with SySim. Assign a proxy port with the stereotype << SySimOutputport >> for the output value to be assigned to ThingWorx.

Figure 5.14.: TWx block for ”Left” pushbutton

Figure 5.15.: TWx block for ”Right” pushbutton

46 5.1. Model-in-the-loop Architecture

Figure 5.16.: Assigning operation-”SetValue” to the TWx buttons

The operation parameter in the new TWxBlock tells the simulation block how the value assigned is relevant to both SySim and ThingWorx. We assign a new service called ”SetValue” to toggle between the Boolean values when the button is pressed. Here, we call the Status output to be displayed by adding a “newVal” of type-Double, as seen in figure 5.16. The state diagrams of the SySim is linked from associate diagrams to the block for simulation. We set the SySim Identifier to “Pushbutton001” to identify the Remote Thing. This identifier is given in the identifier column in the ThingWorx mashup, to be linked to TWx service.

Figure 5.17.: ”TWx Pushbuttons” replacing the simulation buttons

2. Enable the identification:

Once the block is created, and the operation is assigned, we move on to assign the stereotypes connecting SySim and ThingWorx Com-

47 Chapter 5: Methodology - MiL Architecture

poser. This initiates the communication between the two platforms. To the TWx block, we assign << SySimSimulator >> and << SySimT W Si − mulator >> stereotypes. The next step is to authenti- cate the SySim models with ThingWorx, hosted on the web with a key. An application key can be created by simply selecting create “applica- tion key2” button on the ThingWorx Composer. This key is composed of large string values, including numbers and alphabets. The time du- ration for this key to be valid is changed according to the duration of the SySim model available for the simulation. The application key we are using for this thesis is attached with the SySim model in the “SySim TWApplicationKey” column. With the new buttons created, we replace the existing buttons on the simulation block with TWx services. Fig- ure 5.17 shows the connections which have been re-established from the simulation buttons (in yellow) with the ThingWorx buttons (in green). The Composer is hosted locally as a web application. The host ad- dress and the connection server address are also attached in the columns “SySim TWComposerAddress” and “SySim TWConnectionServerAd- dress” columns, respectively. By following these steps, we ensure the SySim simulator is completely annotated as TWx Simulator. The last step while running the simulation is to make sure the prerequisites are there.

3. Ensure the prerequisites are ready:

The model is now set up to run on SySim. The project is prepared to execute on Visual Studio. We are calling ”ButtonPressed” whenever we are calling for the service in Visual Basics (VB). The credentials are asked to be filled in (figure 5.18), proving the connection between TWx and the SySim simulator is now established. Before the VB code is auto-generated, we have to add all the references pertaining to Thing- worx. By adding these references, we add all the TWx capabilities, which helps in the model execution. We select the following .dll files from the TWx.NET SDK file: • Log4net.dll • Newtonsoft.Json.dll • Thingworx-dotnet-common.dll Now, we build the solution and run the model if no errors. With this step, we have ensured the SySim project is ready to work with ThingWorx. As a last step, we need to alter the TWxConfiguration file, which holds the data of the app key and the host address. This will be changed with the new app key we created, as shown in figure 5.19. We change this XML file in accordance with the project we need to run this model.

2Application key is an encrypted security token used for logging in into the ThingWorx platform.

48 5.1. Model-in-the-loop Architecture

Figure 5.18.: ThingWorx login credentials

Figure 5.19.: ThingWorx Config.XML file

5.1.3. Connecting GUI with ThingWorx using TIC In this section, we shall see the steps of GUI being connected to the ThingWorx platform using Kepware server or ThingWorx Industrial connectivity (TIC). This section is divided into two subsections. With the first subsection, we explain how to setup an Industrial gateway in TWx using OPC UA server. Then the Boolean type buttons are transferred in the TWx platform to add subscriptions.

1. Connect TWx to KepServerEX: By default, the server has the “ThingWorx” property group, which makes it easier to enable the connectivity. As seen from the figure below, we have to establish the connection by providing the details from TWx. We build the mashup and configure the IoT platform to be connected to an industrial connectivity server. The local host address of the TWx composer, which is running online, is captured. Port “443” is used as a standard connectivity port between the server and the industrial plat- forms. We have created the application key in TWx to ensure secure connectivity. This key acts as the authentication key between two end- platforms. When these settings are enabled in the property editor, an “Industrial Connection” is created as described on the server-side. The industrial connection- “KEPServerEX” acts as the gateway to connect to IoT platform. This IoT gateway is referenced whenever we try to

49 Chapter 5: Methodology - MiL Architecture

Figure 5.20.: ThingWorx server interface to establish the connection

connect. This entity is the actual representation of the Kepware server in TWx platform. All the data enabled to establish the connection in the property editor is shown in the figure 5.25. Kepware sends signals to ThingWorx on a regular time-stamps. We have set it up for 1000ms to configure the regular connectivity. Once we have done this, we can see from the “status log” that the connection is established for the given host. This log also contains the Thing it is connected to, as shown in the figure 5.26.

Figure 5.21.: ”Connected to ThingWorx” event

Now, we create an industrial Thing - “Ch1Dev1” in ThingWorx platform with the “Industrial Gateway” Thing template that can be used to con- figure the OPC server. KEPServerEX is used as a host evaluation server to explore ThingWorx composer features. The instances in the server are set up for 3 hours of activity by default. After 3 hours of inactivity, the instances automatically shut off, and the sever connection needs to be re-established. The server uses the “Store & Forward service” feature to ensure the property updates are not lost when the connectivity is lost. As seen from figure 5.27, the data in the interim is saved in the local database. Later, the incoming updates are matched with the outgoing

50 5.1. Model-in-the-loop Architecture

Figure 5.22.: ”Store and Forward” datastore in TWx Native Interface. Source: [PTC20a]

updates as a form of “handshake” to ensure the changes reflect on both the ends. The re-connection to the Industrial platform sends all the updates to the platform in real-time [PTC20a]. This way, we ensure the updates are consistent and are updated real- time. Figure below shows the binding data from the GUI to Thing- Worx platform with OPC UA protocol through Kepware server. The “Left” and “Right” buttons of the interlocking command in the GUI are assigned as “properties” in the platform. The figure shows the same buttons being reflected on two platform ends. 2. Add subscriptions to the Industrial Thing - “Ch1Dev1”: We have created the industrial Thing, which is the interface between the IoT platform and the server. Adding subscriptions allows us to sub- scribe the buttons to data-change event. The buttons are used as the subscription elements to call each time the trigger-event occurs. “Dat- aChange” is used for the property states reflecting the event change. We write a small script (JavaScript) as seen from the figures 5.23 and 5.24 to call for an event whenever the property values changes. This script includes an “if-else” condition converting the “left” and “Right” Boolean entry to “Numeric.” The “SetValue” entity is used to add the subscription parameters. We follow this step for both the buttons from the GUI. This process allows us to see the numeric entry in the display box in the mashup. As we are familiar, the numeric entry “0” refers to button - not triggered or simply “Off,” and the numeric entry “1” refers to button - triggered or simply “On.” The last step is to enable the subscription information so that buttons - “TransferButton1” and “TransferButton2” remain always enabled when we connect. The table 5.9 shows the subscription elements we have created with the source properties.

In the following section, we connect the server to the GUI end to visualize and control the ”subsystem Point.”

51 Chapter 5: Methodology - MiL Architecture

Subscription Event Source Property TransferButton1 DataChange Channel1 Device1 Button1 TransferButton2 DataChange Channel1 Device1 Button2

Table 5.9.: Mashup entities created for “PM”

Figure 5.23.: Subscription info for ”LeftThing” with Script

Figure 5.24.: Subscription info for ”RightThing” with Script

52 5.1. Model-in-the-loop Architecture

5.1.4. Connecting GUI to KEPServerEX The objective of this section is to connect the Graphical user interface (GUI)3, which emulates the operational properties of the PLC to the IoT platform through the Kepware server using the OPC UA communication standard. The PLC includes the modules of Interlocking and Point controller, which is also called as an Object Controller (OC). Figure 5.25 shows the digital Interlocking from HIMA4. We create a GUI with the simple and basic features of the PLC, which can be used to connect to the IoT platform and to test the models generated. For this, we have used GraphWorXTM645, a product of ICONICS GENESIS64TM, which allows us to create, visualize and contextualize the real-time graphics in 2D and 3D based on Vectors. This application also enables universal connectivity to databases such as OPC UA6 and OPC DA. In the next steps, we present the steps undertaken in detail to create the GUI, establish the connectivity in the Workbench, and finally connect it to the Kepware server.

1. Run-time connection with server: We begin with initializing the Kepware server, which is running on the local system. In the main interface of the server, which is otherwise also called as ThingWorx Industrial connectivity, we create the channel and the and the device, which is essential for interacting with the server. “Channel1” acts as the medium of communication between the local system and other external devices. “Device1” is the GUI representation with which the Kepware server communicates. The project interface is presented in the figure 5.26. We create tags in the buttons that represent a particular address in the PLC (which is the GUI) to be communicated with the server. We add the buttons - “Button1” and “Button2” to enable and disable the functionality of the selected items. The address in the simulator driver is given as a K-type register whose data is numeric. The address in K-register is a 16-bit memory with a range of K0000- K9999. The data type is selected as Boolean as we need it to toggle the values of the buttons, which is binary in operation. We additionally select the “read/write” access to the client enabling the client to edit the data configuration.

2. Create a new configuration database: We avail Workbench, a GENESIS64 product, to configure the OPC UA connectivity and the run-time operations. In the OPC UA network’s

3GUI is a form of user interface that allows users to interact with devices through interactive visual components and graphical icons 4HIMA is the leading provider of smart automation solutions for functional safety. Opti- mized for the digital age. [ c HIMA] 5GraphWorXTM64 is a rich HMI and SCADA data visualization tool for process control that can be used to create animated graphics. [ c Iconics] 6OPC Unified Architecture is a machine to machine communication protocol for industrial automation

53 Chapter 5: Methodology - MiL Architecture

Figure 5.25.: A digital Interlocking by HIMA. Source: A. Rasheeq, DB Netz AG

Figure 5.26.: ”Buttons” created as tags in Kepware

54 5.1. Model-in-the-loop Architecture

network settings, we create a server named “Kepware” with a local- host IP address of the system “opc.tcp://127.0.0.1:49320” (figure 5.27). The preferred end point is selected as none to ensure the authentication when connecting to the server is secure. The Frameworx services are restarted, and the connection is tested. The database is ready to use when the connection to the OPC UA server is successful, as shown in figure 5.28.

Figure 5.27.: Creating a database to connect

Figure 5.28.: ”Successful” OPC connection

3. GUI front end: Creating an interface: We create an intuitive and simple GUI with the functionality of In- terlocking and the ”subsystem Point.” The displays are developed by making use of the features like buttons and process points in GraphWorXTM64. The principle operation of the object controller is implemented in the form of signal and track change. The buttons and signals are assigned with the data types that are then configured to the tags-“Button1” and “Button2” in Kepware server. The process points are then used as a display with the Boolean values representing the on and off of the signal. Figures 5.29 and 5.30 show the process points whose values are of type-Boolean, displaying the operation in binary form. The on and off feature is assigned to the buttons on the interface

55 Chapter 5: Methodology - MiL Architecture

which, when pressed, shows not only the movement of the train but also the dynamic change of colors on the signal.

Figure 5.29.: A ”Process point” entry with value ”0”

Figure 5.30.: A ”Process point” entry with value ”1”

The run-time feature allows us to see the animation of the entire scenario. The press of the button “Right” enables the train to pass with the signal changing to “green” from “red.” This directs the train to the right track with the assumption in the GUI that the Point moves to “right.” Detailed simulation is presented in the next chapter with scenarios. We use these scenarios to test the model of ”subsystem Point” and to visualize the model and generate test cases with various scenarios. Figure 5.31 is the interactive GUI in the run-time environment. 4. Connecting GUI to Kepware server: OPC UA communication protocol is used as the communication-medium to connect to the server. With the database established, the steps are quite straight forward to connect to Kepware. We add the created “But- ton” tags in Kepware as the data source to all the entities on the GUI. Adding dynamics to these buttons also needs the data source to transact the values from and to a database. There are three signal lights with two buttons and one display process points. The data source for all the entities on the GUI is as follows:

{Left Button: ua:Kepware\[ThingWorx Industrial Connectivity] Chan- nel1.Device1.Button1}

{Right Button: ua:Kepware\[ThingWorx Industrial Connectivity] Channel1.Device1.Button2}

{Process point (Left) : ua:Kepware\[ThingWorx Industrial Connectiv- ity] Channel1.Device1.Button1}

56 5.1. Model-in-the-loop Architecture

Figure 5.31.: GUI emulating the operations of PLC

57 Chapter 5: Methodology - MiL Architecture

{Process point (Right) : ua:Kepware\[ThingWorx Industrial Connec- tivity] Channel1.Device1.Button2}

{Train Right: ua:Kepware\[ThingWorx Industrial Connectivity] Chan- nel1.Device1.Button2}

The signal lights turn between “green” and “red,” and the train simula- tion moves either on the “Right” track or “Left” track. To achieve this dual functionality, we add the data source in the form of expressions, as shown below:

{Signal lights (Green & Red):{{ua:Kepware\[ThingWorx In- dustrial Connectivity] Channel1.Device1.Button1}} == 1 && {{ua:Kepware\[Thing Worx Industrial Connectivity] Chan- nel1.Device1.Button2}} == 1}

{Train Left & Right: {{ua:Kepware\[ThingWorx Industrial Connectiv- ity] Channel1.Device1.Button1}} == 1 &&{{ua:Kepware\[ThingWorx Industrial Connectivity] Channel1.Device1.Button2}} == 0}

The change of values can be read and written as “Synchronous write” in the OPC Quick Client7 (Figure 5.32). The Quick client presents the additional information on Timestamp and the quality of the connectivity with the system and the external devices. A “process point” is created and assigned with a value in the quick client. It ensures connectivity with the change of values as displayed in the “Tag1.”

Figure 5.32.: Tags for ”synchronous write” in OPC Quick client

The next step is to bind all the data entries from 3 platforms and build the mashup to visualize and verify the connectivity.

5.1.5. ThingWorx Mashup Build The behavior of the SysML models are designed in the PTC Modeler. The model-execution is seen in the simulator view in SySim. As the infrastructure manager (DB Netz AG) does not get an opportunity to see the state-machine

7The OPC Quick Client grants users to read and write data, perform structured test suites, and test server performance. c Kepware.com

58 5.1. Model-in-the-loop Architecture animation of the system, the system must be validated by other means. En- abling the end user to control the system over an IoT platform is discussed and presented in this chapter. We will begin by creating the entities for the application. Then the properties and services are added to enhance the op- erational parameters of the application. In the end, the mashup is built by binding the data and visualizing the mashup. An internet browser is used to access the ThingWorx platform. Using Google chrome is suggested as it is optimized for the use of this platform. We deploy the mashup in the cloud enabling us to connect to the KepServerEX and to the Modeler over the application key. The composer environment is an end-to-end modeling application environment that helps us build the applications as GUI or mashups to stay connected to all the possible applications in today’s world of data and cloud computing. ThingWorx composer helps us to models the Things, which are the representation of physical devices and systems [Sup20]. In this chapter, we build the mashup for 2 different services. On one end, to connect to the SySim simulator and, on the other hand, to connect to the GUI through the Kepware server. Although the process differs to ex- tend the services on the IoT platform, the fundamental steps are somewhat similar with different entities on either end. We connect the mashup by cre- ating an industrial Thing “Ch1Dev1,” which identifies the GUI parameters in ThingWorx. The buttons on SySim are connected to the mashup by creat- ing ThingWorx (TWx) “PushButtonShapes” for “Left” and “Right” buttons, respectively. The steps to build mashup for both interface ends consist of 3 essential steps. The following detailed explanation includes the steps for both Sysim connection and GUI connection with TWx mashup parallelly. We can start creating this IoT solution by creating entities such as Things, Thing templates, and Thing shapes to model the application.

Figure 5.33.: Overview of entities in ThingWorx. [ c PTC ThingWorx]

59 Chapter 5: Methodology - MiL Architecture

1. Creating entities:

In general, Things are the building blocks of the application represent- ing the real-world objects. These Things inherit the attributes such as properties, services, and events from the Thing Template. The Thing Template can be composed of the Thing Shape as seen in the figure 5.33. From the section connecting Sysim with TWx elements, we have seen how the “Left” and “Right” buttons are replaced with the TWx pushbuttons. Creating new Simulation blocks and assigning them with an operation of “Setvalue” creates an automatic Thing Shape for each of the buttons in TWx. These two entities digitally represent the but- tons of the Interlocking component in the Modeler. They inherit the attributes from the “ThingButtonshape” generated from the Modeler. The Thing Shapes “SySimTWXPushbuttonRightShape” and “SySimTWXPushbuttonLefttShape” are used as a implemented base shape to create “RightButtonTemplate” and “LeftButtonTem- plate”.The ThingWorx application environment is driven by an object or the Thing-driven model. This means that the processes are repre- sented by Things. The instances are relayed on Generic Thing for both “Left” and “Right.” as the button “Things.” Then we create “Left” and “Right” Things to inherit the properties from the Thing templates. We assign the identifier of the pushbuttons in the Modeler to TWx here. On the other end, with the GUI, an Industrial Thing: Ch1Dev1 is generated in TWx. This entity acts as the industrial gateway to connect the external applications to TWx services. Next, we will add data to the entities created and bind them to the mashup interface. 2. Design mashup Interface:

Mashup is a web-page visualization used for sending and receiving the information from or to a ThingWorx model. The mashup builder feature in the platform helps us to create the visualization environment. In a nutshell, the mashup is the web page on the interface, which allows us to combine the data available within the TWx platform. The full-and-full configuration based with zero code development needed makes it easier for the user and content developers to use the application. A mashup is generally responsive or static in the platform. We use re- sponsive mashup type as it adapts to the resolution of the display of the interface being designed. Using the widgets tab, we create two buttons to trigger the data to be displayed on the interface. These buttons are assigned with the Boolean data type from the Kepware server. The but- tons are then connected over the OPC UA protocol with the GUI on the front end, explained in section Connecting GUI to KEPServerEX. The text-box widget is used to display the data in the form of Boolean values. The selected widgets are dragged and dropped to the workspace area of the platform, which is shown in the figures 5.34 and 5.35, respectively.

60 5.1. Model-in-the-loop Architecture

Figure 5.34.: Button1 denoting the ”Left” Point with Status display

Figure 5.35.: Button2 denoting the ”Right” Point with Status display

These buttons assigned with the data “SetProperties” for the industrial Thing “Ch1Dev1,” and “SetValue” for the “Left” and “Right” Things. The next step is to bind all the services with which the buttons can obtain the operational parameters.

3. Binding the data and services:

This section is divided into 2 sub-sections where we first bind the data and add service for industrial Thing to connect to the GUI. In the next subsection, the data is bound with the Button Things, and the services are added. a) Binding the data to Thing Ch1Dev1: The binding data feature is simple to assign, with a drag and drop option. The visual indicator on the individual widgets shows the options for us to drag the necessary data. Figure 5.36 shows the services that are added to the text-box widget. First, we get the existing properties created as a “gateway-Thing” from the Kepware server and bind it to the buttons created. The buttons now are assigned properties to have a defined functionality. The figure below shows the properties that have been called and assigned to the buttons. This is denoted by the filled arrows pointing out of the “GetProperties” box. This property is assigned as a “state,” which allows for the toggling between the state changes. This process is carried out for the buttons with the “state” prop- erty assigned to enable a change of state when triggered. Now, the buttons can be used to toggle between the states, but they

Figure 5.36.: Binding ”GetProperties” service to the Buttons

61 Chapter 5: Methodology - MiL Architecture

are not connected to the GUI yet. This can be achieved by as- signing the properties of the buttons in the mashup with the but- tons on the Kepware server. We add services “SetProperties” to the “Thing Ch1Dev1” on the data column. This ensures the bi- directional flow of data from and to the Kepware server. We assign the “State changed” property from the “Left” and “Right” buttons to the “Button1” and “Button2” of the “Thing Ch1Dev1”. This is denoted by the filled arrows pointing towards the “SetProperties,” as shown in figure 5.37.

Figure 5.37.: Adding ”SetProperties” service to the Buttons

We bind the result of “Left” and “Right” with the GUI buttons through the Kepware server. The text-box widget is used as the display for the status in the form of string values. The complete properties and services applied are shown in the form of connec- tions. These connections provide us with an overview of the asso- ciations between different entities in the mashup. Figures 5.39 show the connections of the ”Left” and ”Right” but- tons with buttons - ”Button1” and ”Button2” on the GUI with the ”State” type as ”GetProperties.” The “State Changed” property then set to the buttons. This suggests that when the mashup is loaded, the buttons look for properties when pressed and exhibits a state. Figure 5.38 shows the overview of the properties the buttons are assigned with.

Figure 5.38.: Connection of ”SetProperties” service with the mashup

62 5.1. Model-in-the-loop Architecture

Figure 5.39.: Connection of ”GetProperties” property with the mashup

63 Chapter 5: Methodology - MiL Architecture

(a) ”LeftThing” (b) ”RightThing”

Figure 5.40.: ”Setvalue” service assigned to ”LeftThing” and ”RightThing”

b) Binding the data to Thing Left and Thing Right: We start by adding the service “SetValue” to both the buttons with the parameter “NewVal.” This parameter is assigned with the property “StateChanged” to trigger the change of state with the press of the button. The figures 5.40a and 5.40b show the data and services that are bound with the “Left” and “Right” Things. The filled-up arrow denotes the property that is already assigned. Expressions are used to convert the button entry into the Boolean type entry. A parameter is added with the default value as ”False” to change the data type to Boolean. The expression is written as a script to enable it for both the buttons. As seen from figure 5.41, we assign the operation and convert the button entry into Boolean. The output base type is selected as “Number” to ensure we have either “0” or “1” as the only output values in the simulation results. This indicates the Point moving to either “Left” or “Right.”

Figure 5.41.: ”Expression” service in script

The “Changed” and “Output” service, as seen in the associations from the figures 5.42 and 5.43, is used to send the output values in the form “0” and “1” when the state is changed. The association diagram reveals how the Boolean input is converted and assigned as a numeric entry for both the buttons. This state change is the entry condition for the button press. This expression auto evaluates

64 5.1. Model-in-the-loop Architecture

the data entry and converts it to the ”number” entry that is easy to understand what the actual behavior of the simulation is.

Figure 5.42.: ”ConvertButton1” expression added as a service to ”LeftThing”

Figures 5.42 and 5.43 also show the associations of the button with the Things - Thing Left and Thing Right. We can also see the associated services “SetValue” as an input parameter.

The next step is to visualize the executables running in all three interfaces- SySim executables, ThingWorx mashup, and the GUI emulating the PLC controls. We also simulate and test the models with all 3 platforms acting as a hybrid testbed.

65 Chapter 5: Methodology - MiL Architecture

Figure 5.43.: ”ConvertButton2” expression added as a service to ”RightThing”

66 6. Results - Simulation and Testing

In this chapter, we present the results in the form of simulation and testing. The SysML logic model is executed in the form of SySim executables. The results of the mashup built on the ThigWorx platform are discussed. Later, we will discuss the results of the testing based on the test on the Hybrid testbed. It begins with formulating the model visualization results based on its behavior on the Hybrid testbed. Later, in this chapter, we generate the test cases for the complete model and present the results of model verification based on the test cases and the Model-in-the-Loop simulations.

6.1. Model Simulation on Hybrid Testbeds

In this section of the chapter, the results from simulation are presented. The SySim simulation, as viewed on the simulation scenario dashboard, is dis- played. The simulation scenarios are shown as seen in the application with the animation of the state machines running in tandem. The results of in- tegration with the IoT platform are analyzed, and the complete behavior of the system in the form of a model-view is illustrated. As shown in the figure 6.1, we have three interfaces that allow the user to control the model simula- tion. The three platforms - GUI emulating the PLC interlocking, ThignWorx Mashup, and the Modeler platform with the SySim simulation platform - is used to show their respective functionalities with the control options allowing the user to establish the connection, simulate, and test the system. The section is divided into three subsections where we present the individual platforms and explain in-detail the connection between the platforms to show how the model is tested against the PLC.

6.1.1. GUI Simulation The steps needed in creating the front-end of the GUI and the back-end steps in establishing the connection with the Kepware server have already formu- lated in this section - Connecting GUI to KEPServerEX. We will now use the interface to simulate the PLC interlocking operation. As mentioned ear- lier, we will see the principle operation scenarios in this section. The GUI is used to reflect the scenarios by the real-hardware PLC interlocking. The PLC in operation is the HImatrix interlcking system from HIMA for the signaling technology in DB Netz AG. The principle operation of the GUI is to emulate the interlocking system, which provides authority to the ”subsystem Point” to switch the Points through Point machine. We use Boolean operation as the dynamic behavior of the command is based on the “toggle value.” It makes

67 Chapter 6: Results - Simulation and Testing

Figure 6.1.: Testing on Hybrid Testbed sense to use the toggling behavior as we deal with the buttons to command “Left” and “Right.” In the GUI, the command parameters are set to “Value one” and “Value Two,” which can either be “Zero” or “One.” From the figures 6.2, 6.3, 6.5, and 6.6, we can see the four command properties we have assigned to the buttons to move the Point to either left or right. These properties re- flect as ”True” or ”false” in the Button1 and Button2, respectively. In the GUI, we conceptualize the Point switching with the train on the track moving in the respective direction. Based on this, we have two scenarios possible - Left and Right.

1. Scenario-Left:

Figure 6.2.: Command property ”True” for button ”Turn Left”

Figure 6.3.: Command property ”True” for button ”Turn Left”

With the data source being already assigned to the process points of the buttons and the buttons, we can now see the dynamic behavior of the GUI entities in the runtime. The runtime option allows us to see the configuration of the train on the track in a dynamic state. When the

68 6.1. Model Simulation on Hybrid Testbeds button “Turn Left” is pressed, the toggle value of the button gets as- signed to “True.” This property initiates the toggle value to “1,” making the process point to show the same value. This sets the GUI entity - train - to move on the track where the Point is switched to “Left.” It is to be noted that the signaling entity - Point - is not directly reflecting as a mechanism in the GUI since we see the operation of the Point when the train is set to move. As we can see from the figure 6.4, the train is moving on the “left” track with the “Turn Left” button pressed. We also see the data “1” being assigned as the toggle value in the process point.

Figure 6.4.: Command property ”True” for button ”Turn Left”

69 Chapter 6: Results - Simulation and Testing

2. Scenario-Right:

Figure 6.5.: Command property ”True” for button ”Turn Right”

Figure 6.6.: Command property ”False” for button ”Turn Right”

Similar to the previous scenario, when the button “Turn Right” is pressed, the toggle value of the button gets assigned as “True.” This changes the property of the toggle value from “0” to “1.” This property is reflected in the process point as the binary value “1.” As seen from the figure 6.7, the GUI entity - train - is set to move on the right track. This implies that the Point is being switched to “Right” with the press of the button “Turn Right.” For safety reasons, the interlocking checks if any other Point switch requests are in line. This property can be shown in the figure. We can see the “Turn left” button pressed again to finish the “left” operation. This feature displays how the safety checks are being carried out by the digital interlocking system to ensure the conflict-free movement of the train.

6.1.2. SySim Model Execution In this subsection of the chapter, we use SySim as the first step to execute the models which we have already set up (”subsystem Point” and Interlocking). With this step, we will see how SySim coordinates the model execution of the SysML logic. This step helps in visualizing the behavior of the models and gaining initial grants from the stakeholders. The “PM” and “IXL” models, here, are translated into the executable models first. We have two main blocks with input parameters in the form of pushbuttons on “IXL” and the output parameters in the form of “movement” and “display” on “PM.” The behavior of the entire simulation block is implemented in this simulator. We start the process by running the SySim simulation on the simulation block. The assigned stereotyped recognize the models for the simulation. This triggers the generation of SySim model execution platform in the Visual Basic application. Both the SySim scenario and the SySim control blocks get mapped to Visual Basic form. The process can be classified into four main steps:

70 6.1. Model Simulation on Hybrid Testbeds

Figure 6.7.: Command property ”True” for button ”Turn Right”

• Prepare the model from the SySim scenario by pressing the “EXE” but- ton from SySim control to generate a VB project (figure below).

• Design the interface of the VB form in the Visual Studio project accord- ing to the needs of our model.

• Build and run the Sysim scenario using VB.

• Run the state machine animation along with the SySim Simulator.

71 Chapter 6: Results - Simulation and Testing

By following the above mentioned three steps, we make sure the SySim model execution is ready to run, and all the model files are added to the Visual Studio project. We start the simulation by pressing “Run” in Visual Studio. The Simulation scenario dashboard automatically opens with no dis- play on the display column. The dashboard is created with four buttons and two display boards to emulate the interface of the state machines using the “toolbox” option in Visual Studio, as shown in figure 6.8. We coordinate the state machines with this simulation dashboard by pressing the “RUN/Play” button on the dashboard. In parallel, we start the state machine simulation in the Modeler by pressing the “RUN simulation” button to animate the block behavior.

Figure 6.8.: SySim simulator block to execute the models

1. Scenario - Left:

We have both the SySim simulation dashboard in the form of an exe- cutable and the animation of the state machines running in parallel. We control the simulation using the dashboard buttons. The initial state has no guard condition, which makes “NO End Position” the default initial state. With the press of the button “Left” on the dashboard, we trigger the transition with the guard condition “Move Left:= 0”. The transition is fired, and the state transits to the new state “Left.” This also sends the state action “Status Update IXL/Status12:= “LEFT””

72 6.1. Model Simulation on Hybrid Testbeds

to the IXL state “Get Status.” The transition is fired, and the state is already moved to the new state “Left,” as shown in the figure 6.10. The new active state is shown in red, while the inactive states are shown in black, and the last active state is shown in blue. For the status to be displayed, we press the “Status” button on the dashboard. Figure C.2 shows the dashboard with the status “LEFT.” Now, we move to the next scenario, which is Scenario-Right.

Figure 6.9.: Simulator displaying the status ”Left”

2. Scenario - Right:

Like the previous scenario, we press the button and see the animation of the state machines for the Point moving to “Right.” The “Left” but- ton pressed on the dashboard triggers the transition with the guard condition “Move Right:= 0.” The new state reached is “Right” from state “Left.” IXL state “Get Status” receives the state action “Sta- tus Update IXL/Status12:= “RIGHT” (figure 6.12). This is displayed on the dashboard with the “Status” button pressed (figure 6.11). The new active state and the transition fired can be seen in red. The tran- sitions are repeated either from the “left” state or “No End Position” state. The SySim scenario dashboard for “Right,” and the animation of the state machine is shown in the figures 6.11 and 6.13. Ideally, the “No End Position” state refers to the intermediate state of the Point moving one of the end positions. The output log generated in the Modeler can be used for documentation purposes. The animation log created while running the animation is attached in figure 6.14. The log clearly states the events entry and exit along with the transitions fired. The time frame capture log helps to analyze the instances created and the simulation run. In the next section, we will generate the test cases that are used for testing the model.

73 Chapter 6: Results - Simulation and Testing

Figure 6.10.: Animation of Point changing to ”Left” state

74 6.1. Model Simulation on Hybrid Testbeds

Figure 6.11.: Simulator displaying the status ”Right”

Figure 6.12.: Animation of IXL state ”Get Status”

75 Chapter 6: Results - Simulation and Testing

Figure 6.13.: Animation of Point changing to ”Right” state

76 6.1. Model Simulation on Hybrid Testbeds

Figure 6.14.: Output log of the animation of state machines

77 Chapter 6: Results - Simulation and Testing

6.1.3. Mashup Visualization Once we have all the entities for the connectivity from the sections above, We bring them together to form a project which can be called for the mashup connectivity. Figure 6.15 shows the essential entities needed to establish the communication between the GUI, Kepware server, and SySim simulator with the ThingWorx native interface.

Figure 6.15.: Entities involved in this Project

The summary of the entities are as follows: • Ch1Dev1 - The Industrial Thing serves as the interface between the GUI that uses a standard OPC UA protocol and the TWx platform. • KEPServerEX - The IoT Thing serves as the gateway to connect Thing- Worx Industrial connectivity (TIC) to the IoT platform. • ButtonTemplates: The Left and Right ButtonTemplates serve as the basis for the “LeftThing” & “RightThing” to be developed upon. • Thing (Left & Right): Things are the entities with which we execute the properties, services, and events of the ThingTemplate. • Pointmachine (AppKey): The Application key is created in TWx web application with an expiry date to connect to different models on various

78 6.1. Model Simulation on Hybrid Testbeds

applications. This encrypted key enables a secure connection between different platforms.

• SySim mashup: Mashup is the dashboard on which the interface features are developed. The mashup interface is used to display the data from the SysML model.

• SySimTWXPushbuttons: The SySimPushbutton is the shape that is generated automatically in TWx web application when we replace the SySim pushbuttons with TWx pushbutton in the Modeler.

With the mashup dashboard, we can now visualize the attributes that are built in the model. The “View mashup” option in the web application of TWx allows us to visualize the model with the assigned properties. The TWx web application is used as an interface where all the features that are designed are visualized dynamically. The connection to the SysML model and the GUI is made possible with this application. The TWx application not only serves as the medium where the connectivity is made possible but also has enhanced features that can be made useful to check for the model behavior. We avail of these features by adding the “Button” and “Display” entities on the dashboard. We are simulating the whole operation of the ”subsystem Point” and Interlocking system with two simple buttons and their display box, which shows the status in the form of numeric entry. Although we do not use this dashboard as a standalone test bench in TWx application for the verification of the model, this serves as the essential component in hybrid testbed. The mashup visualization consists of services from Industrial Thing and PushButtons - LeftThing and RightThing. While the mashup is viewed, the output log can be generated for documentation purposes. From figure 6.16, the summary of all the services that are assigned to mashup is shown in the output log. We can clearly notice the properties that are assigned, service parameters that we use to call the Thing, and the operation of each parameter. Furthermore, the “red” and “green” indications on the debug log allows us to analyze if there are any errors or if there is a connectivity issue. From this mashup, we see the services in action with the toggling of the buttons from “0” to “1.” “Button-1” toggled to “1” means that the Point is switched to “Left” and “Button-1” toggled back to “0” means that the Point stays in the “Left” position unless otherwise triggered. Similarly, “Button- 2” toggled to “1” moves the Point to “Right” position, and the position is retained until and unless a different direction is triggered again. Naturally, the operation triggers are taken up by the Interlocking system to verify for safety deadlocks, and only then the Point machine is allowed to switch to any position. Since the operation of the Interlocking system as a standalone system is out of the scope of this thesis work, we consider it on an interface-level with the Point machine. The next step is to generate test cases to test the model. In the next section, we will see how the model is verified with the test cases for different scenarios.

79 Chapter 6: Results - Simulation and Testing

Figure 6.16.: Services in Mashup dashboard

6.2. Model Verification - Test Cases

The requirements for the SCI-P EULYNX model is specified in the document [EUL20b]. We are using the simpler version of this SCI-P model to analyze and conduct the research work. We perform the research work to test the model, to enable the connectivity to an IoT platform, and to connect it to a GUI. Although the model is not developed to the complete requirements of EULYNX specification, we still model the ”subsystem Point” and the Interlocking system according to the requirements needed in the operation of the system. In this section, we will create the test cases for various scenarios arising from three platforms. These test cases are used to test the model for its intended behavior. We have proved the test cases for many different

80 6.2. Model Verification - Test Cases scenarios. Some test cases are initially not proven, which indicate the errors in the model and the connectivity. We rectify the errors in the newer versions of the test cases, which were proven “False.” With this approach, we go many steps ahead in the verification of SysML model. This approach tests the system for various scenarios. The errors are observed and rectified as compared to the approach of Model checking with the simulation on SySim executable alone.

Test Case Generation (TCG)

Test Case ID: [T01]

Title: No transition to “Left” state Test Case Description [T01]: The trigger of the“Left” button in SySim should not trigger the state machine to make a transition to “Left” from either “Right” or “No End Position” state as we have replaced the SySim “Left” button with ThingWorx “Left” Pushbutton that allows us to control the state machine via mashup interface. Pre-condition: A Leftpushbutton SySim shape should be generated as a ThingWorx entity for the SySim “Left” button. Post-condition: The state “Left” should not be triggered by the event of pressing “Button-1” in mashup. Pass/Fail: Pass

Test Case ID: [T02]

Title: No transition to “Right” state Test Case Description [T02]: The trigger of the “Right” button in SySim should not trigger the state machine to make a transition to “Right” from either “Left” or “No End Position” state as we have replaced the SySim “Right” button with ThingWorx “Right” Pushbutton that allows us to control the state machine via mashup interface. Pre-condition: A Rightpushbutton SySim shape should be generated as a ThingWorx entity for the SySim “Right” button. Post-condition: The state “Right” should not be triggered by the event of pressing “Button-2” in mashup. Pass/Fail: Pass

Test Case ID: [T03]

Title: “Button-1” toggled in mashup Test Case Description [T03]: Since the SySim buttons are replaced with ThingWorx pushbuttons, we can control the state machine in the Modeler with the mashup buttons now. “Button-1” denotes the transition to “Left” state in SySim with the status display toggling to “1” indicating that the

81 Chapter 6: Results - Simulation and Testing

Point has switched to “Left.” Pre-condition: A Leftpushbutton SySim shape should be generated as a ThingWorx entity for the SySim “Left” button. Post-condition: The state “Left” should be triggered by the event of pressing “Button-1” in mashup. Pass/Fail: Pass

Test Case ID: [T04]

Title: “Button-2” toggled in mashup Test Case Description [T04]: Since the SySim buttons are replaced with ThingWorx pushbuttons, we can control the state machine in the Modeler with the mashup buttons now. “Button-2” denotes the transition to “Right” state in SySim with the status display toggling to “1,” indicating that the Point has switched to “Right.” Pre-condition: A Rightpushbutton SySim shape should be generated as a ThingWorx entity for the SySim “Right” button. Post-condition: The state “Right” should be triggered by the event of pressing “Button-2” in mashup. Pass/Fail: Pass

Test Case ID: [T05]

Title: “Left” event trigger in the GUI Test Case Description [T05]: The state machine in the Modeler should be controlled by the GUI to establish the operational connectivity between the working model and the PLC. This is achieved by checking by pressing the button “Left” in the GUI. The expected behavior is to see the transition in the state to “Left” from either “Right” or “No End Position.” We also see the GUI simulation with the track animation to “Left” in the runtime environment of GraphWorx. Pre-condition: The “Left” GUI button should be connected to the mashup via Industrial gateway Thing - Ch1Dev1. Post-condition: The state “Left” should be triggered by the event of pressing “Left” in the GUI. Pass/Fail: Pass

Test Case ID: [T06]

Title: “Right” event trigger in the GUI Test Case Description [T06]: The state machine in the Modeler should be controlled by the GUI to establish the operational connectivity between the working model and the PLC. This is achieved by checking by pressing the

82 6.2. Model Verification - Test Cases button “Right” in the GUI. The expected behavior is to see the transition in the state to “Right” from either “Left” or “No End Position.” We also see the GUI simulation with the track animation to “Right” in the runtime environment of GraphWorx. Pre-condition: The “Right” GUI button should be connected to the mashup via Industrial gateway Thing - Ch1Dev1. Post-condition: The state “Right” should be triggered by the event of pressing “Right” in the GUI. Pass/Fail: Pass

Test Case ID: [T07(a)]

Title: “Left” event trigger in the GUI to mashup display Test Case Description [T07(a)]: This test revealed that the button triggers from the GUI are not transferred to display the change of status in the mashup. The numeric entries “0” and “1” are assigned to indicate the point switching to “off” and “on.” From this test, we noticed that the GUI animation is being executed. However, the display is not changed to reflect the animation. This is rectified in the following test cases. Pre-condition: The “Left” GUI button should be connected to the ”Button-1” via “subscriptions” in mashup. Post-condition: The GUI “Left” button should trigger the change of value from “0” to “1” in the display of “Button-1” in mashup. Pass/Fail: Fail [Problem rectified in T07(b)]

Test Case ID: [T07(b)]

Title: “Left” event trigger in the GUI to mashup display Test Case Description [T07(b)]: From this re-evaluated test case, we have rectified the status display error. Now, the “Left” Button pressed in the GUI changes the button toggle in the mashup and changes the display to “1,” indicating that the button parameters are also connected with the mashup. This is achieved by adding services to the text box (Display field) of “Button-1”. Pre-condition: The “Left” GUI button should be connected to the”Button- 1” via “subscriptions” in mashup. Post-condition: The GUI “Left” button should trigger the change of value from “0” to “1” in the status display of “Button-1” in mashup. Pass/Fail: Pass

Test Case ID: [T08(a)]

Title: “Right” event trigger in the GUI to mashup display

83 Chapter 6: Results - Simulation and Testing

Test Case Description [T08(a)]: This test revealed that the button triggers from the GUI are not transferred to display the change of status in the mashup. The numeric entries “0” and “1” are assigned to indicate the Point switching to “off” and “on.” From this test, we noticed that the GUI animation is being executed. However, the display is not changed to reflect the animation. This is rectified in the following test cases. Pre-condition: The “Right” GUI button should be connected to the”Button-2” via “subscriptions” in mashup. Post-condition: The GUI “Right” button should trigger the change of value from “0” to “1” in the display of “Button-2” in mashup. Pass/Fail: Fail [Problem rectified in T08(b)]

Test Case ID: [T08(b)]

Title: “Right” event trigger in the GUI to mashup display Test Case Description [T08(b)]: From this re-evaluated test case, we have rectified the status display error. Now, the “Right” Button pressed in the GUI changes the button toggle in the mashup and changes the display to “1,” indicating that the button parameters are also connected with the mashup. This is achieved by adding services to the text box (Display field) of “Button-2”. Pre-condition: The “Right” GUI button should be connected to the”Button-2” via “subscriptions” in mashup. Post-condition: The GUI “Right” button should trigger the change of value from “0” to “1” in the status display of “Button-2” in mashup. Pass/Fail: Pass

Test Case ID: [T09]

Title: “Button-1” trigger in the mashup to GUI Test Case Description [T09]: The toggling of buttons in the mashup reveals the connectivity of the GUI with the mashup through the OPC UA server. “Button-1” is assigned with the Boolean type register values in the Kepware server. “Button-1” in the mashup interface is used to move the train to the “Left” track in the GUI. Pre-condition: “Button-1” should have the services added in mashup with the Industrial Thing - Ch1Dev1. Post-condition: “Button-1” toggled to “On” in mashup should move the train to “Left” in GUI Pass/Fail: Pass

Test Case ID: [T10]

84 6.2. Model Verification - Test Cases

Title: “Button-2” trigger in the mashup to GUI Test Case Description [T10]: The toggling of buttons in the mashup reveals the connectivity of the GUI with the mashup through the OPC UA server. “Button-2” is assigned with the Boolean type register values in the Kepware server. “Button-2” in the mashup interface is used to move the train to the “Right” track in the GUI. Pre-condition: “Button-2” should have the services added in mashup with the Industrial Thing - Ch1Dev1. Post-condition: “Button-2” toggled to “On” in mashup should move the train to “Right” in GUI Pass/Fail: Pass

Test Case ID: [T11(a)]

Title: “Button-1” mashup status Test Case Description [T11(a)]: The display box in the mashup interface is Boolean type in text format. However, the values “0” and “1” are used to interpret the status in both GUI and the SySim. Hence we need to see the same values being reflected in the mashup. This test fails as the numeric entries are not visible with the toggling of the “Button-1”. Pre-condition: Status display of “Button-1” should be converted to the numeric entry using expressions in the mashup services. Post-condition: “Button-1” toggled to “On” in mashup should change the value of the display to “1”. Pass/Fail: Fail [Problem rectified in T11(b)]

Test Case ID: [T11(b)]

Title: “Button-1” mashup status Test Case Description [T11(b)]: From the test case T11(a), we can see the error in the status display field. We rectify this by adding expressions for both “Button-1” in the mashup. The expressions consist of a script that converts the Boolean values to numeric entries - “0” or “1” based on the status of the Point. Pre-condition: Status display of “Button-1” should be converted to the numeric entry using expressions in the mashup services. Post-condition: “Button-1” toggled to “On” in mashup should change the value of the display to “1”. Pass/Fail: Pass

Test Case ID: [T12(a)]

Title: “Button-2” mashup status

85 Chapter 6: Results - Simulation and Testing

Test Case Description [T12(a)]: The display box in the mashup interface is of Boolean type in text format. However, the values “0” and “1” are used to interpret the status in both GUI and the SySim. Hence we need to see the same values being reflected in the mashup. This test fails as the numeric entries are not visible with the toggling of the “Button-2”. Pre-condition: Status display of “Button-2” should be converted to the numeric entry using expressions in the mashup services. Post-condition: “Button-2” toggled to “On” in mashup should change the value of the display to “1”. Pass/Fail: Fail [Problem rectified in T12(b)]

Test Case ID: [T12(b)]

Title: “Button-2” mashup status Test Case Description [T12(b)]: From the test case T12(a), we can see the error in the status display field. We rectify this by adding expressions for both “Button-2” in the mashup. The expressions consist of a script that converts the Boolean values to numeric entries - “0” or “1” based on the status of the Point. Pre-condition: Status display of “Button-2” should be converted to the numeric entry using expressions in the mashup services. Post-condition: “Button-2” toggled to “On” in mashup should change the value of the display to “1”. Pass/Fail: Pass

86 7. Conclusion and Future Work

In the final chapter of this thesis work, we present the conclusion of the research work in the section Conclusion with regards to the research and development. In the next section Future Work, we briefly summarize the major areas where this research work can be used as a foundation for future endeavors in the railway signaling at Deutsche Bahn and other sectors where safety is a major concern. In the last section Personal Thoughts, my personal thoughts on the research work are presented.

7.1. Conclusion

Testing of SysML models using a Hybrid testbed appears to be viable and efficient considering the simulation with the Model-in-the-Loop. This the- sis work presents an interesting and an illustrated view of how the SysML models can be combined with the IoT to test and check for errors. We have investigated a systematic approach to improve the current model verification and validation approach taken up by DB Netz AG. We understood from the EULYNX specifications that the state machines have a significant impact on how the testing is done by most European railway infrastructure managers. In EULYNX, the expected system behaviour visible at the system interface level is specified using state machines. This specified behaviour is verified and validated by simulation-based model testing carried out by IM’s assuming the real environment. With this research work, we have presented a new approach to integrate the real environment in this verification and validation process. With this thesis work, we have added an extra layer of testing method with MiL simulations on a hybrid test bed. This mechanistic approach helps us understand how the same SysML model behaves with respect to the GUI that emulates the behavior of the real interlocking. With this, we provide a framework to verify that the specification model also behaves as intended when connected to the real world. The test cases that are generated help us understand the model behavior at a greater depth. This step is essential for the SysML model to be tested and implemented against real hardware. The ”subsystem Point” model with the railway interlocking system is first developed as a SysML model in the Windchill Integrity Modeler. The button- attributes are assigned to the mashup in ThingWorx composer to test the model. Then, the GUI is developed with the train-track animation showing the behavior of the ”subsystem Point” by controlling the interlocking commands. The GUI is the emulator to test the model for its expected behavior. We have proved that the SysML model is working as expected, along with the test cases generated.

87 Chapter 7: Conclusion and Future Work

The standardization of the railway signaling interfaces by EULYNX has revolutionized the approach of IM’s like Deutsche Bahn in relying on suppliers for their technical competence. This thesis work showcases the ability to integrate the specification models into a real environment and prove their compliance. Up to now the IM’s had to assume the behaviour of the real environment and consider these assumptions in there test cases. This research work serves as one of the essential first-steps in gaining technical competence with regards to research & development - modeling, testing, and implementing the research work.

7.2. Future Work

This research work can be used as an extension to other interesting opportu- nities. This work could serve as a basis for the following future work:

• Expand the model with EULYNX SCI-P specifications: In this research work, we have created a lesser complicated SysML model to lay the research foundations. We have still considered the operational parameters of the model from the EULYNX specifications. However, the model is stripped of its complicated behavioral properties. One can consider to expand the model by adding all the other specifications for the SCI-P interface and use this work as the foundation to integrate the fuller version of the model in the IoT platform.

• Test the model against the real PLC: In this research work, the SysML model is tested against the GUI and the operational interface of the mashup. We have generated 12 different test cases to test the model. This work can be used in the future to replace the GUI with the real hardware and test the SysML model for its behavior in its entirety.

• Add features in SySim to control the ThingWorx mashup directly: Currently, we have added enough features in the SySim model to com- municate to the IoT platform via the mashup interface. In this research work, we have not considered adding the features to have bi-directional control. One can learn more on ThingWorx and SySim and execute these additional features.

• Use this concept of learning to implement it in other domains: With this research work, we have established the significance of Model- Based Engineering, and its integration with IoT platform that enhances the testing results of the model. This methodology proves to be a sig- nificant option to consider in other domains where safety is critical, and the testing depends on the SysML Models. This combination of domains - MBSE and integration of IoT - will be useful for other sectors as it is with railway signaling.

88 7.3. Personal Thoughts

• Use advanced features of PTC ThingWorx: Some advanced features like ”Alert - notifications” of PTC ThingWorx can be made useful. As seen from the Point model, we could have conflicting behavior regarding the operation of ”subsystem Point.” The ”Alert” feature can trigger a warning to the Interlocking system or to the Traffic safety Personnel for when problems like these persist. These simple yet important measures can add an extra layer of safety to the system.

7.3. Personal Thoughts

I truly enjoyed the process of conducting my research work and writing my the- sis. I have learned and reflected on what I learned from the many hours of the project work. Writing my thesis with an organization helped me understand and gain experience in the day-to-day work culture, professional thinking, and problem-solving. Seeing my skills and knowledge be put into practice is a motivating factor to achieve more. I have gained new colleagues and friends along the way who also share the same passion as me on both academic and personal levels. As a Master’s student, I sincerely appreciate the support and the efforts taken by the mentors from DB Netz AG and TU Kaiserslautern to help me make this research work possible. This thesis work, among many others, is one step closer to making the best use of technologies in today’s world.

89

Bibliography

[20] Alstom to conduct world-first ATO tests on regional trains in Ger- many. 2020. url: https://www.globalrailwayreview.com/ news/101133/alstom-ato-tests-regional-trains-germany/ (visited on 06/04/2020). [50120] CENELEC-EN 50126-1. “GlobalSpec”. In: (2020). url: https: //standards.globalspec.com/std/10262901/EN%2050126-1 (visited on 05/18/2020). [Ahm+18] Afsana Ahmed, Kazi Rifah Noor, Ahmed Imteaj, and Tanveer Rahman. “Unmanned Multiple Railway Gates Controlling and Bi-directional Train Tracking with Alarming System using Prin- ciples of IoT”. In: 2018 International Conference on Innovations in Science, Engineering and Technology (ICISET). IEEE. 2018, pp. 486–491. [AL18] Nesa Asoudeh and Yvan Labiche. “Life sciences-inspired test case similarity measures for search-based, FSM-based software test- ing”. In: European Conference on Modelling Foundations and Ap- plications. Springer. 2018, pp. 199–215. [Ama+17] Domenico Amalfitano, Nicola Amatucci, Vincenzo De Simone, Vincenzo Riccio, and Fasolino Anna Rita. “Towards a Thing-In- the-Loop approach for the Verification and Validation of IoT sys- tems”. In: Proceedings of the 1st ACM Workshop on the Internet of Safe Things. 2017, pp. 57–63. [AML19] Zoran Zˇ Avramovi´c,DraˇzenM Marinkovi´c,and Igor T Lastri´c. “Digitalization of Railways–ICT Approach to the Development of Automation”. In: JITA-JOURNAL OF INFORMATION TECH- NOLOGY AND APLICATIONS 17.1 (2019). [ANS19] Mounifah Alenazi, Nan Niu, and Juha Savolainen. “SysML Mod- eling Mistakes and Their Impacts on Requirements”. In: 2019 IEEE 27th International Requirements Engineering Conference Workshops (REW). IEEE. 2019, pp. 14–23. [AP18] Bashar Alshboul and Dorina C Petriu. “Automatic Derivation of Fault Tree Models from SysML Models for Safety Analysis”. In: Journal of Software Engineering and Applications 11.5 (2018), pp. 204–222. [Bia+18] Chong Bian, Shunkun Yang, Tingting Huang, Qingyang Xu, Jie Liu, and Enrico Zio. “Degradation detection method for railway point machines”. In: arXiv preprint arXiv:1809.02349 (2018).

91 Bibliography

[BK08] Eckard Bringmann and Andreas Kr¨amer.“Model-based testing of automotive systems”. In: 2008 1st international conference on software testing, verification, and validation. IEEE. 2008, pp. 485– 493. [Bon+16] Andrea Bonacchi, Alessandro Fantechi, Stefano Bacherini, and Matteo Tempestini. “Validation process for railway interlock- ing systems”. In: Science of Computer Programming 128 (2016), pp. 2–21. [Boo+19] A. Boockmeyer, J. Beilharz, L. Pirl, and A. Polze. “Hatebefi: Hy- brid Applications Testbed for Fault Injection”. In: 2019 IEEE 22nd International Symposium on Real-Time Distributed Com- puting (ISORC). 2019, pp. 97–98. [Bot+16] Alessio Botta, Walter De Donato, Valerio Persico, and Antonio Pescap´e.“Integration of cloud computing and internet of things: a survey”. In: Future generation computer systems 56 (2016), pp. 684–700. [Bou+19] Racem Bougacha, Abderrahim Ait Wakrime, Slim Kallel, Rahma Ben Ayed, and Simon Collart-Dutilleul. “A Model-based Ap- proach for the Modeling and the Verification of Railway Signaling System”. In: Proceedings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineering. SCITE PRESS-Science and Technology Publications, Lda. 2019, pp. 367– 376. [Bou18] MS Bouwman. “A model-based test platform for rail signalling systems”. PhD thesis. Master’s thesis, Eindhoven University of Technology, 2018. [Boy+18] Hugh Boyes, Bil Hallaq, Joe Cunningham, and Tim Watson. “The industrial internet of things (IIoT): An analysis framework”. In: Computers in Industry 101 (2018), pp. 1–12. [Bud+14] Ramachandra Budihal, R Surendran, N Mahendravarman, and Hirisave S Jamadagni. “ANRC hybrid test bed implementation and an End-to-End performance characterization of dynamic spectrum access”. In: 2014 International Conference on Advances in Computing, Communications and Informatics (ICACCI). IEEE. 2014, pp. 1175–1182. [Bui17] NL Bui. An analysis of the benefits of EULYNX-style requirements modeling for ProRail. 2017. [Cap+12] J Capers et al. “Software Defect Origins and Removal Methods”. In: Namcook Analytics LLC (2012). [CEN20] CEN. “Railways”. In: (2020). url: https : / / www . cen . eu / work/Sectors/Transport/Pages/Railways.aspx (visited on 05/18/2020).

92 Bibliography

[Chu+19] Tran-Tuan Chu, Van Tong, Hai Anh Tran, Sami Souihi, Duc Quang Tran, and Abdelhamid Mellouk. “NextLab: A new hybrid testbed and development platform for Software-defined Network- ing”. In: Proceedings of the Tenth International Symposium on Information and Communication Technology. 2019, pp. 186–190. [DB19] Michael Juris (DB). “Virtual Certification: State of the art, gap analysis and barriers identification, benefits for the Rail Indus- try”. In: (2019). url: https://projects.shift2rail.org/. [Dij12] Edsger W Dijkstra. Selected writings on computing: a personal perspective. Springer Science & Business Media, 2012, pp. 60–66. [DVA19] SD Dewasurendra, AC Vidanapathirana, and SG Abeyratne. “In- tegrating runtime validation and hardware-in-the-loop (HiL) test- ing with V & V in complex hybrid systems”. In: Journal of the National Science Foundation of Sri Lanka 47.4 (2019). [EUL20a] EULYNX. EULYNX partners. 2020. url: https://eulynx.eu/. [EUL20b] EULYNX.EU. “20191202 EULYNX System Definition Appendix A1 Eu Doc 7 A1 v3 2 (0 A)”. In: (2020). url: https://eulynx. eu / index . php / documents / published - documents / open - availability/baseline-set-3 (visited on 06/08/2020). [FC10] Tongrang Fan and Yanzhao Chen. “A scheme of data manage- ment in the Internet of Things”. In: 2010 2nd IEEE Interna- tionalConference on Network Infrastructure and Digital Content. IEEE. 2010, pp. 110–114. [FMS15a] Sanford Friedenthal, Alan Moore, and Rick Steiner. “Chapter 1 - Systems Engineering Overview”. In: A Practical Guide to SysML (Third Edition). Ed. by Sanford Friedenthal, Alan Moore, and Rick Steiner. Third Edition. The MK/OMG Press. Boston: Mor- gan Kaufmann, 2015, pp. 3–14. isbn: 978-0-12-800202-5. doi: https://doi.org/10.1016/B978-0-12-800202-5.00001-1. url: http://www.sciencedirect.com/science/article/pii/ B9780128002025000011. [FMS15b] Sanford Friedenthal, Alan Moore, and Rick Steiner. “Chapter 2 - Model-Based Systems Engineering”. In: A Practical Guide to SysML (Third Edition). Ed. by Sanford Friedenthal, Alan Moore, and Rick Steiner. Third Edition. The MK/OMG Press. Boston: Morgan Kaufmann, 2015, pp. 15–29. isbn: 978-0-12-800202-5. doi: https://doi.org/10.1016/B978-0-12-800202-5.00002- 3. url: http://www.sciencedirect.com/science/article/ pii/B9780128002025000023. [FMS15c] Sanford Friedenthal, Alan Moore, and Rick Steiner. “Chapter 3 - Getting Started with SysML”. In: A Practical Guide to SysML (Third Edition). Ed. by Sanford Friedenthal, Alan Moore, and Rick Steiner. Third Edition. The MK/OMG Press. Boston: Mor- gan Kaufmann, 2015, pp. 31–51. isbn: 978-0-12-800202-5. doi:

93 Bibliography

https://doi.org/10.1016/B978-0-12-800202-5.00003-5. url: http://www.sciencedirect.com/science/article/pii/ B9780128002025000035. [FV04] Lidia Fuentes-Fern´andezand Antonio Vallecillo-Moreno. “An in- troduction to UML profiles”. In: UML and Model Engineering 2 (2004), pp. 6–13. [GG19] Marie Gehrmann and Charlotte G¨abel. “Using state machines to test for verification and acceptance”. In: SIGNALLING + DATACOMMUNICATION (111) 7+8/ (2019). (Visited on 01/05/2020). [Glo20] 2019. Product-Eurostat Glossary for transport statistics-5th edi- tion. “Glossary for transport statistics”. In: (2020). url: https: / / ec . europa . eu / eurostat / web / products - manuals - and - guidelines/-/KS-GQ-19-004 (visited on 04/26/2020). [Gra20] GraphWorx64. “GraphWorX64 Overview”. In: (2020). url: https://docs.iconics.com/V10.96/GENESIS64/Help/Apps/ GWX/GWX10001001_GraphWorX64.htm (visited on 04/18/2020). [Gro20] AGICO Group. “What is railway turnout?” In: (2020). url: http : / / www . rail - fastener . com / railway - turnout - introduction.html (visited on 05/26/2020). [Han+17] Norman Hansen, Norbert Wiechowski, Alexander Kugler, Stefan Kowalewski, Thomas Rambow, and Rainer Busch. “Model-in-the- Loop and Software-in-the-Loop Testing of Closed-Loop Automo- tive Software with Arttest”. In: INFORMATIK 2017 (2017). [Hat+14] John Hatcliff, Alan Wassyng, Tim Kelly, Cyrille Comar, and Paul Jones. “Certifiably safe software-dependent systems: challenges and directions”. In: Proceedings of the on Future of Software En- gineering. 2014, pp. 182–200. [Hei16] Frans Heijnen. EULYNX: A route to standardisation. 2016. url: https : / / www . globalrailwayreview . com / article / 74147 / eulynx-initiative-standardisation/. [Hel+17] Petra Helmi¨oet al. “Open source in Industrial Internet of Things: a systematic literature review”. In: (2017). [Hil03] Jane Hillston. “Model validation and verification”. In: Edinburgh: University of Edinburgh (2003). [Hob17] Chris Hobbs. Embedded software development for safety-critical systems. Jan. 2017, pp. 1–343. doi: 10.1201/b18965. [INC20] T INCOSE. “Systems engineering vision 2020”. In: Technical Operations, International Council on Systems Engineering (IN- COSE) Version 2.03 edn (2020). (Visited on 06/04/2020). [Ini17] E. Initiative. “System engineering process v1.0 (0.A)”. In: (2017), pp. 71–72.

94 Bibliography

[Ini18] E. Initiative. “Verification and validation plan 1.0 (0.A), Eu.Doc.31”. In: (2018), pp. 3–4. [Jia+12] Xiaolin Jia, Quanyuan Feng, Taihua Fan, and Quanshui Lei. “RFID technology and its applications in Internet of Things (IoT)”. In: 2012 2nd international conference on consumer elec- tronics, communications and networks (CECNet). IEEE. 2012, pp. 1282–1285. [JKK17] Ohyun Jo, Yong-Kyu Kim, and Juyeop Kim. “Internet of things for smart railway: feasibility and applications”. In: IEEE Internet of things journal 5.2 (2017), pp. 482–490. [Kap+19] George-Dimitrios Kapos, Anargyros Tsadimas, Christos Kotro- nis, Vassilis Dalakas, Mara Nikolaidou, and Dimosthenis Anag- nostopoulos. “A Declarative Approach for Transforming SysML Models to Executable Simulation Models”. In: IEEE Transactions on Systems, Man, and Cybernetics: Systems (2019). [Kar+13] Oleg Karfich, Florian Bartols, Till Steinbach, Franz Korf, and Thomas C Schmidt. “A hardware/software platform for real-time ethernet cluster simulation in OMNeT++”. In: SimuTools. 2013, pp. 334–337. [KB19] Utsav Khan and Andrea Bianchi. Steering system development using test rig and driving simulators. 2019. [Kep20] Kepware. “KEPServerEX”. In: (2020). url: https : / / www . kepware . com / en - us / products / kepserverex/ (visited on 03/18/2020). [Kin16] Karl M King. “Systems engineering framework for railway control & safety systems”. In: 2016 IEEE International Conference on Intelligent Rail Transportation (ICIRT). IEEE. 2016, pp. 236– 243. [Kni02] John C Knight. “Safety critical systems: challenges and direc- tions”. In: Proceedings of the 24th international conference on software engineering. 2002, pp. 547–550. [Lam+04] Klaus Lamberg, Michael Beine, Mario Eschmann, Rainer Otter- bach, Mirko Conrad, and Ines Fey. “Model-based testing of em- bedded automotive software using MTest”. In: SAE transactions (2004), pp. 132–140. [LCW19] Xuefei Li, Ming Chai, and Haifeng Wang. “Modeling and Veri- fication of Route Protection for Train-centric Train Control Sys- tem”. In: 2019 IEEE Intelligent Transportation Systems Confer- ence (ITSC). IEEE. 2019, pp. 2189–2194. [LD17] Phillip A Laplante and Joanna F DeFranco. “Software engineering of safety-critical systems: Themes from practitioners”. In: IEEE Transactions on Reliability 66.3 (2017), pp. 825–836.

95 Bibliography

[LHW11] Jianfeng Li, Zuqing Huang, and Xiangbing Wang. “Notice of Retraction Countermeasure research about developing Internet of Things economy: A case of Hangzhou city”. In: 2011 Inter- national Conference on E-Business and E-Government (ICEE). IEEE. 2011, pp. 1–5. [LL15] In Lee and Kyoochun Lee. “The Internet of Things (IoT): Appli- cations, investments, and challenges for enterprises”. In: Business Horizons 58.4 (2015), pp. 431–440. [Ly-+18] Nhan Ly-Trong, Chuong Dang-Le-Bao, Dang Huynh-Van, and Quan Le-Trung. “UiTiOt v3: A Hybrid Testbed for Evaluation of Large-Scale IoT Networks”. In: Proceedings of the Ninth Interna- tional Symposium on Information and Communication Technol- ogy. SoICT 2018. Danang City, Viet Nam: Association for Com- puting Machinery, 2018, pp. 155–162. isbn: 9781450365390. doi: 10.1145/3287921.3287935. url: https://doi.org/10.1145/ 3287921.3287935. [Mac18] Gon¸caloCarteado Pinho Machado. “Application development on the IoT Thingworx platform”. PhD thesis. Universidade de Coim- bra, 2018. [Mat] Mathworks. What is MIL, SIL, PIL, HIL and how do they in- tegrate in Model Based Design approach? url: https : / / de . mathworks.com/matlabcentral/answers/440277- what- is- mil-sil-pil-hil-and-how-do-they-integrate-in-model- based-design-approach (visited on 05/12/2020). [Mat+14] Reza Matinnejad, Shiva Nejati, Lionel Briand, and Thomas Br- cukmann. “MiL testing of highly configurable continuous con- trollers: scalable search using surrogate models”. In: Proceedings of the 29th ACM/IEEE international conference on Automated software engineering. 2014, pp. 163–174. [MB07] Robert McNeal and Mohamed Belkhayat. “Standard tools for hardware-in-the-loop (HIL) modeling and simulation”. In: 2007 IEEE Electric Ship Technologies Symposium. IEEE. 2007, pp. 130–137. [MEW20] Atif Mashkoor, Alexander Egyed, and Robert Wille. “Model- driven Engineering of Safety and Security Systems: A Systematic Mapping Study”. In: arXiv preprint arXiv:2004.08471 (2020). [MM19] Frits Monique and Maarten. “ProRail and its industrial partners have built the first EULYNX demonstrator”. In: SIGNALLING + DATACOMMUNICATION (111) 7+8/ (2019). (Visited on 04/05/2020).

96 Bibliography

[Mod20] PTC Integrity Modeler. “Integrated suite of modeling tools for systems and software engineering - Third-Party Products Ser- vices - MATLAB Simulink”. In: (2020). url: https : / / de . mathworks . com / products / connections / product _ detail / ptc-integrity-modeler.html (visited on 03/12/2020). [MS18] Azad M Madni and Michael Sievers. “Model-based systems engi- neering: Motivation, current status, and research opportunities”. In: Systems Engineering 21.3 (2018), pp. 172–190. [NHC12] Jonathan Nibert, Marc E Herniter, and Zachariah Chambers. “Model-based system design for MIL, SIL, and HIL”. In: World Electric Vehicle Journal 5.4 (2012), pp. 1121–1130. [Onl] Online. ] Industrial Internet Consortium, What Is the Industrial Internet? url: https://www.iiconsortium.org/ (visited on 05/18/2020). [Par20] EULYNX Partners. “20181212 Verification and validation plan Eu.Doc.31 v1.0(0.A)”. In: (2020). [Per16] Matthew J Perry. Evaluating and Choosing an IoT platform. O’Reilly Media, 2016. [PTC20a] PTC. “Kepware Manual”. In: (2020). url: https : / / www . kepware . com / getattachment / 5759d980 - 7641 - 42e8 - b4fb - 7293c835a2f9 / kepserverex - manual . pdf (visited on 06/26/2020). [PTC20b] PTC. “PTC Help Center”. In: (2020). url: https://support. ptc . com / help / modeler / r9 . 0 / en / index . html # page / Integrity_Modeler/ads/Introduction_to_Artisan_DOORS_ Synchronizer.html#wwID0EGL3JC (visited on 03/12/2020). [PTC20c] PTC. “PTC Help Center”. In: (2020). url: https://support. ptc . com / help / modeler / r9 . 0 / en / index . html (visited on 03/12/2020). [PTC20d] PTC. “PTC Help Center”. In: (2020). url: https://support. ptc . com / help / modeler / r9 . 0 / en / index . html (visited on 03/18/2020). [PTC20e] PTC. PTC ThingWorx Platform Product Brief. 2020. url: https://www.ptc.com/en/resources/iiot/product-brief/ thingworx-platform (visited on 10/04/2020). [PTC20f] PTC. “ThingWorx is an IIoT Platform Purpose-Built for Driv- ing Industrial Innovation”. In: (2020). url: https://www.ptc. com / en / products / iiot / thingworx - platform (visited on 03/18/2020). [PTC20g] PTC. “Windchill Modeler (formerly Integrity Modeler) Software To Simplify Your Design Process”. In: (2020). url: https:// de.mathworks.com/products/connections/product_detail/ ptc-integrity-modeler.html (visited on 03/12/2020).

97 Bibliography

[PTC20h] PTC. “Windchill Modeler (formerly Integrity Modeler) SySim”. In: (2020). url: https://www.ptc.com/en/products/plm/plm- products/windchill/modeler/sysim (visited on 03/18/2020). [Qin+13] Erwa Qin, Yoanna Long, Chenghong Zhang, and Lihua Huang. “Cloud computing and the internet of things: Technology inno- vation in automobile service”. In: International Conference on Human Interface and the Management of Information. Springer. 2013, pp. 173–180. [RK18] L Rakesh and Lokanna Kadakolmath. “Modeling and formal ver- ification of SMT rail interlocking system using PyNuSMV”. In: 2018 4th International Conference on Recent Advances in Infor- mation Technology (RAIT). IEEE. 2018, pp. 1–8. [Ros20] Ben Rossi. “How the Internet of Things is impacting enterprise networks”. In: (2020). url: https://www.information- age. com / internet - things - impacting - enterprise - networks - 123463122/ (visited on 05/29/2020). [Rs11] communications signalling Railway applications and processing systems. “European Committee for Electrotechnical Standardiza- tion, CENELEC, EN 50128:2011”. In: (2011). [San+12] Iv´anSantiago, Alvaro Jim´enez,Juan Manuel Vara, Valeria De Castro, Ver´onicaA Bollati, and Esperanza Marcos. “Model-driven engineering as a new landscape for traceability management: A systematic literature review”. In: Information and Software Tech- nology 54.12 (2012), pp. 1340–1356. [Sch+13] Nikolai Schetinin, Natalia Moriz, Barath Kumar, Alexander Maier, Sebastian Faltinski, and Oliver Niggemann. “Why do ver- ification approaches in automation rarely use HIL-test?” In: 2013 IEEE International Conference on Industrial Technology (ICIT). IEEE. 2013, pp. 1428–1433. [SHC17] Daniel Schwencke, Hardi Hungar, and Mirko Caspar. “Be- tween Academics and Practice: Model-based Development of Generic Safety-Critical Systems”. In: Tagungsband des Dagstuhl- Workshops Modellbasierte Entwicklung eingebetteter Systeme XIII. fortiss GmbH. 2017, pp. 1–18. [Sis+18] Emiliano Sisinni, Abusayeed Saifullah, Song Han, Ulf Jennehag, and Mikael Gidlund. “Industrial internet of things: Challenges, opportunities, and directions”. In: IEEE Transactions on Indus- trial Informatics 14.11 (2018), pp. 4724–4734. [SL15] Muhammad Shafique and Yvan Labiche. “A systematic review of state-based test tools”. In: International Journal on Software Tools for Technology Transfer 17.1 (2015), pp. 59–76.

98 Bibliography

[Son20] Daniel Sontag. “Industrial IoT vs. Industry 4.0 vs. . . . Industry 5.0?” In: (2020). url: https://medium.com/the-industry-4- 0-blog/industrial-iot-vs-industry-4-0-vs-industry-5- 0-a5f9541da036 (visited on 05/29/2020). [SS15] Sachchidanand Singh and Nirmala Singh. “Internet of Things (IoT): Security challenges, business opportunities & reference ar- chitecture for E-commerce”. In: 2015 International Conference on Green Computing and Internet of Things (ICGCIoT). IEEE. 2015, pp. 1577–1581. [sta] European committee for standardization. “CEN/TC 256 - Rail- way applications”. In: (). url: https : / / standards . cen . eu / dyn / www / f ? p = 204 : 7 : 0 :::: FSP _ ORG _ ID : 6237 & cs = 15513F2E0FECDDEE42DD36DF28D558027 (visited on 05/05/2020). [Sta14] John A Stankovic. “Research directions for the internet of things”. In: IEEE Internet of Things Journal 1.1 (2014), pp. 3–9. [Ste18] Perdita Stevens. “Is bidirectionality important?” In: European Conference on Modelling Foundations and Applications. Springer. 2018, pp. 1–11. [SUN15] Pengfei SUN. “Model based system engineering for safety of rail- way critical systems”. Theses. Ecole Centrale de Lille, July 2015. url: https://tel.archives-ouvertes.fr/tel-01293395. [Sup20] Support. “PTC Help Center”. In: (2020). url: https : / / support . ptc . com / help / thingworx _ hc / thingworx _ 8 _ hc / en/index.html (visited on 05/18/2020). [Tul+17] Punit Tulpule, Ayyoub Rezaeian, Aditya Karumanchi, and Shawn Midlam-Mohler. “Model based design (MBD) and hardware in the loop (HIL) validation: curriculum development”. In: 2017 Amer- ican Control Conference (ACC). IEEE. 2017, pp. 5361–5366. [Tut20] SysML Tutorial. “Technology and Management Training Courses and Seminars”. In: (2020). url: https : / / www . tonex . com / sysml-tutorial/ (visited on 05/28/2020). [VDA13] A Vidanapathirana, SD Dewasurendra, and SG Abeyaratne. “Model in the loop testing of complex reactive systems”. In: 2013 IEEE 8th International Conference on Industrial and Information Systems. IEEE. 2013, pp. 30–35. [VDC17] AS Vijay, Suryanarayana Doolla, and Mukul C Chandorkar. “Real-time testing approaches for microgrids”. In: IEEE Journal of Emerging and Selected Topics in Power Electronics 5.3 (2017), pp. 1356–1376. [WP19] Gan Wang and Saulius Pavalkis. “A Model-Based V&V Test Strategy Based on Emerging System Modeling Techniques”. In: INCOSE International Symposium. Vol. 29. 1. Wiley Online Li- brary. 2019, pp. 771–787.

99 Bibliography

[Wu+10] Miao Wu, Ting-Jie Lu, Fei-Yang Ling, Jing Sun, and Hui-Ying Du. “Research on the architecture of Internet of Things”. In: 2010 3rd International Conference on Advanced Computer Theory and Engineering (ICACTE). Vol. 5. IEEE. 2010, pp. V5–484. [XLG18] WANG Xin, Jin-yu LI, and Zhi-da GUO. “A Design Based on Internet of Things for Safety Monitoring System in High-speed Railway Maintenance”. In: DEStech Transactions on Engineering and Technology Research ecar (2018). [Yu16] Yun Yu. Quantitative Comparison of SensibleThings and Things Worx. 2016. [Zas20] Mykola Zasiadko. ‘EULYNX replaces mosaic of national sig- nalling interfaces’. 2020. url: https : / / www . railtech . com / policy/2019/09/10/eulynx-replaces-mosaic-of-national- signalling-interfaces/?gdpr=accept&gdpr=accept. [ZZ11] Qilou Zhou and Jie Zhang. “Research prospect of Internet of Things geography”. In: 2011 19th International Conference on Geoinformatics. IEEE. 2011, pp. 1–5.

100 A. Visual Studio Code

Figure A.1.: An excerpt of the auto-generated VB code

101

B. Modeler Blocks

103 Appendix B: Modeler Blocks

Figure B.1.: Simulation block ready for visualization

104 Appendix B: Modeler Blocks

Figure B.2.: BDD of System design with TWx blocks

105

C. SySim Simulation

C.1. Scenario - No End Position

Figure C.1.: Simulator displaying the status ”NoEndposition”

107 Appendix C: SySim Simulation

Figure C.2.: Transition to the state ”NoEndposition”

108