EXAMENSARBETE INOM ELEKTROTEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM, SVERIGE 2021
Development of a pipeline to allow continuous development of
software onto hardware
Utveckling av en pipeline för att ge upphov till kontinuerligt
utvecklande av mjukvara på hårdvara
Implementation on a Raspberry Pi to simulate a physicalpedal using the Hardware In the Loop method
Implementation på en Raspberry Pi för att simulera en fysisk pedal genom användandet av Hardware In the Loop-metoden
JEFFREY PERSSON JONATAN RYD
KTH SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA
Development of a pipeline to allow continuous development of software onto hardware
Implementation on a Raspberry Pi to simulate a physical pedal using the Hardware In the Loop method
Utveckling av en pipeline för att ge upphov till kontinuerligt
utvecklande av mjukvara på hårdvara
Implementation på en Raspberry Pi för att simulera en fysisk pedal genom användandet av Hardware In the Loop-metoden
Jonatan Ryd Jeffrey Persson
Examensarbete inom Elektroteknik Grundnivå, 15 hp
Handledare på KTH: Jonas Willén Examinator: Elias Said
TRITA-CBH-GRU-2021:054
KTH Skolan f ör kemi, bioteknologi och hälsa 141 52 Huddinge, Sverige
Abstract
Saab want to examine Hardware In the Loop method as a concept, and how an infrastructure of Hardware In the Loop would look like. Hardware In the Loop is based upon continuously testing hardware, which is simulated. The software Saab wants to use for the Hardware In the Loop method is Jenkins, which is a Continuous Integration, and Continuous Delivery tool. To simulate the hardware, they want to examine the use of an Application Programming Interface between a Raspberry Pi, and the programming language Robot Framework. The reason Saab wants this examined, is because they believe that this method can improve the rate of testing, the quality of the tests, and thereby the quality of their products.
The theory behind Hardware In the Loop, Continuous Integration, and Con- tinuous Delivery will be explained in this thesis. The Hardware In the Loop method was implemented upon the Continuous Integration and Continuous Delivery tool Jenkins. An Application Programming Interface between the General Purpose Input/Output pins on a Raspberry Pi and Robot Framework, was developed. With these implementations done, the Hardware In the Loop method was successfully integrated, where a Raspberry Pi was used to simu- late the hardware.
Keywords
Continuous integration, continuous delivery, hardware in the loop, Robot Framework, application programming interface, simulation, Raspberry Pi, general purpose input/output
Sammanfattning
Saab vill undersöka metoden Hardware In the Loop som ett koncept, dessu- tom hur en infrastruktur av Hardware In the Loop skulle se ut. Hardware In the Loop baseras på att kontinuerligt testa hårdvara som är simulerad. Mjuk- varan Saab vill använda sig av för Hardware In the Loop metoden är Jenkins, vilket är ett Continuous Integration och Continuous Delivery verktyg. För att simulera hårdvaran vill Saab undersöka användningen av ett Application Pro- gramming Interface mellan en Raspberry Pi och programmeringsspråket Ro- bot Framework. Anledning till att Saab vill undersöka allt det här, är för att de tror att det kan förbättra frekvensen av testning och kvaliteten av testning, vilket skulle leda till en förbättring av deras produkter.
Teorin bakom Hardware In the Loop, Continuous Integration och Continuous Delivery kommer att förklaras i den här rapporten. Hardware In the Loop me- toden blev implementerad med Continuous Integration och Continuous Deli- very verktyget Jenkins. Ett Application Programming Interface mellan Gene- ral Purpose Input/output pinnarna på en Raspberry Pi och Robot Framework blev utvecklat. Med de här implementationerna utförda, så blev Hardware In the Loop metoden slutligen integrerat, där Raspberry Pis användes för att si- mulera hårdvaran.
Nyckelord
Kontinuerlig integration, kontinuerlig leverans, hårdvara i en loop, Robot Framework, applikationsprogrammeringsgränssnitt, simulering, Raspberry Pi, general purpose input/output
Acknowledgements
We would like to thank Saab for giving us this opportunity to complete our bachelor thesis on their behalf. Special thanks to Oscar Kleyer for setting us up with Saab, and his help throughout the thesis. A huge thanks to Clémence Lhéritier, our supervisor at Saab, for her support and guidance throughout.
We would also like to thank our supervisor at KTH, Jonas Willén, for giving us advice and feedback. Thanks to Anders Utter for lending us his Raspberry Pi, which helped us immensely to get familiarized with the hardware used in this thesis.
Abbreviations
HIL – Hardware In the Loop RF – Robot Framework CI – Continuous Integration
CD – Continuous Delivery/Deployment API – Application Programming Interface CMS – Combat Management System GPIO – General Purpose Input/Output TDD – Test Driven Development
Table of Content
1 Introduction ... 1
1.1 Problem Definition ... 1
1.2 Goals ... 2
1.3 Previous Work ... 2
1.4 Delimitations ... 2
2 Theory and Background ... 3
2.1 Automatic Testing Methods and Programming Interfaces ... 3
2.2 Technical Tools for the System ... 6
3 Methods and Results ... 11
3.1 Research Method ... 11
3.2 Expected Results ... 12
3.3 Creating a Jenkins Pipeline ... 12
3.4 Jenkinsfile ... 13
3.5 Created Simulators ... 13
3.6 Setup of Raspberry Pis ... 16
3.7 Results ... 17
4 Analysis and Discussion ... 21
4.1 Methods ... 21
4.2 System ... 22
4.3 Possible Improvements ... 23
5 Conclusions ... 25
References ... 27
Appendixes ... 31
Appendix A: Configuring Jenkins Pipeline with a Webhook ... 31
Appendix B: HTML Log ... 34
Appendix C: Jenkinsfile ... 36
Appendix D: Pedal Simulator ... 37
Appendix E: Control Panel Simulator ... 42
1 | INTRODUCTION
1 Introduction
“Saab AB is a company that serves the global market with world-leading prod- ucts, services and solutions for military defence in all domains to civil security.
Saab’s market offering is broad and consists of complex systems involving ex- tensive research and development. As well as services with a high degree of repetition.” – Saab [1].
This chapter will first cover the problem definition for this thesis, which in- cludes why this subject is being analyzed and why the employer wants it ana- lyzed. Secondly, the goals of this thesis will be introduced and explained.
Lastly, the delimitation of this thesis will be set.
1.1 Problem Definition
Saab is currently working on a system to test and analyze a control panel. To- day, the control panel is tested manually with a pedal connected to it. This testing phase is a great example which can be improved with the Hardware In the Loop (HIL) method, and that is why Saab wants to consider implementing this method in their work. By replacing the control panel and the pedal with Raspberry Pis, the system can be simulated without the need of using the hardware used in the real system. Oskar Kleyer, Saab employee, had this to say when asked why Saab wanted HIL-testing examined.
“We are interested in examining HIL-testing as a concept, and how a HIL in- frastructure could look like. We are also interested in examining how an inter- face between RF and Raspberry Pi could look like. We believe that HIL can increase the test frequency and improve the quality of the tests and thereby improve the quality of our products.” – Oskar Kleyer, Saab employee.1
To be able to continuously develop and update software on the simulated hardware, another method called Continuous Integration Continuous Deliv- ery and/or Deployment (CI/CD) needs to be researched and applied. By inte- grating HIL and CI/CD, developers can remotely deliver code to the hardware being tested in the HIL method.
1 Personal communication (e-mail) 2021-03-26
2 | INTRODUCTION
1.2 Goals
The goal of this thesis is to successfully develop and implement an Application Programming Interface (API) between Robot Framework (RF) and a Rasp- berry Pi. This interface will be used for an implementation in a CI/CD pipeline, which will also have an integrated HIL. This is because Saab wants to examine the use of HIL, and how this can help them quicken their release of products and their overall quality of products. To reach this goal, this thesis will exam- ine the theory behind CI/CD and HIL, and how they have been implemented in previous works.
1.3 Previous Work
During the literature study done during this thesis, multiple papers was found concerning the CI/CD and HIL method, which is presented in chapters 2.1.1 and 2.1.2. However, no study implicitly combining the specific hardware and software used in this thesis was found.
1.4 Delimitations
The test system will consist of two Raspberry Pis, where one will act as a pedal simulator and the other as a control panel simulator. The pedal simulator will use a Robot Framework program to act as a pedal. There will be an implemen- tation of an interface between RF and the Raspberry Pi, that interface will only be handling the General Purpose Input/Output (GPIO) pins. The control panel is one of Saabs own creations, but due to confidential information it was replaced with a Raspberry Pi. The Pi which simulates the control panel, is a minimal version of the control panel, and only configured to react to the pedal.
There will be an implementation of a Continuous Integration and Continuous Delivery/Deployment pipeline. However, due to no real product available for deployment, the Continuous Deployment step will not be integrated.
3 | THEORY AND BACKGROUND
2 Theory and Background
This chapter will first explain different methods for automatic testing and the concept of an application programming interface. The automatic testing methods which will be explained are the continuous integration & continuous delivery approach and the hardware in the loop method. Lastly, the technical tools including software and hardware will be introduced and explained. The software includes the different programming languages used, and other ser- vices like Ngrok and GitHub. The hardware is simply a Raspberry Pi, which will be used as the simulation hardware.
2.1 Automatic Testing Methods and Programming Interfaces
First, continuous integration & continuous delivery will be explained, which includes why it is needed and how it works. Secondly, the hardware in the loop method will be explained. The explanation includes why Saab is interested in it, how it works and how hardware testing was done in the past. Lastly, the application programming interface will be explained. The application pro- gramming interface will be compared to libraries and how they are connected.
Continuous Integration and Continuous Delivery
Modern businesses are in constant need of improving and adapting teams to be able to release a constant flow of software updates into physical hardware.
This will lead to quicker release cycles, lower cost, and reduce the risk associ- ated with deploying software updates to live hardware. To achieve that goal, implementing a CI/CD tool will be useful. CI, meaning Continuous integra- tion, is a practice that developers use when making small changes and checks to their code [2], [3], [4], [5]. According to Thoughtworks, who coined the term, CI helps with detecting errors quickly and locating them more easily.
For instance, they say: “Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early” - Thoughtworks [6]. CD stands for two steps:
both Continuous Delivery and Continuous Deployment. Continuous Delivery is the automated and consistent way of code to be delivered to testing environ- ments. The step after Continuous Delivery is Continuous Deployment. If a set of code passes the automated tests in the Continuous Delivery stage, it will automatically be deployed and placed in production, resulting in continuous updates of the product that is to be developed. However, if a set of code does
4 | THEORY AND BACKGROUND
not pass the stage of automated tests, the developer will be notified, and the code will not be deployed to the system [2], [3], [4], [5]. Thoughtworks be- lieves this can help large organizations become more lean, agile, and innova- tive as startups. They say: “Through reliable, low-risk releases, Continuous Delivery makes it possible to continuously adapt software in line with user feedback, shifts in the market and changes to business strategy. Test, support, development and operations work together as one delivery team to automate and streamline the build-test-release process.” – Thoughtworks [7]. Figure 1 demonstrates the CI/CD steps graphically.
Figure 1. Overview of the CI/CD pipeline steps [8].
Hardware In the Loop
Ever since the invention of the transistor, the growth and usage of electronic devices has been growing in an extraordinary fashion. Digital electronics are still today becoming more and more commonly used amongst developers be- cause of its flexibility and reliability. However, as the technology is becoming more complex, the harder the process of testing and verifying a system be- comes. The testing phase of electronics in general is costly and time consum- ing, and this is a problem in modern industry where the competition between global companies creates a need for shorter product delivery and deployment cycles [9].
As innovation is critical for Saab’s future, thorough and reliable tests are a ne- cessity when verifying and validating design. As modern systems complexity grows, this critical part in development of hardware becomes more of a chal- lenge. This advancement has given rise to Hardware In the Loop (HIL), the bridge that connects traditionally isolated simulation and physical prototyp- ing.
Before HIL, simulation and prototyping coexisted as separate iterative steps.
Simulation in industry before HIL consisted of a software environment gov- erned by a mathematical model with no real aspects. The simulation quality
5 | THEORY AND BACKGROUND
heavily depended on the accuracy of the model, and even then, a highly com- plex control system could not be fully validated until it had been tested against a 100 percent accurate model. Similarly, traditional prototyping could pro- duce a realistic model, which led to a more accurate outcome. However, this resulted in longer development time, higher engineering costs and if the pro- totype were damaged, it would not have been possible to reuse. During proto- type testing, there must be a new prototype developed as the product goes fur- ther in development [10], [11].
These prototypes consist of materials and parts that are often imported from other countries. In Sweden there was a total of 9663,6 kilo tonnes CO2 equiv- alents emitted through import and export in 2019, compared to 9460,9 kilo tonnes in 2009 [12]. To get a better understanding of how much this is, the total emission of CO2 equivalents in 2019 was 25094,1- and 31548 kilo tonnes in 2009 [13]. This means that in 2019 import and export stood for approxi- mately 38,5% of all greenhouse gas emissions, and almost 30% in 2009. The high cost to execute tests on complex machinery can also be reduced. For ex- ample, National Instruments presents one example where HIL reduced field test time by half, saving 150 000$ in costs associated with testing an aircraft arrestor control system [14]. HIL efficiently combines these two approaches and addresses the issue. This results in scalability, ecological and economical cost efficiency benefits that simulation provides, while maintaining physical realism at a high level as prototyping does.
The basic idea of HIL simulation is to include a part of real hardware in a sim- ulation loop during system development. Rather than only testing a control system solely based on a mathematical model of the system, HIL allows the use of real hardware in the simulation loop [10], [11]. HIL has been seen as a successful testing method in numerous works. In one of the works, the HIL method was implemented to test the control of an inverter in an AC electrical grid. The HIL method proved successful when implemented, it helped the writer to real-time test the system without any danger of destroying the hard- ware [15]. Another work implemented the HIL method, to run tests of enhanc- ing a controller’s tuning ability. The HIL method helped the writers to gain better understanding of the problems as the process moved forward [16].
Application Programming Interface and Libraries
Application Programming Interface (API) is used to open an application’s data and functionalities, to external or internal developers. This allows different
6 | THEORY AND BACKGROUND
services and products to communicate with each other and take use of that service/products data and functionalities through an interface [17]. An API can be related to software libraries, where the API describes the behavior of a system, and the library implements that behavior [18]. Libraries consist of a collection of functions, pre-compiled routines, or reusable code. By integrat- ing a library, the library’s functions can be implemented in the application without defining the behavior of the function in the application. The main dif- ference between a library and an API, is that a library refers to the code itself, meanwhile an API refers to an interface. A library itself cannot be considered an API, although an API can be a part of a library [19].
2.2 Technical Tools for the System
This part of the chapter handles the different technical tools used. First, the software, programming languages and other software services will be intro- duced. The reason why they are used, and what they offer will be explained.
Lastly, the hardware, Raspberry Pi, will be introduced. The introduction of the Raspberry Pi will be quite concise, as it offers numerous configurations, how- ever, most of them are not relevant to this thesis.
7 | THEORY AND BACKGROUND
Described System
Saab describes how the system is supposed to look like with a block diagram shown in figure 2 below.
Figure 2. Block diagram of the system
The control panel is the hardware that is directly connected to the pedal, along with other buttons, screens, mouses and keyboards. The control panel is used by an operator who needs to be able to communicate with other operators. The operator also need s to be able to make decisions on h ow to proceed in d ifferent situations based on the information given by the control panel through differ- ent sensors. The pedal in this system is a pedal that is part of a firing sequence.
The control panel will read signals sent from the pedal and forward them to the Combat Management System (CMS). Saab describes the CMS as the brain behind everything onboard. There are two readable signals between the pedal and the control panel. Depending on if the pedals signals are high or low, four different states are defined. The four different states are:
• Disconnected
• Pedal up
• Pedal down
• Hardware failure
8 | THEORY AND BACKGROUND
Python
Python was developed under the Open-Source Initiative (OSI)-approved open- source license. Open source means that the program is free and open for anyone to use and distribute, the source code can be manipulated without any jurisdictionally consequences as well. Python's license is under the admin- istration of Python Software Foundation [20]. Python was first released in 1991 and was developed by a single developer by the name of Guido Van Ros- sum. The language Python is based on a lot of predecessors, but mostly on the ABC language. Python is considered one of the easiest languages to learn, thanks to its code readability, meaning the code is written in such a way that it says what it does in clear English [21], [22], [23]. Python is used due to its compatibility with a Raspberry Pi.
Jenkins
Jenkins is an independent open-source software, which was first developed by Kohsuke Kawaguchi in 2011. Jenkins is an automated server which is used to automate tasks like building, testing, delivering, and deploying of software [24], [25]. The main feature of Jenkins is the Jenkins Pipeline or Pipeline for short. Pipeline is created with an assemblage of plugins, which supports the integration and implementation of continuous delivery pipelines into the Jen- kins software. A continuous delivery pipeline is an automated process of get- ting software from version control directly to the customers/users [26]. Jen- kins is the CI/CD tool used for this thesis, as requested by the employer.
Robot Framework
Robot Framework is an automation framework for acceptance testing, Ac- ceptance Test Driven Development (ATDD) and Robotic Process Automation (RPA). Acceptance testing is a technique of testing to determine if the software has met the required specifications [27]. ATDD is test driven development based on acceptance testing [28]. Test Driven Development (TDD) is a style of programming where a single aspect of the program is tested by itself, until that single aspect passes the test. The code which represents that single aspect is then refactored, to be implemented in the program [29]. RPA is a method to automate tasks that are highly repetitive, cumbersome, or big in volume [30].
The syntax of RF is simple plain text coding, and it can be easily implemented using Python or Java [31]. RF is used for this thesis, as requested by the em- ployer.
9 | THEORY AND BACKGROUND
Eclipse
Eclipse is the Integrated Development Environment (IDE) used for program- ming, due to its support of both Python and RF. The Eclipse project was first launched by International Business Machines (IBM) in 2001. Eclipse became very popular and very community integrated, which later induced the creation of The Eclipse Foundation in 2004. The foundation is an independent non- profit organization, it was made to act as a steward between Eclipse and its community [32].
GitHub
GitHub is a development platform, which is free to use for developers around the world. With over 56 million registered developers, it is considered the larg- est and most advanced development platform [33]. Developers can upload their projects on a repository, where other developers are able to take part of their code, if the creator allows it. GitHub allows multiple developers to work on the same project [34]. GitHub is the used development platform for this thesis, as the writers have experience with this service since earlier.
Ngrok
Ngrok is a cross-platform application that exposes a local development server to the Internet. The software makes a locally hosted web server appear to be hosted on a subdomain of ngrok.com. Therefore, no public IP or domain name on the local machine is needed. By creating a long-lived TCP tunnel from a random generated subdomain on ngrok.com, Ngrok bypasses NAT mapping and firewall restrictions. After specifying which port that the web server lis- tens to, the software initiates a connection to the Ngrok server. It is then pos- sible for other nodes to make requests to the local server through the unique Ngrok tunnel address [35]. Ngrok summarizes their software as follows:
“Ngrok exposes local servers behind NATs and firewalls to the public internet over secure tunnels” – Ngrok [36]. Ngrok is the tunneling service used for this thesis, as it is free of charge and user friendly.
Raspberry Pi
Raspberry Pi is a small desktop computer which historically started its devel- opment in 2006, it was then based on models of the British Broadcasting Cor- poration (BBC) micro. Through six years the Raspberry Pi was merely a pro- totype, the first official Raspberry Pi launched in 2012. The main goal of cre- ating this small computer was to give people, who wanted to learn more about
10 | THEORY AND BACKGROUND
computers, an affordable choice [37], [38]. The Raspberry Pi runs the operat- ing system Linux, and also provides a set of General Purpose Input/Output (GPIO) pins [39]. This allows controlling of electronic components for physi- cal computing. In figure 3 you can see the schematic of the 40 pins that are available on the Raspberry Pi 4 model B that is used throughout the thesis.
Raspberry Pi is the hardware used for this thesis, as requested by the em- ployer.
Figure 3. Raspberry Pi pins [40].
11 | METHODS AND RESULTS
3 Methods and Results
This chapter will first explain the methods and techniques used to simulate a functional HIL system to achieve the goal of analyzing signals from a simu- lated pedal using a CI/CD approach. At the end of this chapter, the results will be summarized.
3.1 Research Method
To reach the goals of this thesis, there had to first be a detailed understanding of the CI/CD and HIL methods, as well as the technical tools used. This was achieved by performing a literature study, which can be seen in chapter 2. Sec- ondly, the creation of the simulators and the coding behind it was achieved by using Test Driven Development (TDD).
The choices of methods used in this thesis was mainly prescribed by Saab.
Those methods were the use of Jenkins as a CI/CD tool, the use of Raspberry Pis as simulators, and the use of RF as the programming language for one of the simulators. RF should have an implementation of an API, to allow config- uration on a Raspberry Pi.
To have the code available to the Jenkins server, and to allow multiple users to work on the same application, there had to be an implementation of a de- veloper platform. There are numerous developer platforms available, and most of them are free. However, due to Jenkins having multiple default con- figurations related to GitHub, and multiple plugins related to GitHub, the choice was quite clear. GitHub is also a service that we, the writes, are familiar with since earlier, which strengthened the choice of the service. The IDE used in thesis, Eclipse, have an integration of GitHub, where the code can be di- rectly pushed from the IDE upon GitHub.
To get the Jenkins server, which is running on a local port, to be accessible by other computers through a web browser, there had to be an implementation of a local to public network tunnel. This could have been done manually. How- ever, due to it not being a topic of interest to this thesis, an available tunneling service was used. The choice of tunneling service, was based upon the research done when examining webhook integration in Jenkins, with GitHub. During the research, one tunneling service was mentioned a lot, and that was Ngrok.
There are multiple free tunneling services similar to Ngrok. However, due to it being mentioned and described during the research, the choice of Ngrok was made.
12 | METHODS AND RESULTS
During the creation of the simulators, there had to be a choice made on which programming language the control panel simulator should be written in, and which language the API to RF should be written in. There are multiple choices, which include Python, Java, and C. The research made upon configuring the Raspberry Pi’s GPIO pins, in the respective languages, showed that both Java and C was unnecessarily complicated for the task in question. Python, how- ever, have predefined libraries that can be used to configure the GPIO pins on a Raspberry Pi with ease. Two of those libraries are RPi_GPIO and gpiozero.
Those libraries are both easily configured, with clear predefined functions that are made for the purpose to configure GPIO pins. Another aspect to consider, is what language works the best for creating an API to RF. As discovered dur- ing the research on RF, RF works well with both Java and Python. However, due to Python being more user friendly when configuring GPIO pins, Python was the choice for this thesis.
3.2 Expected Results
The expected results of this thesis were the following: Implementation of the HIL method on a CI/CD pipeline. Updated code should be delivered to the pipeline automatically. If a test fails, the code should be reverted to the previ- ous working code. The testing should be able to be done remotely. An API be- tween RF and a Raspberry Pi, where the GPIO pins on the Raspberry is avail- able for configurations. Implementation of serial communication with GPIO pins in the API.
3.3 Creating a Jenkins Pipeline
To successfully create a system using a CI/CD approach where software be- havior continuously can be changed and tested through different nodes, a Jen- kins pipeline was created on a Raspberry Pi acting as a master node. However, when creating a Jenkins pipeline, it runs on a localhost port thus making it only accessible locally on that PC. To make the Jenkins pipeline accessible from other nodes, the local host port of the master node needs to be connected to a public URL. The way to integrate GitHub to Jenkins, is to first connect the Jenkins pipeline with the GitHub repository in question. Secondly, the GitHub repository needs a way to communicate with the Jenkins pipeline on the mas- ter node. This was done by using Ngrok. As mentioned earlier, Ngrok is a way to expose local servers to a public URL, which in turn can be used by GitHub.
GitHub also has a configuration called webhook. Webhook is a way to send HTTP POST payloads to the assigned URL, which in turn tells the URL that a
13 | METHODS AND RESULTS
change has been made upon the repository. That is where a Jenkins build con- figuration called GitHub hook trigger for GITScm polling was enabled. This configuration enables the Jenkins project to trigger a build of the project when a HTTP POST payload is sent to the server. With all these configurations made, the Jenkins project is now connected to a repository. Jenkins is then able to fetch the repository files in question and build the project, whenever a commit is pushed upon the repository [41], [42]. For more details on how to configure this, see Appendix A.
3.4 Jenkinsfile
During the creation of the Jenkins pipeline, there had to be a Jenkinsfile im- plemented. A Jenkinsfile is a text file that contains the defining script of a Jen- kins Pipeline. The defining script is a script that tells the pipeline what steps to do, and in what order. The Jenkinsfile developed for the Jenkins pipeline used in this thesis consists of three stages that define what will be done. The first stage connects the Raspberry Pi that runs the Jenkins pipeline to a GitHub account, which contains the Robot Framework file in a repository. The Raspberry Pi will then download the latest version of the RF file and place it locally in the machine's Jenkins folder. The second stage uses a plug-in in Jen- kins and publishes a log of the test in HTML-format, when the test is finished.
To be able to open the HTML log, a function needs to be executed in the Jen- kins script console. The function that is executed, needs to be re-executed every time the server is restarted [43]. An example of this HTML log and the function in the script console is demonstrated in Appendix B. This makes the log of the test possible to open remotely from another node other than the master node running the Jenkins pipeline. The third stage navigates to said local folder and runs the RF test. The Jenkinsfile canbe seen in Appendix C.
3.5 Created Simulators
In this sub-chapter the created simulators for the pedal and the control panel will be introduced. The simulators explanations include the design, functions, integration of an API, and the Raspberry Pi configuration.
Pedal Simulator
The pedal simulator was designed to send the current pedal state, which is defined by two General Purpose Input/Output (GPIO) pins, to the control panel, and then read what the control panel sends back. The output from the control panel was also defined by two GPIO pins. The GPIO pins were config- ured on two different Raspberry Pis, where one is acting as the pedal, and the
14 | METHODS AND RESULTS
other as the control panel. The pedal simulator, which was written in Robot Framework, has no default way to communicate through GPIO pins. To solve this problem, there had to be an implementation of an API. This API includes two libraries written in Python. Those two libraries are RPi_GPIOZERO and StateCheck, both of those libraries were written as Python modules. The RPi_GPIOZERO library was written with the help of the gpiozero library in Python [44]. The purpose of the RPi_GPIOZERO library is to write functions which can configure the GPIO pins on a Raspberry Pi. The functions included in that library is the following:
• SetOutPin
Turn a specific GPIO pin to an output pin.
• SetInPin
Turn a specific GPIO pin to an input pin.
• TurnOnPin
Set the value of an output pin to 1.
• TurnOffPin
Set the value of an output pin to 0.
• ReadInPin
Read the value of an input pin.
• ShutdownOutPin
Closes the output pin as a safety measure.
• ShutdownInPin
Closes the input pin as a safety measure.
The reason these functions are specific to input/output pins, is solely because of the imported gpiozero library. The gpiozero library defines an output pin as a led, and an input pin as a button. The other library, StateCheck, has one purpose only, which is to read the value that the control panel sends, and re- turn the corresponding state. The name of that function is StateChecker.
With these two libraries configured, the pedal simulator was built. The simu- lator was built upon five GPIO pins, where three of them are configured as outputs, and two of them as inputs. One of the output pins acts as a start/stop pin, it is set to the value 1 to tell the control panel that transmission has begun.
After the transmission is finished, that pin is set to the value 0. This tells the control panel that the transmission is done, and it can stop listening. The two other output pins represent the state of the pedal. As mentioned earlier, there are four total states that the pedal can be set to, disconnected, pedal up, pedal down and Hardware (HW)-failure. The states correspond with the value of the
15 | METHODS AND RESULTS
output pins, 00 = disconnected, 01 = pedal up, 10 = pedal down and 11 = HW- failure. These states are set by giving a function the numerical value of the requested state. That function then led to a sub-function that changes the val- ues of the output pins to the requested state. The control panel gets the state of the pedal and responds. The response from the control panel is then re- ceived on the two input pins. These two input pins are then read. The value of the read pins is then evaluated, and a numerical value is returned. That nu- merical value represents the state that the control panel responds with. The returned state is then compared to the requested state. If the requested- and returned state is the same, the test continues, if not, the test is considered failed, and the simulation stops. The full set of code of the pedal simulator is available in Appendix D.
Control Panel Simulator
The control panel simulator was designed to retrieve the current state of the pedal and respond with the same state on another Raspberry Pi. The control panel simulator is written as a python program, with the help of the gpiozero library [44]. The setup of the control panel is similar to the pedal simulator, as it also has five GPIO pins configured. Three of those pins are configured as inputs, the other two as outputs. All these pins correspond with the five pins on the pedal simulator; however, they are inverted. One of the input pins acts as the start/stop pin, the simulator is in a constant loop reading the start/stop pin. The other two input pins receive the pedal state. The received state is then evaluated, and the two output pins are then set to represent the state it re- ceived. Those output pins are then read by the pedal simulator, which was ex- plained earlier in chapter 3.3.1. The code of the control panel simulator is available in Appendix E.
16 | METHODS AND RESULTS
3.6 Setup of Raspberry Pis
The system seen in figure 2, ended up looking like figure 4 in its final state wh ere two Raspb erry Pis are used to simula te this. One Ra spb erry Pi simu lates the two blocks called “Test computer” and “Simulator”. The other one simu- lates the block called “Control Panel”.
Figure 4. Block diagram of the simulated system
Figure 5. Schematic representation of the connected Raspberry Pis.
As seen above, figure 5 shows how the two Raspberry Pis were connected be- tween their GPIO pins. The green wire is connected to the GPIO18 pin on both Raspberry Pis. This pin is configured as output on the pedal simulator and input on the control panel simulator. This is the pin which starts and stops the transmission.
The blue wires are connected to the GPIO17 and GPIO22 pins on the Rasp- berry Pis. These are the pins that simulate which state the pedal is in. On the Raspberry Pi simulating the pedal, the wires are configured as output pins. On
17 | METHODS AND RESULTS
the Raspberry Pi simulating the control panel, the pins are configured as input pins.
Th e red wires a re connected to the GPIO2 3 and GPIO24 pins on the Ra spb erry Pis. These are the p ins that resp ond to the pedal simula tor with the read sta tes.
On the Raspberry Pi simulating the pedal, these pins are configured as input pins. On the Raspberry Pi simulating the control panel, these pins are config- ured as output pins.
The black cable connected between the two Raspberry Pis is connected to ground on the physical pin numbered 39. This is to sync the Raspberry Pis together, so that they are on the same voltage level. A picture of the final setup can be seen in figure 6 below.
3.7 Results
Figure 6. Raspberry Pis connected with GPIO pins.
The expected result of implementing a system containing a HIL method using a CI/CD approach was achieved. This was done by creating a Jenkins Pipeline with a GitHub webhook integration through Ngrok. Every time a developer pushes a change upon the connected GitHub repository, the pipeline is then able to build itself and run the Jenkinsfile script. This makes it possible for a developer to remotely write code that is automatically delivered to the pedal simulator.
18 | METHODS AND RESULTS
The Jenkinsfile was configured in such a way that it will connect the Raspberry Pi to the repositoriy’s owner, publish a HTML log of the Robot Framework log and run the pedal simulator. The pedal simulator was built with the help of an API, consisting of two libraries, RPi_GPIOZERO and StateCheck RPi_GPIOZERO enables the RF based pedal simulator to configure the GPIO pins on a Raspberry Pi. The pedal simulator was built upon five GPIO pins, three outputs and two inputs. The outputs consist of one start/stop pin and the other two as the pedal state. These inputs are the controlling received state, which is sent from the control panel. The control panel simulator was built similarly to the pedal simulator, with five GPIO pins, which are configured as three inputs and two outputs. They correspond with the GPIO pins in the pe- dal simulator, although inverted. When the test program is executed, the con- trol panel receives the current state from the pedal simulator and evaluates it.
The control panel then responds to the pedal simulator, with the state it just received. The simulated hardware was integrated in a Jenkins pipeline, to es- tablish the HIL method.
A HTML log of a successful test’s results can be seen in Appendix B. In this case, the two output pins on the pedal simulator which simulates the state of the pedal were set to 1. The control panel simulator then read the states of these pins and returned the resulting state. The state which represents ‘11’ is as mentioned earlier defined as HW-failure. As seen in the appendix, that is the state then read by the two input pins on the pedal simulator. Since the state received by the pedal simulator was the same as the state sent, the test was considered a success.
Another expected result of this thesis was to send the state of the pedal from the control panel to the CMS simulator using serial communication. However, the system developed in this thesis returns the state of the pedal from the con- trol panel, using two generic GPIO pins.
A feature which was not fulfilled was the desire to undo faulty code which is delivered to the pedal. As of now, when a set of code containing errors is de- livered to the pedal simulator, the test will run, and a log of the failed test will be published. The faulty code will then remain, until another set of code is pushed upon the GitHub repository.
19 | METHODS AND RESULTS
Table 1. Summary of achieved results.
Expected results Achieved
Implementation of HIL on a CI/CD pipeline Yes
Automatic delivery of updated code Yes
Revert to previous working code if test failed No
Remote testing Yes
API between RF and the GPIO pins on a Raspberry Pi Yes Implementation of serial communication in the API No
20 | METHODS AND RESULTS
21 | ANALYSIS AND DISCUSSION
4 Analysis and Discussion
This chapter consist of three parts. The first part will analyze and discuss the different methods used. The second part will discuss how our proposed system could be of benefit to Saab, both in a technical and non-technical aspect. The third and last part will discuss possible improvements of the proposed system.
4.1 Methods
To fulfill the expected results and complete the thesis, a literature study of the CI/CD and HIL methods was done by analyzing previous works. This gave us, the writers, a better understanding of how these methods could be combined, and how they could work together.
Saab wanted us to use Raspberry Pis to simulate the different parts of the sys- tem. This worked greatly in our favor, as the Jenkins pipeline could without trouble be set up on one of the Raspberry Pis, as it is a small computer. This, combined with the GPIO pins available on the Raspberry Pis, made the CI/CD and HIL methods easy to combine. The Jenkins pipeline applying the CI/CD method, and the usage of the GPIO pins made the HIL simulation complete.
GitHub was the development platform we chose to use, as Jenkins and GitHub already had multiple default configurations related to each other. In hindsight, we believe it is clearly the best development platform to use when working with Jenkins. The IDE we used, Eclipse, is also integrated with GitHub. This made our Test Driven Development (TTD) method used when developing code, in a trial-and-error fashion, work in a good way. We could have used another development platform. However, due to the integration of GitHub in Jenkins, this would have made the thesis more tedious than necessary.
The use of the tunneling service Ngrok, enabled the automatic execution of the Jenkins pipeline, when a change was made upon the connected repository on GitHub. It also made it possible for us, to view the Jenkins pipeline from dif- ferent computers. This could have been done with any Tunneling service, and it would probably result in no difference. Ngrok was chosen because it was the first tunneling service we were introduced to, and the research we did had ex- planations on how to use it.
The choice of programming language for the simulators was Python. As men- tioned earlier, there is two available libraries for configuring GPIO pins on a Raspberry Pi. Those two libraries are RPi_GPIO and gpiozero. RPi_GPIO was
22 | ANALYSIS AND DISCUSSION
the first choice of library when programming the control panel simulator, and it was supposed to be implemented in the pedal simulator as well. However, the RPi_GPIO library needed the support of a Linux operating system, which would not work as the pedal simulator was programmed on a Windows based computer. This could have been solved with the help of a Linux emulator.
However, due to the progress already made and the time aspect of this thesis, this was not implemented. This made the gpiozero library the choice for this thesis. The library gpiozero, is a good choice for a GPIO pin library, if the con- figuration is limited to turning a GPIO pin on/off and reading it. It was used for both the control panel and the pedal, for easier understanding.
4.2 System
As of today, when testing the physical pedal against the control panel, manual tests are performed on the real system. The pedal is manually connected to the control panel, and the four different states are tested by hand. The results are then forwarded to the combat management system. This is not optimal as only one person at a time can test the system, which makes the testing verification processes more complex than necessary. Over time the physical pedal is worn out and might need to be replaced. Because of this, Saab wanted to examine the use of a Hardware In the Loop method, and how that could improve the quality and release rate of their products.
By creating a Jenkins pipeline and implementing RF on a Raspberry Pi, which also simulates a physical pedal, a CI/CD approach with HIL was successfully implemented. Our proposed system also makes it possible for multiple devel- opers to continuously deliver code to the same hardware remotely. If this method were to be implemented on Saabs current test system, using a physical pedal as a prototype would not be necessary. Our supervisor at Saab, Clémence Lhéritier, had the following to say after examining our thesis and proposed system.
23 | ANALYSIS AND DISCUSSION
“This analysis gives us a great overview of the whole process and its possibili- ties. By replacing the Raspberry Pis by our own control systems, it is easy for us to consider the HIL option for projects in the future. We believe that Con- tinuous Integration, together with Hardware In the Loop can simplify the ver- ification processes, increase the frequency and the quality of the tests and thereby improve the quality of our products.” - Clémence Lhéritier, Saab su- pervisor.2
If our proposed system would be implemented, it would also lead to less im- pact on the environment, as shipping of hardware for the prototype would not be needed. As mentioned earlier, import and export stood for approximately 38,5% of total greenhouse gas emissions in Sweden 2019. HIL also allows the possibility to reduce the cost to execute tests. One study showed that a com- pany saved 150 000$, by using the HIL method.
4.3 Possible Improvements
A possible improvement to the proposed system could be the API between RF and the Raspberry Pi, which can only handle generic GPIO pins. Generic GPIO pins are either on or off, there is no implementation of other configurations like Pulse Width Modulation or serial communication through Serial Periph- eral Interface. The plan for the API was to be able to communicate through both generic GPIO and SPI GPIO pins. However, due to a delay of receiving the Raspberry Pis, and because the available libraries for processing SPI needed a Linux operating system, while we were using Windows, this was not implemented. This could be fixed with the help of a Linux emulator. Another improvement that could be implemented to the Jenkins pipeline, would be a way to reverse faulty code back to a working version. A possible way to achieve this would be to reverse the GitHub repository to the latest push that passes the Robot Fra mework test. To improve the u ser friendliness of the HIL system, a graphical user interface could also be implemented.
2 Personal communication (e-mail) - 2021-05-19
24 | ANALYSIS AND DISCUSSION
25 | CONCLUSIONS
5 Conclusions
This thesis successfully implemented the HIL method with a CI/CD approach through a Jenkins pipeline. The hardware in question is a pedal that was sim- ulated through a Raspberry Pi. Simulation of the pedal was done with a pro- gram written in Robot Framework. To use RF with the Raspberry Pi, an API between RF and the generic GPIO pins on a Raspberry Pi was created. The simulated pedal was tested against the simulated control panel on another Raspberry Pi. The result of the test is then available for examination in a RF log, published on the Jenkins pipeline. As Lhéritier said, HIL implemented with a CI/CD pipeline is believed to simplify Saab’s verification process, and improve the quality of their tests, and thereby the quality of their products.
She also said, by simulating Saab’s test system with Raspberry Pis, it would make it easy for Saab to consider the use of HIL in future projects.
For future improvements, a fully working API between RF and Raspberry PI should be developed. This would make it easier to simulate any sort of hard- ware, and there would be more configurations available for testing. An imple- mentation of HIL to any sort of hardware, should benefit any company. HIL made this project easier for us, the writers, to continuously test our written programs every time we updated it. However, there is not just the smoothness of the testing that would benefit a company. Most companies in the world are working toward a greener future, an implementation of HIL will lower the number of resources shipped for creation of prototypes. With fewer prototypes being built, less material would go to waste.
27 | REFERENCES
References
1 Saab. About us [Internet]. Saab; [date unknown; cited 2021-03-23]. Available f rom:
https://www.saab.com/about
2 Versluis G. Xamarin Continuous Integration and Delivery. 1st ed. New York, NY: Apress; 2017.
3 Devops. Understanding Continuous Integration, Delivery and Deployment [Internet]. Devops;
2016 [cited 2021-03-24]. Avaible f rom: https://devopscube.com/continuous-integration-delivery- deployment/
4 Pittet. S. Continuous integration vs. continuous delivery vs. continuous deployment [Internet].
Atlassian; [date unknown: cited 2021-03-24]. Available f rom:
https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs- deployment
5 Synopsis. CICD [Internet]. Synopsis; [date unknown; cited 2021-03-24]. Available f rom:
https://www.synopsys.com/glossary/what-is-cicd.html
6 Thoughtworks. Continuous Integration [Internet]. Thoughworks; [date unknown; cited 2021-03- 25]. Available f rom: https://www.thoughtworks.com/continuous-integration
7 Thoughtw o rk s. Continuous Delivery [Internet]. Thoughwo rks ; [date unknow n; cited 2021-03-25].
Available f rom: https://www.thoughtworks.com/continuous-delivery
8 RedHat. What is a CI/CD pipeline? [Internet]. Redhat; [date unknown; cited 2021-05-18].
Available f rom: https://www.redhat.com/en/topics/devops/what-cicd-pipeline
9 Avenco M. FPGA-Based Hardware-In-the-Loop Co-Simulator Platform fo r SystemModeler [master's thesis on the Internet]. Linköping; Linköpings universitet; 2016 [cited 2021 may 5].
Available f rom: http://liu.diva-portal.org/smash/get/diva2:1059834/FULLTEXT01.pdf
10 Bacic M. On hardware-in-the-loop simulation. 44th IEEE Conference on Decision and Control, and the European Control Conference, Seville, Spain. December 12-15, 2005
11 Köhler C. Enhancing Embedded Systems Simulation. 1st ed. Wiesbaden, Germany:
Vieweg+Teubner Verlag; 2011.
28 | REFERENCES
12 Statistiska centralbyrån [Internet]. Sverige: SCB. 2020. [cited 2021 May 5]. Available f rom:
https://www.statistikdatabasen.scb.se/pxweb/sv/ssd/START MI MI0107/MI0107Utrikes Tran sp/table/tableViewLayout1/
13 Statistiska centralbyrån [Internet]. Sverige: SCB. 2020. [cited 2021 May 5]. Available f rom:
https://www.statistikdatabasen.scb.se/pxweb/sv/ssd/START MI MI0107/MI0107Utrikes Tran sp/table/tableViewLayout1/
14 Ellis G. Control System Design Guide. 4th ed. Elsevier; 2012.
15 Júnior D. C. S, Oliveira J. G, Almeida P. M. D, Boström C. Electric Power Systems Research.
2019 July; Elsevier, vol. 172.
16 Carraua J. V, Reynoso-Meza G, García-Nieto S, Blasco X. Engineering Applications of Artificial Intelligence. 2017 Sep; Elsevier, vol. 64.
17 IBM. Application Programming Interface (API). [Internet]. IBM; 2020 [cited 2021-05-05].
Available f rom: https://www.ibm.com/cloud/learn/api
18 A. Onsman. Application Programming Interface (API) [Internet]. Tutorialspoint; 2018. [cited 2021-05-05] Available f rom: https://www.tutorialspoint.com/application-programming-interf ace- api
19 API vs Library (What’s the Difference?). [blog on the Internet]. RapidAPI; 2015. [cited 2021 -05- 05]. Available f rom: https://rapidapi.com/blog/api-vs-library/
20 Python. Python is powerful... and fast; plays well with others; runs everywhere; is f riendly & easy to learn; is Open. [Internet]. Python Software Foundation; [date unknown; cited 2021 -03-26]
Available f rom: https://www.python.org/about/
21 Software Engineering Insider. The Python Programming Language. [Internet]. Software Engineering Insider; [date unknown; cited 2021-03-26] Available f rom:
https://www.softwareengineerinsider.com/programming-languages/python.html
22 Pramanick S. History of Python [Internet] GeeksForGeeks; 2019 [updated 2019-05-06; cited 2021- 03-26] Available f rom: https://www.geeksforgeeks.org/history-of-python/
23 Python. A Brief history of the Python Programming Language. [blog on the Internet] Digita- lAdBlog; 2021. [cited 2021-03-26] Available f rom: https://digitaladblog.com/2021/03/04/a-brief- history-of-the-python-programming-language/
24 Jenkins. Jenkins User Documentation [Internet]. Jenkins; [date unknown; cited 2021-03-18]
Available f rom: https://www.jenkins.io/doc/
29 | REFERENCES
25 Kawaguchi K. Jenkins 1.396 released. 2011, Feb 03 [cited 2021-03-18] In: Nabble [blog on the Internet]. Nabble; 2005- Available f rom: http://jenkins.361315.n4.nabble.com/Jenkins-1-396- released-td3257106.html
26 Jenkins. Creating your f irst pipeline [Internet]. Jenkins; [date unknown; cited 2021-03-18]
Available f rom: https://www.jenkins.io/doc/pipeline/tour/hello-world/
27 Tutorialspoint. Acceptance Testing [Internet]. Tutorialspoint; [date unknown; cited 2021 -05-07]
Available f rom:
https://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm
28 Agile Alliance. Acceptance Test Driven Development (ATTD) [Internet]. Agile Alliance; [date unknown; cited 2021-05-07] Available f rom: https://www.agilealliance.org/glossary/atdd/#q=~
29 Agile Alliance. TDD [Internet]. Agile Alliance; [date unknown; cited 2021-05-07] Available f rom:
https://www.agilealliance.org/glossary/tdd/#q=~
30 Microsoft. End-to-end intelligent automation [Internet]. Microsoft; [date unknown; cited 2021-05- 07]. Available f rom: https://clouddamcdnprodep.azureedge.net/gdc/gdcG3Ykpk/original
31 Robotframework. Introduction [Internet]. Robotframework; [date unknown; cited 2021-05-07]
Available f rom: https://robotframework.org/#introduction
32 Eclipse Foundation. About the Eclipse Foundation [Internet]. Eclipse Foundation; [date unknown; cited 2021-04-28] Available f rom: https://www.eclipse.org/org/
33 GitHub. Where the world builds software [Internet]. GitHub, Inc; [date unknown; cited 2021-04- 19] Available f rom: https://github.com/about
34 GitHub. The tools you need to build what you want [Internet]. GitHub, Inc; [date unknown; cited 2021-04-19] Available f rom: https://github.com/features
35 PubNub. What is ngrok? [Internet]. PubNub [date unknown; cited 2021-04-28] Available f rom:
https://www.pubnub.com/learn/glossary/what-is-ngrok/
36 Ngrok. What is ngrok? [Internet]. Ngrok; [date unknown; cited 2021-04-19]. Available f rom:
https://ngrok.com/product
37 RaspberryPi. FAQs [Internet]. RaspberryPi; [date unknown; cited 2021-03-15]. Available f rom:
https://www.raspberrypi.org/documentation/faqs/#introduction
38 P. Fromaget. The Epic Story of the Raspberry Pi [Internet]. RaspberryPi; [date unknown; cited 2021-03-15]. Available f rom: https://raspberrytips.com/raspberry-pi-history/
30 | REFERENCES
39 Opensource. What is a Raspberry Pi? [Internet]. Opensource; [date unknown; cited 2021-05-04]
Available f rom: https://opensource.com/resources/raspberry-pi
40 Adams J. Raspberry Pi 4 Model B (REDUCED) [Internet]. Raspberry Pi; 2019 [cited 2021 May 04]. Available f rom: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schemat- ics/rpi_SCH_4b_4p0_reduced.pdf
41 GitHub. About webhooks [Internet]. GitHub, Inc; [date unkown; cited 2021-04-19]. Available f rom: https://docs.github.com/en/developers/webhooks-and-events/about-webhooks
42 Melendez C. How to Integrate Jenkins with GitHub [blog on the Internet]. Cprime; ©2021-. [date unknown; cited 2021 Apr 15]. Available f rom: https:// www.cprime.com/resources/blog/how-to- integrate-jenkins-github/
43 Avraham G. Error: Opening Robot Framework log failed. 2016, Apr 13 [cited 2021-05-11]. In:
Stackoverflow [blog on the internet]. Stackoverflow; 2008-. Available f rom: https://stackover- f low.com/questions/36607394/error-opening-robot-framework-log-failed
44 Nuttall B, Jones D. Gpiozero [Internet]. Ben Nuttal Revision 2021; [date unknown; cited 2021 - 05- 04] Available f rom: https://gpiozero.readthedocs.io/en/stable/
31 | APPENDIXES
Appendixes
Appendix A: Configuring Jenkins Pipeline with a Webhook.
This section presents the steps of configuring Jenkins to connect the Jenkins server to GitHub, how to make the local host port connectable from other nodes and how to set up a webhook to automatically build pushed commits.
Declaring the GitHub Repository URL to connect with Jenkins.
The payload URL must be declared as a GitHub-webhook at the end of the line.
32 | APPENDIXES
Specifying which events to trigger the webhook.
Activate the webhook.
33 | APPENDIXES
Enabling the Jenkins project GitHub hook trigger for GITScm polling.
Use Ngrok to connect the Jenkins local URL to a public URL on the same port.
Here you see the output in the terminal on the master node when another node is successfully connected.
34 | APPENDIXES
Appendix B: HTML Log
Script executed: System.setProperty("hudson.model.DirectoryBrowserSup- port.CSP","sandbox allow-scripts; default-src 'none'; img-src 'self' data: ; style- src 'self' 'unsafe-inline' data: ; script-src 'self' 'unsafe-inline' 'unsafe-eval'
;")
Robot log after successful test.
35 | APPENDIXES
36 | APPENDIXES
Appendix C: Jenkinsfile
Jenkinsfile script.37 | APPENDIXES
Appendix D: Pedal Simulator
Robot Framework code:38 | APPENDIXES
39 | APPENDIXES
40 | APPENDIXES
RPi_GPIOZERO library, python code:
41 | APPENDIXES
StateCheck library, python code:
42 | APPENDIXES
Appendix E: Control Panel Simulator
Control Panel, Python code:43 | APPENDIXES
44 | APPENDIXES
TRITA TRITA-CBH-GRU-2021:054
www.kth.se
