 Welcome to the Sulekvarnivkar's keynote. How are we running Sulekvarnivkar? Well, we have a small core team, continuous integration architecture, that was the Sulekvarnivkar backend infrastructure, and we support up to around 111 developers who consist of many smaller teams and they have at least one DevOps, you can add nodes, pipelines and repositories. And whenever a new team wants to use Sulekvarnivkar, continuous integration architecture trains one of these people to become a DevOps. So, why are we using Sulekvarnivkar? Well, one of our developers is in a really good way, and he believes that premium cars need premium tools, and Sulekvarnivkar is a premium tool. And it forces us to have a green master, and in that way we increase our development speed. For example, the one pedal driver Polestar 2 was built with Sulekvarnivkar. Sulekvarnivkar 3, why do we use that? Well, to handle development in an NVIDIA central computer, but there are many teams with different garrids, and we have the introduction of cloud nodes, we really need Sulekvarnivkar 3. And here we rely on cross-project dependencies, which is the feature of Zulekvarnivkar. And as mentioned many times before, the most important feature of Zulekvarnivkar is the gating system. Do not merge broken code. Polestar 2 project has had a green master since April 2018, while other non-Zule teams on our company have long periods of broken master tracks, and even turned off CI in periods. There are three other features that we really love with Zulekvarnivkar, and one is speculative merge. And speculative merge makes the merging of new changes into master dependent on the build capacity, basically, because you test everything in parallel. You also have the prioritized queue system, and this is very important when there is a deadline and there is a long queue, at least then you start the jobs that are most prioritized and you keep the customers happy. CI job configuration together with software in repository is an essential tool. So here are some of the software components that we currently build with Zule. We have some autonomous drive components, decision manager and so forth. These are high-level AP functions. And then we have propulsion vehicle control, which actually controls the car's variability. We have the dependability of the same functions, which is the fallback strategies. We have thermal control, control the cooling systems. We have vehicle state functions, which controls the accelerations and vehicle states. And we also have a brake planning, because in electric car you can brake both with an electric engine and the friction brakes. And then we have some components controlling the doors, the seats, the car mats, the steering, and the central onboard diagnostic core, which actually keeps track of the state of the components of the car. And also the central core, low-power CPU-based technology. And that's developed in Rust. And this team really likes the picture about how well suited Rust is for automotive development since it tries to be safe by default. In this picture you see two typical pipelines that we have running Zule. And the dots here are automatic jobs and the capacitators of the lines are manual steps. In the middle here on the left side, you can see a pipeline that we have when we generate the C code with the target link and sim link. And we have a lot of link jobs here because we handle security-class software. And that first box describes the check pipelines, and there is code review, plus one plus two leads you and starts the gate pipeline. And here we do system tests and we compile targets. And our releases are triggered by creating git tags. And that can change logs and so forth. And in this picture you can see some of the tools we use in this pipeline. And we rely on, for instance, Silver and Test River to create the sealed components that are not bound to the target. And you can also see some of the compilers we use in this environment. So what does our future also look like? Well, currently we're trying to look into how to handle scalability and move this to Kubernetes. Since all of our developers are located here in Gothenburg, it means that during the night when we're not really running anything, we're still paying for all our services. And we also have a need to be able to nest virtualization, and this is not really possible to do in AWS currently. And we believe we might be able to do this in Azure. And we also have developers who are using GitLab, so we need to be able to start listening to those repositories. Thank you for listening. Thank you.