Autonomous cars are vehicles that can drive to a predetermined destination in real traffic without the intervention of a human driver. To ensure that the car gets from A to B as safely and comfortably as possible, various precautions must be taken. These precautions are explained in the following sections using various questions and security concepts. In addition, further questions are used to answer typical questions in the field of autonomous driving.
The model we’ve chosen is an attempt to implement one part of a large SCM business model. Since an example of shipping processes for single items does already exist on IBM’s platform ‘DeveloperWorks’, we focused on the ability to create and place composite orders.
Many of today’s supply chain management (SCM) solutions still involve enormous amounts of manual work. The procedures required for proper record keeping often rely on manual input, which makes them slow and prone to errors. Additional terms, such as price agreements, conditions that must be strictly adhered to, as well as penalties for neglection of the latter, rely heavily on the completeness and correctness of the recorded information.
The infographic “The Paper Trail of a Shipping Container”, published by IBM, outlines the challenge to improve the management with blockchain technology, using the global container shipping industry as an example.
Hosting your own GitLab server
Some users might have concerns regarding security using GitLab for a variety of purposes, including commercial and business applications. That is, because GitLab is commonly used as a cloud-based service – on someone else’s computer, so to speak. So setting it up for running it on your own server is the conclusion, whether it be a NAS, real dedicated server or even a Raspberry Pi. So, as a side quest, we decided to set things up on a Raspberry Pi Model 3 for comparison. The following part will cover the installation procedure (mostly according to the official GitLab page) as well as hints to some potential pitfalls.
Our first approach was to use the existing GitLab instance of HdM for our project. For them, a shared runner was already defined on which we could run our jobs, so we were able to focus on the CI process itself. This plan worked out at first. We simply defined build and test jobs, which passed without any problems. But when we tried to deploy to our staging server we were a bit confused, because no matter what we tried, the SSH connection to the server could not be established. Even after several reconfigurations of the keys and rewriting of the job we did not succeed, which was surprising, because we could connect to the server from our PC via SSH without problems. Finally, we found out that the HdM firewall blocked our SSH connection to the outside. Since the “HdM-GitLab solution” seemed to be a dead end, we decided to set up our own GitLab instance to be independent of external configurations.
When it comes to software development, chances are high that you’re not doing this on your own. The main reason for this is often that implementing components like UI, frontend, backend, servers and more is just too much to handle for a single person leading to a slow development process. So, you have to team up with others. Therefore some collaboration tools (e.g. SVN, Git) have been established so that you don’t accidentally overwrite someone else’s code and vice versa.
The big challenge with such collaborative projects is to ensure a high quality of the software even with a high level of developer activity. One instrument for this is continuous integration, whereby the individual application components are continuously brought together and successful interaction is ensured.
Especially in large projects high software quality and a structured development process are of enormous importance. That is why we decided to carry out the complete development and quality assurance process from the creation of a project, the definition of tests and continuous integration of the components to the automatic deployment of the application using a small sample project.
The following image shows the architecture of the small node application:
You will learn the steps necessary to configure the CI pipeline and best practices in relation to a CI pipeline for Unity projects.
Continuous Integration is an increasingly popular topic in modern software development. Across many industries the companies acknowledging the importance of IT and delivering value to their customers through great software prevail against their competitors. Many reports indicate that Continuous Integration is one of the major contributing factors to developing high quality software with remarkable efficiency. There are many excellent articles, talks and books explaining the principles of CI in theory. During the lecture System Engineering and Management, we had the opportunity to apply our abstract knowledge and gain our own experience by creating and operating a CI pipeline in an accompanying project. The following article covers the approach, major challenges and most important the lessons learned of our Continuous Integration endeavor. By pointing out relevant issues we want to raise awareness on our misconceptions and mistakes we committed so you can avoid them in the first place.
When we started the project “Flora CI” for the lecture “System Engineering”, we planned to deal with Continuous Integration. As an important aspect of software engineering all of us have previously been involved in projects where code of developers had to be merged and builds had to be automated somehow. Anyway we felt we could dive deeper into CI pipelines and learn what it needs to get them running in a performant, useful and reliable way.
On our journey building such a system we also planned the containerization of all components in order to achieve the strongest possible encapsulation of the individual processes and to gain experience in this topic as well. Another planned goal was the automatic deployment into the corresponding Android and iOS App Stores as well as the provision on a web server.