Thinking out loud

 NASA used a precursor to these technologies to bring the Apollo 13 astronauts back to Earth. Lockheed Martin claims these types of solutions are one of six game-changing technologies in the defense industry. The opinion-forming Gartner includes them in its list of ten strategic technologies that can streamline corporate decision-making processes. When Porsche and Volkswagen Group reach for them, it’s a signal for the automotive industry to  become interested in digital twin technology for good.

Although the concept of a digital twin had been developing in the space industry since the 1970s, it was not until the 1990s that it was first mentioned in the literature (the book entitled  Mirror World, by David Gelernter). In industry, the technology was recognized even later, 30 years after the Apollo mission, when the authority in the field of PLM - Michael Grieves - disseminated it.

Today, the technology, which was officially named Digital Twin by NASA just over 10 years ago, is placed on the pinnacle of key solutions at the convergence of the virtual and real world. It works well wherever there is a high number of failures, work of coupled systems, and where the production process is long and burdened with numerous risks.

The  automotive industry is one of these sectors, as demonstrated by the virtual car concept developed by Porsche for the new Taycan. What is a digital twin and what benefits does it bring?

•  test prototypes for their functionality, durability and user expectations;
•  predict defects and analyze possible design errors;
•  save time and financial means;
•  reduce design and production risks;
•  improve monitoring capabilities of vehicle fleets;
•  and best of all - it enables continuous product improvement, as it often collects data from not only one, but thousands of objects. This makes it learn faster and predict defects more precisely, as it is based on knowledge gathered from a vast  number of sources.

In the case of cars, these could be sensors from dozens of systems spanning the entire vehicle lifecycle: from research and development to the manufacturing plant and  OTA updates , to  connected services .

„Chassis twin” - a virtual car concept developed by Porsche for TaycanThe „chassis twin” project has been in the process of development at Porsche for the past three years and then it was continued by the CARIAD company (the Volkswagen Group's vehicle software provider). The air suspension of the new Porsche Taycan was chosen as the main object.

Why the chassis and not the entire car? Because it is this part of the vehicle that is subjected to the most strain, especially on racetracks.

Porsche engineers used intelligent neural algorithms to centrally analyze the data, and in-car sensor data was collected not only from Porsche cars but also from Volkswagen Group vehicles. This increased the data pool by over 20 times. The "chassis twin" concept enables chassis loads to be detected, even if they are not noticeable inside the cabin, and notify the driver before faults appear, even when no suspicious sound or vibration has yet been noted by the driver or mechanic.

The data collected by the vehicles is sent via Porsche Connect to a  central system in the cloud , where an algorithm calculates the relevant durability and vehicle operation thresholds for the whole fleet of vehicles to create a baseline. When these are possibly exceeded, the driver of a specific vehicle receives a notification via Porsche Communication Management (PCM), that the chassis may require inspection. Looped into the computational work, the algorithm recommends not only the type of service needed but also the scope of work to be carried out in the service center.
By removing a faulty or overloaded component early on, the driver will not only be able to avert potential malfunctions, but also keep the vehicle in better overall condition.

In the future, based on a vehicle's digital usage history, Porsche or a  partner insurance broker can offer extended warranties and better services to the driver . The data can be classified, analyzed, and used not only for repairs to a specific vehicle but to predict life-cycle events for the entire product. This allows Porsche to create new services and features, and to test different scenarios for the development of a particular vehicle line. Thus, it saves the time and resources required to bring ill-conceived solutions into reality.

The other possible use case is that drivers themselves can use the  data collected by the digital twin to negotiate with the prospective buyer. The buyer can view the vehicle's overall condition and chassis service history.
As for drivers' concerns about their own privacy, the manufacturer assures that it collects data anonymously and the system does not store any information that could identify the driver directly. The future of the concepts digitization of the automotive industry is gaining pace year after year. The digital twin concept may prove to be one of the key technologies that will push  software-defined vehicles to new tracks and help companies create safer cars, provide new services and increase vehicle lifespan.

So far, half of the Taycan users have signed up for the Porsche pilot program, which collects data from the chassis of their sporty electric cars. In 2022, the program is to launch at a test level, and only sensor data directly from the mechatronic components will be evaluated. In the future, the concept is to reach its full potential, making it possible, among other things, to calculate the wear and tear of specific components without the need for physical measuring devices.

How will the  "chassis twin" model developed by Porsche work out ? The future will tell. What is certain is that a return to the past is only possible in the movies. In 2022, Volkswagen is commencing an era in which a virtual equivalent will soon await the driver, in addition to their actual real vehicle.

 The subscription business model outperforms the non-subscription business as we observe the shift from ownership towards usership. The success of services like Netflix for movies, Spotify for music, Microsoft Game Pass for video games quickly spreads outside from the entertainment industry. For industries based on the services, not on physical products, the shift from one-time or reoccurring payment to subscription-based service is easier.

Not-so-warm welcome for subscription model in automotive

It’s harder to justify monthly payments for the service if it enables the device or feature already present in the product you have already paid for. The huge backlash in media happened in a reaction to BMW’s announcement in 2020 that the company has been considering selling heated seats as a subscription-based feature.

Most of the criticism was associated with the fact that the overall price of the car was the same, and obviously, it was already equipped with the electric pad in the seat, while there was no additional software for handling the feature - it was just enabling and disabling the button. Some of the journalists even called that “simple-feature-as-a-service.” That resulted in nightmarish marketing for the idea and postponed the implementation of similar models by other OEMs,  encouraging them to rethink the risk of making similar announcements.

Subscription business models become new normal

But in the last few years, a lot has changed. People get used to the subscription payment model appreciating its benefits. Also, more and  more features in the car are based on the software , so it’s just easier to justify additional payment over the initial vehicle purchase. The overall reception of the idea shifted from mostly negative to neutral or positive.

At this point, customers understand that sometimes building-in hardware that is not activated can be cheaper than making hundreds of configuration versions. Also, the vehicle manufacturers start to learn how to better advertise the benefits of the subscription business model and how to better pick the features that fit this kind of model. It also enabled certain flexibility if this is a corporate vehicle, with basic default configuration, and the driver would like to add Apple CarPlay or enable additional convenience features, like opening the car with the smartphone.

How OEMs can successfully implement a subscription model

For OEMs planning to start with this business model, the moment for building a platform supporting subscription-based services is now. Not just the payment system, because the subscription business model is based on the idea that the feature can be enabled and disabled on the fly, basically  making Connected Car a key requirement , while  OTA makes it much more robust long-term .

It all starts with requirements. Let’s try first to distinguish typical types of feature purchase for a vehicle:

•  Standard equipment (automatically activated in production phase)
•  Runtime - associated with the driver or limited-time licenses
•  Lifetime - associated with the vehicle, does not expire  
   
  •    Purchased on an initial configuration in a dealership  
   
  •    Purchased aftersales (either in dealership or online)  
   
•  Subscription - associated with driver or vehicle, can expire  
   
  •    Automatic re-subscription (e.g., no end time)  
   
  •    Manual re-subscription (e.g., end time after X months)  
   

The other key aspect is offering differentiation between countries, regions, and continents. The same feature may be available as a subscription in the EU while only available as a one-time purchase in the USA.

To make the offer complete, the manufacturer may allow buying a custom offer specific to geographical location - for example, the additional package offered when the driver enters Nürburgring - 24 hours of additional racing time-tracking features.

Building a system for the new model

Our system has to handle all those use cases. To accomplish that, we need to build a solution in which the scheduler (sometimes called cron, from the name of Linux job scheduler) is the core component. It is responsible for triggering notifications or events at specific periods - for example, resubscription notification monthly, to trigger the payment, or license cancellation event after a configured period.

The scheduler itself is just a single, small part of the system. The other important piece is the database for storing the subscription status and the API backend for retrieving and updating the values. Consistency is crucial, as the feature getting disabled by mistake leads to a bad user experience.

 The system has to be connected to the vehicle . In most cases, this is done asynchronously through queues like Kafka or RabbitMQ. This gives better stability and reliability than direct connections.

Lastly, we need to ensure that the feature is actually enabled or disabled in the vehicle. This means the vehicle has to receive the correct, unique license for that feature when it’s enabled, and revoke it when it is disabled (alternatively, the license can be automatically pushed every, for example, 30 days, with expiration time set to 33-35 days, to prevent feature loss when connectivity or payment problems occur.

To avoid building an additional retry mechanism into the licensing system itself, it’s better to update the feature state using Digital Twin. In this case,  the digital representation of the vehicle is updated with the new license, and it is then responsible to synchronize itself with the vehicle when the internet connection to the car is available. This makes the system conformant to the single-responsibility principle, so the license system does not have to know or understand the vehicle connectivity.

That’s the basic architecture of our system for handling licenses and subscriptions of digital services. Obviously, that’s just the beginning. For OEMs, where the scale of digital business grows exponentially, the next important topic would be the reliability of the system. For that, scaling to meet the demand is important, as well as caching the current state of licenses to avoid complex queries.

Apart from that, this is enough to start with the feature activation and deactivation and handling subscriptions. Of course, it must be connected to mobile apps and online stores for purchases and to payment systems, but those are already used by most enterprises.

Is this really the future? It seems like we can’t avoid it anymore, especially with  shared mobility growth, the ability to unlock temporarily additional features is tempting. Imagine grabbing a Ferrari for a weekend to take it to the track, enabling an additional 50HP and an  advanced AI for measuring your times and proposing a better moment to break before the turn and accelerate afterward. And paying for only 2 days. This may make all the difference in convincing customers to the new subscription business models.

Ensuring distributed quality assurance and managing a QA team is not always as straightforward as one may think it is. There is no way to predict the exact number of bugs being introduced into the code and therefore, there is no way to calculate the precise time when those issues are going to be fixed. The planning process is very fluid and very often the development team requires QA team’s attention and help to reproduce the issue. Such challenges arise even in the most usual team setups when there’s just one team. Then what about a project that is so big, that there are three QA teams working together on ensuring the quality and writing automation tests?

Distributed Quality Assurance

Scaling the project by introducing more teams arise many different kinds of challenges. Sometimes the teams work in different, just slightly overlapping time zones. Sometimes it is a different culture and language. Sometimes, if said teams are hired by different vendors, the processes may differ. Rarely, this is a combination of all of those factors.

We are going to take a look at precisely that situation. The project included multiple teams writing automated Selenium tests for a single, large-scale web project simultaneously. Testers were working from Europe, Asia, and the US. Due to customer policy – all the source code for automation tests had to be pushed to a single Git repository.

Initially, there was no cooperation process defined as other teams joining the project organically when parts of the application they were responsible for, were integrated into the system. At this point, nobody anticipated an inevitable disaster.

The realization came in when suddenly a new pull request came in. After six months of work, thousands of lines of the code, and multiple developers contributing - it was impossible to review such a big change and its impact on all other code – especially to foresee a possibility of invisible conflicts.

At this point, we knew that we must create a common process for all teams. We can’t just discard 6 months of development, but at the same time, we can’t merge it without thorough verification. One of the ideas was to split the work into multiple groups of branches – each team having their own set of development/integration/master, etc., but this contradicted the very idea of cooperation between the teams.

First, we’ve asked to split the huge PR into feature branches – possibly, one branch per test or one branch per feature being tested - and then merge them one by one. Going forward, all new tests should be added the same way, as relatively small pull requests instead of large chunks of code that are impossible to digest during the code review process.

It was necessary to remind the teams that in such a setting, being synced with the latest changes saves everyone a ton of work. The process that we’ve introduced made it mandatory to pull the latest code from the development branch at least once a day to make sure there are no new conflicts.

Then we’ve created separate pipelines for the other teams to test their changes, as even with small worktime overlap, it was still a blocker.

Additionally, the process requires at least two approvers from different teams to merge the changes into the development branch – this way teams do not only keep an eye on code quality but also make sure changes from other teams do not impact their work.

It may sound just like a few small steps, but overall, the implementation of the new approach took almost two months. This includes various meetings, agreements, presentations, and writing down the processes. On top of that, teams had to take care of integrating all PRs, big and small, into a new “version zero” codebase, which then was used as a fresh starting point.

The process was written down on a Confluence page accessible for all team members in all teams. It does not just include the rules initially accepted by the teams, but also coding standards, style guide, and links to the agile delivery process used for that particular project. Afterward, the result was presented to all teams and agreed to use from then on. And together we’ve decided to have a weekly sync just for the QA teams.

Key takeaways

The resulting process is working very well for us. It is a scaled-up version of the process we have used internally in our team, so the implementation went smooth and swift. The velocity of the automation tests development also improved over time, as less time was spent on fixing conflicts and going through PRs.

Of course, this process is not a one-size-fits-all solution and does not answer all the questions you might have if you want to implement a similar solution into your QA automation development. Their project includes shared code, such as libraries, which someone is obliged to maintain and take responsibility for. The technical debt reduction also has to be agreed upon and split evenly between the teams. All in all, if the development is based on a solid foundation like the described process, it’s easier to agree on smaller things on the go.

 While the automotive industry is rapidly changing by adopting a software-first strategy, like in other sectors, automotive enterprises struggle with productionizing AI and ML R&D projects. Machine Learning and Data Science teams face numerous challenges, including determining the proper technology, automating workflows, managing computing resources, managing data, and building solutions meeting internal regulations. All these issues can complicate the project even before the kick-off.

So, how do we support AI teams to overcome typical challenges and enable ML engineers and Data Scientists to focus on creating and bringing artificial intelligence algorithms to production?

The implementation of a dedicated deployment platform is a solution that is well suited for  the automotive industry . In particular, it allows you to:

•  accelerate the productionization of AI and ML applications;
•  provide an easy and quick project and user onboarding;
•  simplify access to data and computing resources;
•  ensure high scalability -even when the number of accounts far exceeds thousands of users.

To illustrate the process of working on the platform, let's have a look at a project that the Grape Up expert team had the opportunity to implement.

Building AI and ML deployment platform using proven cloud-native technologies - practical use case

Our client - a well-recognized sports car manufacturer - set us the goal of designing a reliable and extensible architecture capable of handling hundreds of customer accounts for the platform. Tools were to be selected for the project to ensure the scalability and flexibility of operations. The idea was to provide fast and efficient  production of AI/ML software .

Along with building the platform architecture leveraging Terraform orchestrating Cloud Formation scripts, Grape Up ensured efficient migration of existing environments. The solution was integrated with Continuous Integration pipelines and the E2E tests set. To reap the benefits of high-quality performance in multiple regions worldwide, the platform was hosted on the AWS cloud.

Results?

An  AI Deployment Platform was delivered , which was capable of managing a huge number of AI/ML projects and allowed for streamlined processes to create, test, and deploy artificial intelligence and machine learning models into production for  Data Science teams.

Developers were guided through the company's deployment processes and supported with reusable blueprints that could be leveraged at the initial steps of the development.

The cloud-native toolkit that was created provided flexibility and agility, at the same time supporting innovation in the vendor's operations. After introducing improvements to the platform, the customer could reduce the code by 80%, while retaining high quality and testability.

All those solutions allowed  AI software development teams to work more efficiently and reduce time-to-market for new products and services.

If you have ever worked on writing UI automation tests, you probably came to the point when your test suite is so extensive that it takes a long time to run all the cases. And if the suite keeps on expanding, the situation won't look better. Applications are growing and the number of tests will constantly increase. Luckily, there is a solution to speed up test runs. In this article, we present the advantages of using some help in the form of API testing in the UI test suite, focusing on the aspect of test execution time.

How can API Requests help you?

• Tests will be easier to maintain - UI is constantly changing when API requests are persistent (for the most part)
• You will get immediate tests result from the business logic side
• You can find bugs and solve problems faster and in a more effective way
• You will see a significant improvement in the test execution time

If there are some unwanted issues in the application, we want to be able to discover them as fast as possible. That’s why test execution time is significant in the development cycle. Before we focus on the API requests, first let’s take a small step back and take a look at the test from the UI side only.

Customer path

UI testing is literally the path that the customer is taking through the app, and it is crucial to write automation tests for these workflows. Sometimes we need to repeat the same steps in many feature files (especially if we are taking care of data independence ) and it is not necessary to go over them again on UI side in each test.

Imagine that as a customer you can configure your car through the app. You can start with choosing a basic model and then add some extra equipment for your vehicle. Let’s take a look at this example written in Gherkin:

It is basic functionality, so we went through this workflow step by step on the UI side. In this test, we have many components that need to be fully loaded - pages, buttons, modals, and dropdowns. Every action takes some time - loading individual elements and clicking on them. It takes 51.63s. in total to run this scenario in PyCharm:

API enters the stage

Let’s now consider another case. What if customers change their minds about the color of the vehicle or they want to add or delete extra equipment? We need to be able to edit the order. Let's create an additional test for this workflow.

If we want to edit the vehicle, first we need to have one. We can start the Edit car test by creating a new vehicle using all the steps from the previous feature file, but we can also use API help here. Replacing repeatable steps with API requests will allow us to focus on the new functionality on the UI side. Let’s look at the Gherkin file for editing a car:

In the first scenario of this feature, we are creating a car (via API) and in the second one editing the vehicle (through UI). In scenario “Create test car via API” we created the same car as in the previous feature “Create a car with additional equipment” , where everything was done on the UI side. If we look at the result now, we can see that the whole test (creating and editing a car) took less than 17 seconds:

Part for creating a vehicle by API took 11.107 seconds. To run these steps on the UI side we needed more than 50 seconds. To be precise we’ve just saved 40.513 seconds in one test! Imagine that we have another 10 or more tests that need that functionality - it can be a big time saver.

A request for help

Key for benefit from API in UI test suite is to use popular Python library called Requests – it allows us to easily send HTTP requests. Basic POST requests can take the following form:

We have to start with importing the ‘requests’ module. Then we are declaring the URL of the request and data we want to send (provided as a dictionary). The next step is to make an HTTP request where we are passing our parameters (url is required, json – optional - it’s a JSON object which will be sent to the mentioned URL). In the end, we are returning the response from the server.

In our car application, this example will be a little expanded. What exactly is hidden behind lines of code responsible for creating a vehicle via API requests? I will focus on the first step of this scenario: 'Car “<car> from the model “<model>” and lacquer color “<color>” is created via API request’ . If we look deeper, we can see step implementation:

And then if we go further to the car_is_created_via_api function, we can analyze requests sent to API:

In car_is_created_via_api method, we are calling function _create_car which is responsible for requesting API. We are also passing parameters: car, model, and color. They will be used in the body of our request.

As in the basic example, in _create_car function we are declaring URL (our car API) and body. Then we are making a POST request and in the final step, we are returning the response.

After getting the response from the server, at the end of the car_is_created_function , we want to use assertion to check if we got the correct status code. Getting code 201 means that everything went as we hoped. Another result will tell us that something is wrong and we will be able to quickly (hopefully) find the gap in the code.

Good Team

We went together through the advantages of using API help in the UI automation tests suite and a comparison of two approaches to testing. We also focused on speeding up tests suite execution time using Python library Requests . We believe that after reading this article you can see that API requests can be great companions and you are encouraged to start using this concept in your test automation projects.

 The turn of the year is a perfect time for summaries, planning future activities, and market research. It is no different in the automotive industry, which is subject to dynamic changes. Their direction is obviously determined by software development.  It seems that in the next few years this will be a crucial competence of each vehicle manufacturer. Maybe equally as important as producing the engine!

If you listen to CARIAD, Stellantis, Tesla, Audi, and others, you will learn that each and every one of these companies believes that  the future of the automotive industry is software-centric . As the name says, if you want to achieve that, you have to learn how to build software and this may be a bumpy road for most of the OEM’s. How to align a legacy, waterfall approach of building cars with the lean, agile software development paradigms, or modern, disruptive cloud and AI technologies? CARIAD already seems to know, Stellantis says they have a plan, Porsche is at full speed, and Tesla was born that way. Exciting times. And it will only get more interesting!

Buzzword of the year: OTA or EV? Both!

If you are a car geek and digitalization fan, you probably know what were the hottest car premieres in 2021. But do you know what all these cars have in common?

•  Audi e-Tron GT
•  Ford Mustang Mach-E
•  Mercedes EQS
•  BMW iX
•  Rivian R1T
•  Lucid Air

All of them are electric – because electricity is here to stay! They are all  smartphones on wheels because software is the new V8! And all of them take advantage of the hottest trend in connectivity: OTA (over-the-air updates), which means the possibility of adding new features through updates without visiting the dealership. Straight from the cloud. It, at the same time, builds a highway for the creation of new revenue streams and a completely new level of customer care provided by vehicle manufacturers.

It means all the predictions and all the trends we have seen in recent years are here to stay, but now all OEMs are on board, and the trends will play a much more significant role.

Let’s take a look at those that we think are worth highlighting as the automotive trends for 2022 and above.

What should we look for next year and above?

Change 1: Electrification is gaining power

There is no escape from electricity - mainly due to the challenges facing zero emissions. All data indicate that 2021 will end up as the year with the highest sales of these vehicles (EV and PHEV combined), reaching 6.4 million units worldwide [EV Volumes]. This would be a 98% increase compared to the previous year. It is likely that the EV sector will face changes in the next 10 years, comparable to what happened in the internal combustion engine vehicles during the first 100 years of development!

What influences (and will continue to influence) the increasing consumer interest in electrics? There are numerous factors. Let's list the most significant ones.

The spread of other EVs

Urban scooters, bicycles, and electric mopeds are no longer a surprise and are increasingly becoming the dominant mode of transport in congested city centers. With the spread of the  shared mobility trend, which makes it easy to rent out vehicles for a flexible period of time, consumers are gaining confidence in them and begin to notice the advantages of this solution, which is reflected in their future purchasing decisions when it comes to new cars.

New legislation on EVs

The UK, France, Norway, and Germany are implementing laws to ban the sale of new petrol cars by 2025. California wants to reach this goal in 2035 and replace its entire fleet of diesel buses with electric ones as early as 2029. Changes in legislation inevitably trigger changes in vehicle production and affect other sectors. For instance, the construction industry, which will be obliged to equip buildings with sockets and an electrical grid that will allow the charging of electrics in their own homes, which is already done in the USA.

Increased range of EV

The range of electric vehicles has always been a challenge compared to petrol vehicles. The problem was not just the short life of the battery itself, but also the limited network of available chargers. With the development of new technologies for extracting minerals necessary for making batteries and ways of power storage, these factors will gradually become marginalized.

•  Tesla announces it is phasing out the use of cobalt in its batteries to produce a $25,000 electric vehicle in three years - although it is already leading the way in new car sales in Europe.

•  Lilac Solutions, a company supported by Bill Gates' Breakthrough Energy Ventures, is implementing technology that allows lithium to be extracted without draining groundwater.
•  Alternatives to lithium-ion battery technology are emerging, such as the solid-state batteries being developed by Toyota.
•  There are also growing claims that it is not batteries but supercapacitors that will power electric vehicles. Instead of storing energy in chemical form, like a battery, they hold it in an electric field. This makes them more durable and ensures a longer life cycle.
•  In 2019, there were 175,000 public EV chargers in Europe. By 2025, it is estimated that this number will reach 1.3 million, and in 2030 it will already be 2.9 million [ EV volumes]. With the development of connected car technology, this will enable more charging points to be found efficiently and without hassle, and will substantially extend the possibility of a seamless journey.

Change 2: Seamless connectivity and on-board services

OK, 5G is the thing! In China all their biggest cities already have 5G coverage, now the USA and Europe must and will follow. 5G takes  internet connectivity to another level . This is and will be a complete game-changer in several areas:

•  V2X for building a mesh of connected vehicles, road infrastructure and third party devices.
•  Autonomous driving applications with hybrid cloud and edge systems, requiring very low latency.
•  Real-time telematics for tracking the status and location of vehicles almost in real-time, which will make driving safer and more comfortable, save time, reduce vehicle operating costs or allow the purchase of an insurance policy tailored to the driver's driving style.

You can read more on this topic here and  here .

Change 3: Better UX/UI solutions and use of augmented reality

Cockpits of modern vehicles are filled with screens. Pushing all controls, buttons, and knobs to touchscreens decreases production costs and makes the vehicle look more premium. At the same time, customers report that the vehicle interfaces are increasingly harder to operate. Also, the old, slow, or stuttering infotainment makes the whole look & feel of the vehicle worse.

This forces manufacturers to put more effort into the UI/UX design, as well as improving other, safer ways to interact with vehicles. A great example of this are solutions already familiar to consumers in other market sectors - voice assistants and gesture recognition, as well as the most developing technology in this field, i.e. augmented reality.

The latter is increasingly used in vehicles in the form of a Heads-Up Display on the windshield. The following applications can be listed in the vehicles entering the market:

1.     Intelligent Terrain Mapping    - which assists the driver whilst driving by displaying directions, a road map and information about upcoming landmarks.
2.     Automated Parking Assistance -    which, by means of additional lines and indicators on the camera, can make parking or difficult maneuvers easier.
3.     Augmented Marketing -    combining AG with sales and entertainment - not only in the form of offers displayed on the windshield, but also in the course of selling vehicles and advertising them, when you can feel the driving experience without having direct contact with the vehicle.
4.     Intuitive Road Safety -    warning of dangerous driving, pedestrians in lanes, or drivers drifting into the other lane.

You can read more on this topic  here

Change 4: Increased focus on cybersecurity and data privacy

 The connected car operates in a V2X ecosystem consisting of data networks, road infrastructure, other vehicles, and third-party applications. In such an environment, the threat level of cyberattacks is at a very high level. Hence, in the coming years, those involved in the automotive industry must make the utmost efforts to protect not only consumers' sensitive data but also their lives and health.

That cyber attacks will occur is more than certain. The industry's task is to adapt current technology and regulations so that potential threats are minimized at the point a vehicle leaves the factory.

Cyber security should be at the heart of every SVD vehicle leaving the factory. Especially since we're not just talking about the sensors that will be programmed but entire production chains, which can also become potential targets for attack.

In order to prevent such activities, as of 2018, more than 80 organizations from around the world, have created  the ISO/SAE 21434: "Road vehicles - Cybersecurity engineering" standard, which encompasses a set of guidelines for securing vehicle design, manufacturing, maintenance and decommissioning processes. These guidelines define cybersecurity processes for different phases of vehicle development, specifically:

•  addressing and mitigating process vulnerabilities;
•  identifying unsecured ECU (engine control unit) connection protocols;
•  and unsecure aftermarket products and services.

The software industry, however, which supplies software to OEMs, must be prepared for the European Commission's regulations on  AI-related rules . The regulations are expected to cover:

•  the potential risks that artificial intelligence applications can create;
•  requirements for AI systems for high-risk applications;
•  specific responsibilities of artificial intelligence users and high-risk application providers;
•  proposals for compliance evaluation before marketing the AI system;
•  governance structure for AI applications at European and national level.

In the interim period, the regulation may be effective in the second half of 2022. The second half of 2024 is the earliest period of application of the regulation to  AI application operators.

Change 5: Expanding software development capabilities

The transition from a vehicle company to a company dealing with software on four wheels is a complex and challenging process. Such a  transformation inevitably awaits all automotive companies in the coming years. It is worth noting a few factors that are critical to the success of this endeavor.

•  Companies need to build their internal software development structures, become attractive employers for software engineers and gain great partnerships in the software development world.
•  Increased focus on reliable internet connectivity for all produced vehicles, as well as cloud connected car systems.
•  Work on regulatory compliance in terms of GDPR, data collected from vehicles and cybersecurity.
•  Constant growth of software development teams and departments, as well as new partnerships regarding software, cloud and AI.

Change - the only certain thing in the automotive industry

Changes related to the reduction of CO2, the development of the Internet of Things, or automation will affect most industries in the coming years. However, the  automotive sector , where technological, social, ecological, and consumer trends meet, may become a litmus test for the upcoming developments.

Just as new technologies took the telecommunications or smart building industry by storm a few years ago, they will now begin to change the way we use vehicles. Can we set a date when we can say with a high degree of certainty:  this year will be the year of the     connected car    ? Unlikely.

Just as the marketing specs failed, who claimed each year:  that this year will definitely be the year of mobile.

These changes grow exponentially, remaining unnoticed for a long time, but suddenly we realize that they are already with us. We live in a world where they have already become commonplace and everyone benefits from them. Companies working at the intersection of the automotive industry should not let this moment slip by. There comes a time when the car will become our second phone.

 Connected Car ,  Software Development and  Autonomous Driving are the three most repeated words in the automotive industry. It’s hard not to notice that all three are basically different use cases heavily dependent on different kinds of software: cloud, AI, edge computing, or internal applications. Analysts, investors, management, and even regular employees of OEMs seem to believe and agree that software is the future of the automotive industry. But why?

Automotive software - how did we get there?

To understand the origins of this trend, let’s briefly look at the last 20 years of automotive history. On the market, where 99% of vehicles were based on combustion engines, a new entrant appeared. Tesla Motors Inc. A company with no background in building cars, named to pay tribute to the well-known electrical engineer, Nikola Tesla. A year later, famous entrepreneur, Elon Musk, decided to invest in this dream of building electric vehicles for the masses.

Fast forward to 2012 and we have the world premiere of the Tesla Model S. The Electric Vehicle, being the biggest disruption in the automotive industry in years, immediately receiving several automotive awards, including Car of The Year. Designed and developed by a company with 10 years of experience on the market and literally, a single vehicle developed earlier (the original Tesla Roadster). This showed that there is a big, unoccupied market for electric vehicles.

Just a year later, the Tesla Autopilot was introduced, and the whole world joined the hype for autonomous driving.

Why did Tesla get so popular?

It was not just because the market desperately needed an electric vehicle. Since the beginning, Tesla has been designing its cars to be software-centric. Big on-board CPUs from Nvidia support, not just Autopilot but also a multitude of applications and services available in the largest (at the time at least) central screen of a road car.

And the software has been updated very often using Over-The-Air upgrades,  giving the customers the feeling that the software was always fresh and the producer quickly reacted to feedback with new changes. Effectively, making the software a major selling point.

Electrification

Apart from the software-defined vehicle focus, electrification started as a solution to reduce the CO2 footprint of the industry. Both BEV and PHEV vehicles development was caused partially by new legislation and sustainability requirements, and partially of course by the success of Tesla. The EVs offering is increasing year by year, and most of the brands announced the potential timeline of reducing the combustion engines offering to 0 models.

The industry today

It seems like all of the large OEMs treated Tesla as their very own R&D department and allowed the company to conduct the world’s biggest ever market study. Tesla was able to prove that people actually care for the CO2 emission and want to drive electric cars and also showed that software in a vehicle may be more appealing to end-users than the sound of V8.

On the other hand, we compared Tesla to an R&D department because their cars are not always built with top quality and software sometimes have glitches – all in all, it’s a tremendous idea, but not an ideal car. VW Group, Toyota, or Stellantis could never afford to make such mistakes.

 Software defined-vehicles became a real future trend, not when Tesla S was first shown to the world. That happened when all of the world’s top OEMs decided that enough is enough, the experiment was over and the time to “productionize” Tesla’s “concept” had come.

And here we are today, a few days after Stellantis Software Day, an investor meeting purely focused on the Software-Defined Vehicles and their new platform, STLA (pronounced `Stella`). A few months after Mercedes-Benz announced that they are hiring developers to work on their own Operating System, MB.OS, as part of a greater “Digital First” brand strategy. A year after the CARIAD by Volkswagen Group was fully defined to provide unified software platforms for all vehicles in the group, called ODP (One Digital Platform) or VW.OS and VW.AC (VW Automotive Cloud).

Everyone is fully committed. But what exactly is the automotive industry committed to? Let’s dissect the latest event, Stellantis Software Day, to see the core topics they want to focus on in the next few years.

1.  Disconnecting hardware and software lifecycle.
2.  Broadening the scope of software in the vehicle.
3.  OTA software updates for adding new features.
4.  Using software to create a unique offering for all brands in the group.
5.     Connected Car data monetization    .
6.  Software to support EV and sustainability.

    #SWDAY21Stellantis    | Carlos Tavares, CEO: "We are transforming     #Stellantis    into a     #tech       #mobility    company. We owe it to our customers. We owe it to our Brands. We owe it to the principle on which     #Stellantis    was founded".     pic.twitter.com/iMYHSLpMwL    — Stellantis (@Stellantis)  December 7, 2021

Those are predicted to generate ~€20B in incremental annual revenues by 2030. That, of course, partially answers the “why?” question, but is there more to it?

Coming back to why

If we summarize the situation, we see that electrification and disruption forced the industry to change. The side effect of electrification is making the previous key differentiator - powertrain - much less important. With electric vehicles, the engines are not the key. Most of them are very similar and technology focuses more on batteries. This makes the different models similar, especially in terms of acceleration and horsepower.

So, where is the differentiator? Where do companies look for unique selling points for their brands, and how do they separate the offering of different models when the platform is almost exactly the same?

  https://twitter.com/Herbert_Diess/status/1469218343068614657

As you might have already guessed - that is the software. Of course, it’s not just electrification, the other key aspect is also digitalization of our lives, but the disruption already happened and the industry tries to follow.

The people fueling the future of automotive software

Certainly, when everyone decides at the same time to do a similar shift, it can get complicated rapidly. From the resourcing perspective, in the market with such a shortage of skilled software engineers, when everyone tries to quickly build their software competencies, it cannot come without problems. Hiring an experienced software developer is hard, and it gets harder if a company is fully focused on vehicle manufacturing, with a limited budget for IT and IT recruitment departments. The problems with building teams can result in delays in project start or extending their timeline.

This is where partnerships with companies like Grape Up come into play. Partnering with a software development company with strong experience in the automotive industry can help mitigate those issues - having skilled engineers available to help frame the project, architect, develop, and productionize significantly reduces the risk of shifting towards software development, and in the meantime also allows to train internal staff by working together, hands-on, on the actual projects.

The end

 We are an endangered species, you and me. We fans of speed, we devotees of power, we lovers of performance and beauty, and mechanical soul. We dare not speak of cams or cranks or double wishbones. We fear for our love of roaring V8s and the smell of burnt rubber. We're told to think of the economy, the environment, and not excitement and enjoyment. In an age of hybrid-this and automatic-that, we are the odd ones out. Yet there is hope. There is a haven. A place that celebrates speed, grip, gears, and fun. And it's all here for you to explore.

Jeremy Clarkson

 It cost a staggering $200 for that time. The antenna took up almost the entire roof of the car, the batteries barely fit under the front seat, and the huge speakers had to be fixed to the back of the seat backrest. The year was 1922, just over 20 years after the launch of the first mass-produced Oldsmobile Curved Dash car. Entertainment had just made its entrance into the car industry - Chevrolet introduced the first car radio. From then on it only got more exciting.

Nowadays, 100 years on from that event, we can no longer envisage a car without radio, music, or news. In fact, we can no longer imagine a car without entertainment in the broadest sense of the word. Because the radio - at least in its traditional form - is slowly becoming obsolete. It's being replaced by a "personal radio station" created by the driver - streaming music, favorite podcasts, audiobooks, and even video content.

Although we are still a far cry from the catchy phrase  "a smartphone on wheels" , first uttered in 2011 by Akio Toyoda, the automotive industry is indeed heading in this direction. Cars are ceasing to be vehicles designed to take us from A to B. Like any other device connected to the Internet, they are becoming a gate to new worlds of entertainment, shopping, learning, or gaming.

When finishing shopping or listening to an audiobook on one device, we want to seamlessly continue the activity on a laptop or desktop computer. Whether we like it or not,  the car is becoming another medium that will allow us to stay virtually connected all the time.

Akio Toyoda was wrong. A car is much more than a "smartphone" on wheels!

A potentially larger screen than a smartphone (not only the touchscreen in-vehicle infotainment system panel, but the windscreen too, which can also be used to display content), at least 4 seats that can be independently paired with the in-car entertainment system, and, ironically, much more mobility than mobile devices.

As we look at the development of V2X (vehicle-to-everything) technology, which will turn vehicles into the Internet of Things devices, the opportunities that lie ahead for the automotive industry in the entertainment field are hard to estimate.

One thing is certain. This process cannot be stopped. Every company in  the automotive industry must be aware of the upcoming changes.

According to IHS Markit data, in 2014 only 53% of cars in the USA had a dashboard touch screen, while today this percentage has already reached 82%. These types of solutions can bring automotive companies entirely new revenue streams, and most importantly they will be less dependent on vehicle production cycles and with much higher margins.

The in-vehicle infotainment system market is estimated to be worth $78.9 billion by 2025. [Allied Market Research].

Quo Vadis in-vehicle infotainment systems?

In-vehicle voice assistants for infotainment control

Siri, Alexa, or Google Now are names that have become part of the consumer market and make life easier for most of us, allowing us to make phone calls, send messages or manage our own calendars. While sending voice commands to our phone or the speaker in our home or office is nothing new, communicating with our own car is still some kind of novelty.

And it is here while driving when we need to focus on the road and have our hands free, that voice technology can be of the most benefit and make driving more efficient and smooth. And of course, more fun.

Navigant Research (Guidehouse) predicts that by 2028, 90% of vehicles will be equipped with a voice assistant. Already today - looking at Voicebot.ai data - a large proportion of commands given by drivers are entertainment-related. Playing music, listening to podcasts, finding out about movies, ordering food, or making purchases directly from behind the wheel is becoming increasingly popular among drivers with enhanced IVI systems.

The main players in this section are certainly the manufacturers already known for their other platforms, namely Google and Apple, which are integrating their Android Auto and Carplay technologies in partnership with major OEMs. Hot on its heels is Amazon, which has not only begun collaborating to bring Alexa into Toyota, Ford, and BMW vehicles but also released an Amazon Echo device that any driver can install in their car themselves (as long as it meets the manufacturer's technical requirements).

Vehicle manufacturers, however, are no longer just waiting for the offers of the largest players in this market, but are developing their systems or working with smaller business partners to help them develop such solutions.

Korea's Hyundai has entered into an operation with Saltlux, a company specializing in semantic networks. Honda, Kia Motors, and Daimler are working with the SoundHound start-up. And Volkswagen has invested $180 million in the Chinese start-up Mobvoi.

Gesture-recognition

Voice command in the car is a trend that will continue to grow every year. Yet, there are situations in which gestures are much better than voice commands - for example when you are on a call or have a cold and don't want to strain your throat. Gestures are universal for every driver, while voice assistant applications are often still hampered by technological limitations, for example, due to the variety of accents or the system's adaptation to the driver's language.

As the system recognizes a gesture made with the palm of your hand, fingers, or even your head, you can stay focused on your driving and at the same time activate a specific function when you cannot use your voice command. Scrolling through songs on the radio, raising or lowering the temperature in the car, launching a text message application - all these actions can be configured using gestures. Instead of clicking and scrolling through a touchpad, which always entails taking your eyes off the road, gestures will allow you to boost safety and easily manage the entire system.

Virtual reality & Augmented reality

While currently the introduction of virtual reality in vehicles only makes sense for passengers who do not need to focus on driving, augmented reality technologies are already being successfully implemented in vehicles. Unlike VR, augmented reality does not distract drivers from reality and allows them to concentrate on driving. And they can even increase safety.

Although today this type of technology can only be found in the most innovative and prestigious IVI systems (one of the first cars in which this technology was used was Mercedes-Benz GLE 2020), we should expect this type of solution to develop in the near future, as it brings a whole new quality to in-car entertainment.

Their direct equivalent to the automotive field is the heads-up display system, which is an additional head-up display integrated into the vehicle's windscreen in addition to the IVI control panel. This screen can be used to display destination-related information, traffic warnings, or information about other vehicles on the road (so-called intelligent terrain mapping).

In the near future, these technologies may also be applied in entertainment itself - for instance in the form of augmented marketing. The windscreen will then display interesting offers and discounts from the restaurants, shops or shopping malls we have just passed. The displayed images will of course adapt to our driving speed, and we can decide for ourselves what kind of messages we wish to see.

On-demand in-car services

In-vehicle infotainment systems are the point of contact between different parties: customers, internet providers, companies producing vehicles, making entertainment, or electronic equipment (e.g. smartphones).

In most cases, drivers already have their favorite apps (Google and Apple being in the lead, of course) and use their favorite streaming services. Competing with platforms like Spotify, Netflix, Pandora or Slacker may not necessarily be the best strategy for automotive companies. It is much better to make use of the recognisability of brands that provide entertainment content and, based on this, extend it with a unique offer for their own clients. Opening up to partnerships with third-party platforms is the best way to address  customer needs and create a stream of data that can be monetized .

One of the interesting market examples of this type are the efforts of the GM concern, which has created its own car application in the form of a marketplace, from which the driver can make purchases at Starbucks or Dunkin' Donuts, pay for the fuel at selected petrol stations, and book a hotel or a table at a restaurant.

We should expect that the trend of shopping straight from the car and making the most of the time we have on our commute to/from work while being stuck in traffic jams will not be limited to listening to music and podcasts only. With the development of the Internet of Things, drivers will also be able to control other devices within their "smart" network from their vehicles.

Samsung is already creating solutions that allow the driver to look into their own fridge and decide whether they need to go shopping, turn up the thermostat to prepare the perfect temperature for the return home, activate the alarm when going on holiday, or open the gate automatically.

Rear seat entertainment

Most modern IVI systems are not just an integrated head-unit, i.e. a touch panel on the vehicle dashboard for the driver, but more and more often, interactive panels dedicated to the passengers. These offer practically endless opportunities for entertainment. And we don't just mean the extensive range of streaming video services that can be subscribed to in the vehicle.

After all, the interactivity of the screens makes it possible to implement various applications and gamification elements in the car. These can take the form of quizzes, common picture drawing, shopping via third-party applications, or even karaoke singing, which can also engage the driver.

But what if the sound or type of music doesn't suit the driver, who wants to concentrate on driving? There are already solutions that direct the sound from different areas of the vehicle so that each passenger can listen to different music without wearing headphones.

This is how, for example, the Separated Sound Zone (SSZ) works in KIA cars. Based on multiple loudspeakers and the physical wave acoustics principles, the sounds do not overlap but instead reach their intended audience. Even if powerful beats dominate in the back seat, you can still relax while listening to calmer music in the driver's seat.

In-vehicle infotainment enters a new era

In-car entertainment has a long history. Ever since mobile devices became part of our lives, it is nothing new to connect a smartphone to a Bluetooth radio or for passengers to watch videos on their own smartphones/tablets. The only difference was that, until recently, in-vehicle infotainment was just an accessory, an element that makes a difference and highlights a brand. Today it is a factor on which customers often rely when buying a new vehicle.

In-vehicle infotainment is increasingly rarely limited to a touch screen panel on the dashboard. Right before our eyes, it is growing to be omnipresent and taking precedence over other vehicle functions. Brands that miss this moment and, like Blockbuster in the video content market or Nokia in the mobile market, may find themselves in a completely new reality. A reality in which totally different companies will be on top of the bunch.

 When talking about data monetization in the automotive industry, we tend to focus on technology, safety, sensors, or cloud solutions. However, all these elements fade when confronted with the ultimate element - the driver of the vehicle. Without taking into account their needs and expectations, there can be no question of generating revenue. Any vehicle data monetization strategy must be mindful of this.

We can fine-tune the system, we can find exceptional partners to implement the software in the vehicle, but without a deep understanding of the vehicle user, no one will benefit from the solutions developed. Our organization will put a considerable amount of effort into building the team and implementing the technology, but the new vehicle features will not be used by the driver.

For this to happen, we need two factors: a value proposition of the brand- which explains clearly and transparently what the user will get out of it, and a coherent action strategy based on a market-back methodology that stems from specific market needs and allow us to develop services that are desired by the customer.

What benefits do customers most often look for in a software-defined vehicle?

Remember that just because people want to use a service, it doesn't mean that they will pay for it. What matters here is not just the benefit, but also the way it is presented, the user experience, and the pricing model. Only the combination of all these elements determines the success of the service. First of all, it is worth focusing on the benefits themselves and only then selecting the right technology to match them.

What are users willing to actually pay for and what are they willing to share only? Many studies indicate that the main factor motivating consumers to share data is gamification and rivalry - this aspect has not changed for years, as we can see for example in social media or e.g. "free" applications, which from time to time appear on the market, gather millions of interested users and vanish in no time. However, when it comes to paying for such "services", users are not so willing to use them.

In vehicles, it looks slightly different. Capgemini's research shows that the connected car services that are most popular with consumers are those related to the "core" functionality of vehicles, such as:

•     safety,  
•     driving comfort,  
•     time saving  
•     reduction of vehicle operating costs.  

Among them, however, the services that are most willingly paid for are:

•     hazard warning,  
•     collision warning,  
•     theft detection systems / vehicle finder.  

Of course, just because entertainment or gamification isn't on the list doesn't mean that automotive companies should avoid them. It's also a way to distinguish and find their own individual voice that corresponds to the broad brand strategy and allows them to stand out in the market. It's about the way they are served, presented to the consumer, and showing that they can actually derive real benefit from them.

It also works the opposite way. Simply creating a "hazard warning" service in a connected car does not immediately guarantee success. It still needs to be packaged properly, run smoothly, and be provided with a payment model that suits the consumer.

Examples of customized connected car services

In-vehicle ads based on navigation and user experience

Is it possible that a driver will like the ads that will be displayed in the car? If we adopt the message to their needs and preferences, in all likelihood, it is. For example, if we often go to McDonald’s, the navigation system can mark such places on our route. We have our favorite clothing brand, right? We will certainly react differently to a sale offer in a shopping mall we just happen to be driving past. The context of shopping and the consumer’s needs are decisive, and the software-defined vehicle is perfectly suited to ensuring that the advertising message is 100% tailored to the driver.

Contextual payments

Removing barriers to shopping and being able to buy everything everywhere is a popular trend in modern commerce. In a vehicle where the driver is focused on the road and has their hands full, such a service makes even more sense. With the development of voice assistants, drivers will be able to pay this way not only for fuel or tolls but also for purchases beyond typical vehicle-related payments. Voice shopping on the way back home from work, instead of looking for a parking space in front of the mall and returning in traffic jams in the evening? Why not?

Sharing information about driver behaviour

Sharing data about the way we drive may not appeal to everyone. But if in return for sharing this information, a company gives us a huge discount on our car insurance or a super attractive leasing offer, then things may take a totally different turn. In cooperation with an insurance company or a bank, such services become a specific bargaining chip the OEM can play with when dealing with the driver.

Manufacturer's connected car applications

Saving money on car maintenance and taking care of the overall condition of the car is a benefit that most drivers will appreciate. A practical and thoughtful manufacturer app that warns of potential breakdowns, component replacements, or servicing will allow the user to enjoy a well-functioning vehicle for longer and sell it at a higher profit. In this way, the OEM gets the driver used to have the vehicle repaired at an authorized service center, and the user, due to the loyalty shown to the brand, can expect future discounts and lucrative offers.

Practical use of telemetry

Sharing telemetry data may seem profitable only to OEMs - after all, as they draw better conclusions based on the collected information and save on R&D processes. However, it is important for companies to make vehicle users aware of the benefits of such services, as well. After all, driving style data can be used to suggest solutions that improve road safety, work on fuel efficiency or reduce overall vehicle operating costs. In each of these cases, the winner is the driver. Example? When a vehicle frequently skids and triggers the ESP/TC system, the system can suggest that the driver should get better tyres (by a specific brand, of course).

Unlocking extra features on the subscription model

Paying for heated seats, just to use them for three months a year, may not be worthwhile for everyone. Well-known to us from streaming portals, the subscription model definitely meets the users’ needs. The customers themselves choose which functionalities they want to pay for and over what period of time. The OEM only has to take care of the right vehicle software that will enable that. And, of course, be careful not to alienate those customers who see this as "yet another" way to squeeze additional payments out of them. That’s how manufacturers can provide both functionalities directly related to the vehicle itself - e.g. better lights or engine boost - as well as those associated with in-car entertainment providers such as Spotify or Apple CarPlay.

What can be done to make the user more eager to pay for data monetization services?

A well-thought-out user experience is essential

In today's digital world, UX and mobile-friendly approaches decide whether a service is viable. If the product is presented in an unclear and incomprehensible way, and it is difficult for the user to find the desired options - they will not use it. The size and color of buttons, the messages displayed, the stability of the application - all of the above is of paramount importance and determine the popularity of the product. Keeping in mind the latest trends, mapping the market, and adapting to consumer trends is necessary to offer the vehicle user service of the quality known to them from e-commerce or their own AppStore.

UX itself is not only a practical tool that helps better track consumer behavior and how they use the service, but also a constant theme to promote and boost brand interest. Does Apple really need to upgrade iOS every year and does Instagram have to offer users a new feed layout every quarter? The answer is obvious. It's simply profitable for the brand.

Start with anonymized data

When creating a strategy for in-vehicle data monetization efforts, it's a good idea to start by developing services that don't require the sharing of personal data. A lower "pain threshold" will make it quicker for the user to learn the benefits of the system and how convenient or useful the service can be. Thus, it will be easier to convince people to use products that require more openness to data sharing. And this may be the next step in the implementation of technological solutions.

Focus on heavy-vehicle users

People who spend most of their day in the car or drive long and demanding routes happily embrace any technical innovations designed to make driving easier and safer for them. It is this group that should be targeted at the beginning of developing your own data monetization model.

Minimizing risks and accurately selecting the group will not solve all challenges, but it will increase the chance of success and help gain a new, loyal group of consumers who will help transfer the technology to other users.

Last, but not least: a flexible payment model

Convenience should accompany the user at every stage of the use of a new service. Not only when it is most beneficial to the user, but also when it is easiest for the user to give it up: whilst paying for the next billing period.

It is worth taking care of the flexibility of the payment model (e.g. one-off payment, freemium model, annual or monthly settlement), adjusting it to the user's needs and not hindering payments.

The smoother and more tailored to the user's needs the whole process of interacting with the service is - from understanding the need to using it to making payments - the greater the chance that the stream of data flowing from a given vehicle will not dry up after a short period of use (read: being frustrated using an underdeveloped product for the first time).

Let's remember that data monetization can succeed provided that it really understands the user, is fair and transparent to them and focuses on user experience. If we didn't have time to get to know the customer's needs, why should they waste their time on services they don't understand and don't need?

 The collection of data and its subsequent monetization  wouldn’t be possible without the ‘’attachment points" in the form of technologies already used in vehicles and controlled parts and systems. It's also common knowledge that car data monetization is based on three main sets of factors, covering quite different areas. These are automotive technologies, infrastructure technologies, and back-end processes. In this article, we are going to reverse-engineer in-car technologies.

There is no harvest without seeds. In relation to vehicles, these "seeds" are all the elements and systems that make data collection possible at all.

The proper design is the key when we talk about the effective use of information from the vehicle and from the users directly. Let's have a closer look at these crucial technologies.

8 technologies necessary to retrieve data from a vehicle

1. Technical sensors

For  OEMs and suppliers , sensors are the foundation on which they can build knowledge about the vehicle's performance and possible breakdowns. Due to that, they are able to see how their products endure the operation.

With these resources, it is much easier to determine the cause of a particular fault. The biggest challenge? The type of setting and frequency of data collection and integration of results into R&D processes. These issues are yet to be discussed.

2. High-performance processing

Real-time processing and communication are pivotal in unlocking the data potential in the vehicle.

However, it is necessary to define, from the very outset, which specific processing elements are to take place in the vehicle and which in the cloud. Whether the hardware is upgradeable is also an important variable.

3. Interface (HMI) and customer ID

HMI is a bridge between a human and a machine. Any technology, tools, and devices allowing human beings to "communicate" with vehicles - request the operation, change the setting or read for example the current status of the engine.

User experience is the key. Making sure the vehicle operations are as intuitive as possible is the end goal of every interior and UI designer. Adding augmented reality, advanced HUD, gesture operations, or fancy ambient lights makes the driver feel at home, capable of quickly changing the vehicle settings, and always aware of the current situation and hazards.

4. Software platforms

They support various vehicle applications and high-speed data transmission protocols. In the context of monetization, two aspects are of paramount importance: the reliability of the  over-the-air software updates and for which of what consumers will be able to pay.

5. Communication

The connection between the vehicle, sensors, internet, and onboard devices is essential. Network gateways include Wi-Fi, Bluetooth, RFID, as well as a high-speed 4G / 5G modem gateway. The latter is the greatest challenge.

The problem that needs to be dealt with is mainly the stability and cost of the aforementioned connection. As the vehicle moves, it can reach locations with low- or even no- mobile internet coverage. This results in interrupted connections, operation retries, or unavailability of services.

6. On-board data storage

It is a local hardware repository for data generated by the vehicle. It must be clear what  data is stored     on the cloud   and who has access to it (e.g. insurers). It is equally important to reassure customers that their information is protected from unauthorized access from outside.

7. Location and navigation technologies

Monetization also depends on location data. The biggest players of software-defined vehicles must decide how to locate a vehicle (GPS) and decide which specific navigation information should be collected and which map's "technical archetype" to adopt.

8. Environmental sensors

It is not only what happens under the vehicle bonnet that matters, but also what influences it. Therefore, environmental factors provide valuable data. They detect parameters related to e.g. road conditions, weather, etc. They also focus on nearby vehicles and people as well as on the cockpit interior: passengers, transported goods, and the driver.

As for the latter, environmental sensors monitor its physiological condition. Based on fingerprint readers, cameras, and microphones, the technology determines, for example, the driver’s sobriety or the degree of fatigue. It is also possible to control vital signs such as heart rate and blood pressure.

To what extent is such data monetized? It all depends on how willing the customer is to share bio information about themselves and their passengers.

Categories of data collected in the vehicle

Which elements, systems, and subsystems are responsible for collecting valuable data that can be monetized  in the automotive industry ? It's time to look at the specific spots in the vehicle that show the greatest potential for data aggregation.

•     Front collision sensor      
     Information about the seriousness of the accident / collision and where it occurred.  
  
•     Doors and windows    
   The condition of the convertible roof, sunroof, doors, windows, bonnet and boot, spoilers and service lap.  
  
•     Driver identification      
     Identifying the person in charge and setting preferential settings for them.  
  
•     Drivers health      
     Pulse, data for diabetics, measuring stress levels.  
  
•     Trip parameters      
     Parameters such as mileage, acceleration / deceleration, remaining range, ECO or SPORT mode activation time, average distance, driving style rating, average fuel consumption, braking intensity and gear behaviour are taken into account.  
  
•     Electric vehicle      
     Battery status and voltage, charging profile and status, power consumption, recovered energy measurement.  
  
•     Engine      
     Ignition status, oil and engine temperature data when we are talking about gasoline/ diesel engine.  
  
•     Fuel      
     Tank capacity and remaining range.  
  
•     General data about the vehicle      
     Information from the display, outside temperature value, VIN number, environment temperature, air conditioning temperature, network connectivity, teleservices availability, vehicle orientation and position.  
  
•     Lights      
     The condition of the headlights and indicators.  
  
•     Liquids      
     Coolant and oil temperature, coolant and oil levels, brake fluid parameters.  
  
•     Navigation and positioning      
     GPS speed, navigation destination, vehicle location (latitude and longitude), time and distance remaining to reach the destination, vehicle alignment, vehicle movement status, most visited places to suggest destinations of travel.  
  
•     Security      
     Technical condition of the seat belts and their fastening, information about airbags.  
  
•     Service and maintenance      
     Date of the next brake fluid inspection and change, time threshold for the main test and exhaust fumes test, ‘check engine’ information.  
  
•     Smartphone      
     Pairing with smartphones, driver behavioural patterns.  
  
•     Warning systems      
     ESP (Electronic Stability Program), ADAS (Advanced Driver Assistance Systems). Data on automatic eCall, battery protection. Messages from sensors (parking, distance, speed).  
  
•     Wheels      
     Tire pressure status, brake pads.

Challenges related to technical possibilities

People responsible for the development and implementation of modern solutions face various challenges. How well they handle them determines the success of monetization.

When analyzing individual systems, you need to take into account such aspects as:

•  the frequency of data collection,
•  the possibility of updating,
•  the improvement of sensors that allow collecting personal data
•  maintaining the stability of connections,
•  identifying entities that have access to collected data.

    Brook. Not a stream yet, though. But in the foreseeable future, it is going to be a proper river. What are we talking about? Data obtained from vehicles. Experts estimate that data inflow is likely to rise from approximately 33 zettabytes (this is how much we obtained in 2018) to 175 zettabytes in 2052. For OEMs and companies from the broadly-defined automotive industry, this means one thing. Endless monetization possibilities. Providing that they face the challenges connected with data capture, filtering and storage, and become familiar with the in-vehicle technologies enabling that.  

The potential is enormous. However, the Capgemini report shows that there is still a long way ahead before reaching its full potential. Today, as many as 44% of OEM customers do not yet avail of any online service in their cars, and still,  connecting to the network is just the starting point because without the Internet there is no option of monetizing data. And even if the vehicle is already connected to the network, only every second driver declares frequent use of this type of service.

Anyway, the condition of the Internet is a challenge in itself. Today, in modern vehicles, there are around 100 points from which information can be downloaded (in the future it is estimated that there will be up to 10,000 of them!)

Before we get to know the technologies that enable it (about which we will write in the second part of the article), let's have a look at the challenges and checkpoints that must be considered when creating a data monetization strategy for a software-defined vehicle.

5 things to bear in mind if you want to monetize vehicle data

1. Developing the customer value proposition

This is where it all begins- from creating a sales offer and an environment in which drivers will believe you have something unique and valuable for them. Without trade, no technology will guarantee your success. Customers will simply not want to share data.

Think about the unique offer you want to present to them and develop a clear data management policy. As a result, it should be followed by the selection of appropriate technologies, and then their implementation in vehicles.

Obtaining data to offer the driver safety or a good sense of direction differs from getting information related to entertainment or directing the customer to a sale in a nearby shopping mall.

It would be perfect if the developed customer value proposition was consistent with your brand's DNA and features that have always been associated with it. This would make it easier to convince users, remain in line with your business assumptions, and stand out from the competition. Focus on technology application, not on technology just to be used.

2. Consider matching technology with the data for which users are most likely to "pay"

Speaking of users’ preferences, even today, at the stage when the technologies of obtaining data from vehicles are not fully-fledged yet, it can be seen that for some services customers are willing to give up some of their privacy, while they are largely opposed or reluctant towards others.

Capgemini's research shows that the group with the greatest potential includes services related to safety and facilitating driving:

•  hazard warning;
•  collision warning;
•  theft detection system;
•  e-call;
•  interactive language assistance.  
  

On the other hand, the greatest objection among users is aroused by services related to broadly -defined shopping:

•  In-car delivery;
•  in car e-commerce.

Keep this in mind when choosing technology to help you monetize your data.

3. Data collector strategy

The data in the vehicle is acquired by means of special sensors and then sent to collectors, which are supposed to gather this data and enable it to be transferred to the cloud. To effectively filter this data and derive maximum benefit from it, you need reliable technology to facilitate it. Due to the huge amount of data and the interaction between various sensors, the universal data collector is the best solution, as it collects all information obtained from sensors in the car.

In order to fully use its potential, during the implementation phase of this technology, it is crucial to ensure close work of the engineering team with people responsible for digital data management (see the next section). Close cooperation of both teams will help to obtain more interesting data and implement new services more efficiently.

4. Provider of IoT data platform

Collecting data from vehicles is impossible without an  IoT platform connected to cloud solutions dedicated to the  automotive industry - this is where data is sent and analyzed to be later collected by the vehicle sensors.

Regardless of which platform you choose (the most popular solutions on the market today are: Microsoft Azure, Amazon AWS, and Otonomo, operating in the SaaS system), 5 features that such a platform should have are of paramount importance to enable the efficient flow of information.

 You can read more about it in     our article on this issue    .

5. Data enrichment

While this article focuses on technologies directly related to obtaining data from the vehicle, it should not be overlooked that the software-defined vehicle operates in a wider ecosystem. Monetization of data from vehicles will not be possible without technologies related to infrastructure (e.g. smart-road infrastructure,  V2X communication , or high-speed data towers), as well as coordination of back-end processes for which entities such as policymaker, cybersecurity specialist, technical regulator, road infrastructure operator or billing/tolling player are accountable.

To create more valuable and attractive services, a coherent policy is necessary, as it will enrich the data stream from third parties and the user themselves, and will improve cooperation between elements of the ecosystem.

Checkpoints inside the car

In-car technologies are not the only gateway for data that companies can obtain from drivers (another entry point may be, for instance, the driver's smartphone or road infrastructure). However, they are the ones over which OEMs and manufacturers have the greatest control, technically at least.

Before we directly describe the technologies in the vehicle allowing that data to be obtained, let's focus on the  checkpoints that are crucial for the capture of information, its quality, and value for building services.

In the software-defined vehicle ecosystem, we can identify three such areas, a kind of bottleneck on which the flow of data depends. These are:

1.     Vehicle interior and infrastructure.  
2.     Connection to cloud.  
3.     Data cloud.  

Let's have a look at the first area, which is practically entirely the responsibility of the automotive company and is directly related to the equipment in the vehicle.

We can list the following groups of such checkpoints which require closer attention when building a data monetization strategy.

1. Gateway to the customer

Key points due to the start of data gathering and the user's experience - their willingness to share data, and thus increasing the value of the gathered data for the manufacturer.

•     HMI    (i.e. a set of technologies enabling the driver to activate the vehicle and begin collecting data, e.g. touch screens, visual sensors, voice commands, etc. - certainly a topic for a separate article)
•     Data gateway    (port, mobile data connection, USB port, radio connection)
•     Customer ID  

2. Points that build loyalty and the need to buy

That is, the contact points with the offer that allow you to easily download new applications, pay bills and influence the user's willingness to renew the service. The more transparent, engaging, and easy-to-use, the more likely the user is to continue their subscription.

•     App store / ecosystem  
•     Billing platform  
•     In-vehicle infotainment (IVI)  
•     Apps/ content  
   

3. Key points for data security, data analysis and usability

•     CPU/ control unit  
•     Car sensors / actuators  

Software-defined vehicles do not run in a vacuum

When creating a data monetization strategy for a software-defined vehicle, one should always bear in mind the wide ecosystem in which such a vehicle operates. It is not enough to equip it with the technology itself and wait for the flow of  data that will turn into specific value for the enterprise . In such a complex and extensive ecosystem, nothing happens by itself. There is no room for improvisation, omitting checkpoints, and presenting half-baked offers. Yes, the technology that downloads data from the vehicle is crucial, but it won't work unless we bear in mind the broader data management context that reaches beyond collecting and analyzing it.

Welcome back to the series. We hope you’ve enjoyed the previous part and you’re back to learn the key points. Today we’re going to show you how to monitor the application.

Monitoring

We would like to have logs and metrics in a single place. Let’s imagine you see something strange on your diagrams, mark it with your mouse, and immediately have proper log entries from this particular timeframe and this particular machine displayed below. Now, let’s make it real.

Some basics first. There is a huge difference between the way Prometheus and Loki get the data. Both of them are being called by Grafana to poll data, but Prometheus also actively calls the application to poll metrics. Loki, instead, just listens, so it needs some extra mechanism to receive logs from applications.

In most sources over the Internet, you’ll find that the best way to send logs to Loki is to use Promtail. This is a small tool, developed by Loki’s authors, which reads log files and sends them entry by entry to remote Loki’s endpoint. But it’s not perfect. Sending multiline logs is still in a bad shape (state for February 2021), some config is really designed to work with Kubernetes only and at the end of the day, this is one more additional application you would need to run inside your Docker image, which can get a little bit dirty. Instead, we propose to use a loki4j logback appender (https://github.com/loki4j). This is a zero-dependency Java library designed to send logs directly from your application.

There is one more Java library needed - Micrometer . We’re going to use it to collect metrics of the application.

So, the proper diagram should look like this.

Which means, we need to build or configure the following pieces:

• slf4j (default configuration is enough)
• Logback
• Loki4j
• Loki
• Micrometer
• Prometheus
• Grafana

Micrometer

Let’s start with metrics first.

There are just three things to do on the application side.

The first one is to add a dependency to the Micrometer with Prometheus integration (registry).

<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

Now, we have a new endpoint exposable from Spring Boot Actuator, so we need to enable it.

management:
endpoints:
web:
exposure:
include: prometheus,health

This is a piece of configuration to add. Make sure you include prometheus in both config server and config clients’ configuration. If you have some Web Security configured, make sure to enable full access to /actuator/health and /actuator/prometheus endpoint.

Now we would like to distinguish applications in our metrics, so we have to add a custom tag in all applications. We propose to add this piece of code as a Java library and import it with Maven.

@Configuration
public class MetricsConfig {

@Bean
MeterRegistryCustomizer<MeterRegistry> configurer(@Value("${spring.application.name}") String applicationName) {
return (registry) -> registry.config().commonTags("application", applicationName);
}

}

Make sure you have spring.application.name configured in all bootstrap.yml files in config clients and application.yml in the config server.

Prometheus

The next step is to use a brand new /actuator/prometheus endpoint to read metrics in Prometheus.

The ECS configuration is similar to backend services. The image you need to push to your ECR should look like that.

FROM prom/prometheus

COPY prometheus.yml .

ENTRYPOINT prometheus --config.file=prometheus.yml
EXPOSE 9090

As Prometheus doesn’t support HTTPS endpoints, it’s just a temporary solution, and we’ll change it later.

The prometheus.yml file contains such a configuration.

scrape_configs:
- job_name: 'cloud-config-server'
metrics_path: '/actuator/prometheus'
scrape_interval: 5s
dns_sd_configs:
- names:
- '$cloud_config_server_url'
type: 'A'
port: 8888
- job_name: 'foo'
metrics_path: '/actuator/prometheus'
scrape_interval: 5s
dns_sd_configs:
- names:
- '$foo_url
type: 'A'
port: 8080
- job_name: bar
metrics_path: '/actuator/prometheus'
scrape_interval: 5s
dns_sd_configs:
- names:
- '$bar_url
type: 'A'
port: 8080
- job_name: 'backend_1'
metrics_path: '/actuator/prometheus'
scrape_interval: 5s
dns_sd_configs:
- names:
- '$backend_1_url
type: 'A'
port: 8080
- job_name: 'backend_2'
metrics_path: '/actuator/prometheus'
scrape_interval: 5s
dns_sd_configs:
- names:
- '$backend_2_url
type: 'A'
port: 8080

Let’s analyse the first job as an example.

We would like to call '$cloud_config_server_url' url with '/actuator/prometheus' relative path on a port 8080 . As we’ve used dns_sd_configs and type: 'A', the Prometheus can handle multivalue DNS answers from the Service Discovery, to analyze all tasks in each service. Please make sure you replace all ' $x' variables in the file with proper URLs from the Service Discovery.

The Prometheus isn’t exposed to the public load balancer, so you cannot verify your success so far. You can expose it temporarily or wait for Grafana.

Logback and Loki4j

If you use the Spring Boot, you probably already have spring-boot-starter-logging

library included. Therefore, you use logback as the default slf4j integration. Our job now is to configure it to send logs to Loki. Let’s start with the dependency:

<dependency>
<groupId>com.github.loki4j</groupId>
<artifactId>loki-logback-appender</artifactId>
<version>1.1.0</version>
</dependency>

Now let’s configure it. The first file is called logback-spring.xml and located in the config server next to the application.yml (1) file.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

<property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger - %msg%n"/>

<appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>${LOG_PATTERN}</pattern>
</encoder>
</appender>
<springProfile name="aws">
<appender name="Loki" class="com.github.loki4j.logback.Loki4jAppender">
<http>
<url>${LOKI_URL}/loki/api/v1/push</url>
</http>
<format class="com.github.loki4j.logback.ProtobufEncoder">
<label>
<pattern>application=spring-cloud-config-server,instance=${INSTANCE},level=%level</pattern>
</label>
<message>
<pattern>${LOG_PATTERN}</pattern>
</message>
<sortByTime>true</sortByTime>
</format>
</appender>
</springProfile>

<root level="INFO">
<appender-ref ref="Console"/>
<springProfile name="aws">
<appender-ref ref="Loki"/>
</springProfile>
</root>
</configuration>

What do we have here? There are two appenders with the common pattern, and one root logger. So we start with pattern configuration <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger - %msg%n"/> . Of course you can configure it, as you want.

Then, the standard console appender. As you can see, it uses the LOG_PATTERN .

Then you can see the com.github.loki4j.logback.Loki4jAppender appender. This way the library is being used. We’ve used < springProfile name="aws" > profile filter to enable it only in the AWS infrastructure and disable locally. We use the same when using the appender with appender-ref ref="Loki" . Please note the label pattern, used here to label each log with custom tags (application, instance, level). Another important part here is Loki’s URL. We need to provide it as an environment variable for the ECS task. To do that, you need to add one more line to your aws_ecs_task_definition configuration in terraform.

"environment" : [
...
{ "name" : "LOKI_URL", "value" : "loki.internal" }
],

As you can see, we defined “loki.internal” URL and we’re going to create it in a minute.

There are few issues with logback configuration for the config clients.

First of all, you need to provide the same LOKI_URL environment variable to each client, because you need Loki before reading config from the config server.

Now, let’s put another logback-spring.xml file in the config server next to the applic ation.yml (2) file.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger - %msg%n"/>
<springProperty scope="context" name="APPLICATION_NAME" source="spring.application.name"/>

<appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>\${LOG_PATTERN}</pattern>
</encoder>
</appender>
<springProfile name="aws">
<appender name="Loki" class="com.github.loki4j.logback.Loki4jAppender">
<http>
<requestTimeoutMs>15000</requestTimeoutMs>
<url>\${LOKI_URL}/loki/api/v1/push</url>
</http>
<format class="com.github.loki4j.logback.ProtobufEncoder">
<label>
<pattern>application=\${APPLICATION_NAME},instance=\${INSTANCE},level=%level</pattern>
</label>
<message>
<pattern>\${LOG_PATTERN}</pattern>
</message>
<sortByTime>true</sortByTime>
</format>
</appender>
</springProfile>

<root level="INFO">
<appender-ref ref="Console"/>
<springProfile name="aws"><appender-ref ref="Loki"/></springProfile>
</root>
</configuration>

The first change to notice are slashes before environment variables (eg. \${LOG_PATTERN } ). We need it to tell the config server not to resolve variables on it’s side (because it’s impossible). The next difference is a new variable <springProperty scope="context" name="APPLICATION_NAME" source="spring.application.name"/> . with this line and spring.application.name in all your applications each log will be tagged with a different name. There is also a trick with the ${INSTANCE} variable. As Prometheus uses IP address + port as an instance identifier and we want to use the same here, we need to provide this data to each instance separately.

So your Dockerfile files for your applications should have something like that.

FROM openjdk:15.0.1-slim

COPY /target/foo-0.0.1-SNAPSHOT.jar .

ENTRYPOINT INSTANCE=$(hostname -i):8080 java -jar foo-0.0.1-SNAPSHOT.jar
EXPOSE 8080

Also, to make it working, you are supposed to tell your clients to use this configuration. Just add this to bootstrap.yml files in all you config clients.

logging:
config: ${SPRING_CLOUD_CONFIG_SERVER:http://localhost:8888}/application/default/main/logback-spring.xml
spring:
application:
name: foo

That’s it, let’s move to the next part.

Loki

Creating Loki is very similar to Prometheus. Your dockerfile is as follows.

FROM grafana/loki
COPY loki.yml .
ENTRYPOINT loki --config.file=loki.yml
EXPOSE 3100

The good news is, you don’t need to set any URLs here - Loki doesn’t send any data. It just listens.

As a configuration, you can use a file from https://grafana.com/docs/loki/latest/configuration/examples/ . We’re going to adjust it later, but it’s enough for now.

Grafana

Now, we’re ready to put things together.

In the ECS configuration, you can remove service discovery stuff and add a load balancer, because Grafana will be visible over the internet. Please remember, it’s exposed at port 3000 by default.

Your Grafana Dockerfile should be like that.

FROM grafana/grafana
COPY loki_datasource.yml /etc/grafana/provisioning/datasources/
COPY prometheus_datasource.yml /etc/grafana/provisioning/datasources/
COPY dashboad.yml /etc/grafana/provisioning/dashboards/
COPY *.json /etc/grafana/provisioning/dashboards/
ENTRYPOINT [ "/run.sh" ]
EXPOSE 3000

Let’s check configuration files now.

loki_datasource.yml:

apiVersion: 1

datasources:
- name: Loki
type: loki
access: proxy
url: http://$loki_url:3100
jsonData:
maxLines: 1000

I believe the file content is quite obvious (we'll return here later).

prometheus_datasource.yml:

apiVersion: 1

datasources:
- name: prometheus
type: prometheus
access: proxy
orgId: 1
url: https://$prometheus_url:9090
isDefault: true
version: 1
editable: false

dashboard.yml:

apiVersion: 1

providers:
- name: 'Default'
folder: 'Services'
options:
path: /etc/grafana/provisioning/dashboards

With this file, you tell Grafana to install all json files from /etc/grafana/provisioning/dashboards directory as dashboards.

The last leg is to create some dashboards. You can, for example, download a dashboard from https://grafana.com/grafana/dashboards/10280 and replace ${DS_PROMETHEUS} datasource with your name “prometheus”.

Our aim was to create a dashboard with metrics and logs at the same screen. You can play with dashboards as you want, but take this as an example.

{
"annotations": {
"list": [
{
"builtIn": 1,
"datasource": "-- Grafana --",
"enable": true,
"hide": true,
"iconColor": "rgba(0, 211, 255, 1)",
"name": "Annotations & Alerts",
"type": "dashboard"
}
]
},
"editable": true,
"gnetId": null,
"graphTooltip": 0,
"id": 2,
"iteration": 1613558886505,
"links": [],
"panels": [
{
"aliasColors": {},
"bars": false,
"dashLength": 10,
"dashes": false,
"datasource": null,
"fieldConfig": {
"defaults": {
"custom": {}
},
"overrides": []
},
"fill": 1,
"fillGradient": 0,
"gridPos": {
"h": 8,
"w": 24,
"x": 0,
"y": 0
},
"hiddenSeries": false,
"id": 4,
"legend": {
"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 1,
"nullPointMode": "null",
"options": {
"alertThreshold": true
},
"percentage": false,
"pluginVersion": "7.4.1",
"pointradius": 2,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"spaceLength": 10,
"stack": false,
"steppedLine": false,
"targets": [
{
"expr": "system_load_average_1m{instance=~\"$instance\", application=\"$application\"}",
"interval": "",
"legendFormat": "",
"refId": "A"
}
],
"thresholds": [],
"timeRegions": [],
"title": "Panel Title",
"tooltip": {
"shared": true,
"sort": 0,
"value_type": "individual"
},
"type": "graph",
"xaxis": {
"buckets": null,
"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{
"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{
"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
],
"yaxis": {
"align": false,
"alignLevel": null
}
},
{
"datasource": "Loki",
"fieldConfig": {
"defaults": {
"custom": {}
},
"overrides": []
},
"gridPos": {
"h": 33,
"w": 24,
"x": 0,
"y": 8
},
"id": 2,
"options": {
"showLabels": false,
"showTime": false,
"sortOrder": "Ascending",
"wrapLogMessage": true
},
"pluginVersion": "7.3.7",
"targets": [
{
"expr": "{application=\"$application\", instance=~\"$instance\", level=~\"$level\"}",
"hide": false,
"legendFormat": "",
"refId": "A"
}
],
"timeFrom": null,
"timeShift": null,
"title": "Logs",
"type": "logs"
}
],
"schemaVersion": 27,
"style": "dark",
"tags": [],
"templating": {
"list": [
{
"allValue": null,
"current": {
"selected": false,
"text": "foo",
"value": "foo"
},
"datasource": "prometheus",
"definition": "label_values(application)",
"description": null,
"error": null,
"hide": 0,
"includeAll": false,
"label": "Application",
"multi": false,
"name": "application",
"options": [],
"query": {
"query": "label_values(application)",
"refId": "prometheus-application-Variable-Query"
},
"refresh": 2,
"regex": "",
"skipUrlSync": false,
"sort": 0,
"tagValuesQuery": "",
"tags": [],
"tagsQuery": "",
"type": "query",
"useTags": false
},
{
"allValue": null,
"current": {
"selected": false,
"text": "All",
"value": "$__all"
},
"datasource": "prometheus",
"definition": "label_values(jvm_classes_loaded_classes{application=\"$application\"}, instance)",
"description": null,
"error": null,
"hide": 0,
"includeAll": true,
"label": "Instance",
"multi": false,
"name": "instance",
"options": [],
"query": {
"query": "label_values(jvm_classes_loaded_classes{application=\"$application\"}, instance)",
"refId": "prometheus-instance-Variable-Query"
},
"refresh": 2,
"regex": "",
"skipUrlSync": false,
"sort": 0,
"tagValuesQuery": "",
"tags": [],
"tagsQuery": "",
"type": "query",
"useTags": false
},
{
"allValue": null,
"current": {
"selected": false,
"text": [
"All"
],
"value": [
"$__all"
]
},
"datasource": "Loki",
"definition": "label_values(level)",
"description": null,
"error": null,
"hide": 0,
"includeAll": true,
"label": "Level",
"multi": true,
"name": "level",
"options": [
{
"selected": true,
"text": "All",
"value": "$__all"
},
{
"selected": false,
"text": "ERROR",
"value": "ERROR"
},
{
"selected": false,
"text": "INFO",
"value": "INFO"
},
{
"selected": false,
"text": "WARN",
"value": "WARN"
}
],
"query": "label_values(level)",
"refresh": 0,
"regex": "",
"skipUrlSync": false,
"sort": 0,
"tagValuesQuery": "",
"tags": [],
"tagsQuery": "",
"type": "query",
"useTags": false
}
]
},
"time": {
"from": "now-24h",
"to": "now"
},
"timepicker": {},
"timezone": "",
"title": "Logs",
"uid": "66Yn-8YMz",
"version": 1
}

We don’t recommend playing with such files manually when you can use a very convenient UI and export a json file later on. Anyway, the listing above is a good place to start. Please note the following elements:

In variable’s definitions, we use Prometheus only, because Loki doesn’t expose any metric so you cannot filter one variable (instance) when another one (application) is selected.

Because we would like to sometimes see all instances or log levels together, we need to query data like here: {application=\"$application\", instance=~\"$instance\", level=~\"$level \"}" . The important element is a tilde in instance=~\"$instance\" and level=~\"$level\" , which allows us to use multiple values.

Conclusion

Congratulation! You have your application monitored. We hope you like it! But please remember - it’s not production-ready yet! In the last part, we’re going to cover a security issue - add encryption at transit to all components.

Enterprises know that the future of their software is in the cloud. Despite keeping that in mind, many tech leaders delay the process of transforming their core legacy systems. How will the situation change with Kubernetes supporting Windows workloads? Can we assume that companies will leverage the Kubernetes upgrade to accelerate their journey towards the cloud?

 How can this article help you?

•     You can see what Kubernetes supporting Windows workloads provides for enterprises.  
•     We remind you why going to the cloud is crucial for your business excellence.  
•     You can get to know the main reason stopping enterprises from transforming their legacy systems.  
•     We describe the main risks that come with delaying the transition towards the cloud.  
•     You learn how to leverage Kubernetes supporting Windows workloads.  

Technical debt is an unpleasant legacy you often come into money while taking charges of critical systems or enterprise software older than you. Laying under the cache layer and various interfaces, legacy systems encourage you to forget them. And you are good with it - you have enough tasks to perform and things to manage on a daily basis. Sprint after sprint, your team deals with developing applications and particular features to meet increasing customer demand and sophisticated needs. Initiating a tremendous venture, which may transform into opening Pandora's box, it's not exactly what you want to add to your checklist.

The bad news is that if you're willing to be successful at your job, the clock is ticking. The problem with legacy systems is that you don't know when they break down, causing disaster. You will justify yourself, but the impact on your work will be nightmarish. What you know for sure, legacy systems under applications built by your talented teams hinder further development and make your job harder than it already is.

Whatever you are going to go for it all or don't want to throw yourself in at the deep end - Kubernetes supporting Windows workloads is the news you needed. See how it can accelerate your transition towards the cloud.

What's the deal with Kubernetes supporting Windows workloads

 Kubernetes was designed to run Linux containers. Such an approach complicated the transition towards the cloud for enterprises with Windows Server legacy systems. And while over 70% of the global server market is Windows-based (according to Statista), we can see why so many legacy apps are in the closets. If you work at a large enterprise, the chances that you have a few of them hidden carefully are very high.

How supporting Windows workloads by Kubernetes is changing the game? In the - not so much - olden days, Windows-based applications were immovable - they needed to be run on Windows, required Windows server, and access to numerous related databases and libraries. Such a demanding environment encouraged enterprises to wait for better days. And now they have come. Kubernetes, with production support for scheduling Windows containers on Windows nodes in the platform cluster, allows for running these Windows applications, enabling enterprises to modernize and move their apps to the cloud.

It’s believed that with this release, Kubernetes provides enterprises with the opportunity  to accelerate their DevOps and cloud transformation . In case you missed 1 mln publications about cloud advantages, we will write up the main points.

Why do enterprises move their legacy applications to the cloud

As promised above, let’s keep it short:

•     Scalability    - the cloud allows you to easily manage your IT resources, data storage capacity, computing power, and networking (in both ways) without downtimes or other disruptions. Such flexibility supports business growth, product/service development, and better cost management.
•     Security    - the right set of strategies and policies allow enterprises to build and manage secure cloud environments. Decentralization and support for your cloud stack provide solutions to common challenges in maintaining on-premise infrastructure.
•     Maintenance    - using cloud services delivered by trusted providers, you don't have to maintain many things on your own, just leveraging available services.
•     Accessibility    - the pandemic showed us how crucial is remote access to our IT resources, and the cloud provides your remote or distributed teams with easy access regardless of your team members' localization - that is priceless.
•     Reliability    - cloud providers ensure easier and cheaper data backups, disaster recovery, and business continuity as they use the economy at scale.
•     Performance    - as the cloud service market is blooming and service providers are competing about increasing revenues, the quality and performance of cloud infrastructure are top-notch.
•     Cost-effectiveness    - with cloud computing, your enterprise can cut off numerous spendings from your books - including infrastructure, electricity, and IT experts responsible for managing resources.
•     Agility    - forget about capacity planning while your computing provisioning can be done within a few clicks leveraging self-service.

Sounds convincing? If everything is obvious, why are there still so many legacy apps?

Why do enterprises delay with moving apps to the cloud

Legacy systems are long-time friends with procrastination. If you are long enough in this business, you have definitely heard a few of these excuses:

•  We cannot do it now. We have too many things on the list. A better day will come.
•  It’s risky. It’s critically risky. Why do you even ask? Do you want to see the world burning?
•  Ok, let’s do it! But wait….who knows how to do it?
•  We can cover it with our UI or cache layer, and nobody will ever notice.
•  It’s our core system. You touch it, everything will go bad.
•  Why change it if it works well?
•  It’s a too huge project for me to decide and take responsibility for the never-ending process.

These are some examples from the top of the iceberg. Diving into  the process of moving legacy apps to the cloud , you can stumble upon numerous points convincing you to stay out of them. But can it last forever? What if the “zero hour” strikes?

Playing a risky game: what can happen if you don’t migrate to the cloud

Many of our business challenges wouldn’t have existed if we, at some point, tackled the underestimated issues. The excuses highlighted above can convince you to leave things as they are. But what if your real problems are just ahead of you? Let’s name some threats that may occur at enterprises that delay transition towards the cloud.

•  Maintaining legacy systems becomes more expensive with time as your company has to pay for computing power supporting these solutions.
•  Your enterprise may face a huge challenge to find experts understanding your legacy systems. The longer you postpone the process, the harder it will be to look for people working with frameworks and tools that are outdated.
•  By allowing for increasing your technical debt, your enterprise acts against your willingness for innovation. Your legacy systems suppress the development of new products and services, undermining your competitive advantage.
•  You can face a challenge to provide services to your customers because of downtimes and distractions caused by inefficient systems.
•  Technology develops fast. Legacy systems stop you from participating in the movement and may generate new issues in the future, especially in the time you will need to be flexible.
•  Most established enterprises work on highly regulated markets and have to meet challenging conditions. One of our business partners had to rebuild one of its core systems because of new regulations regarding data management. Such a situation can lead to enormous costs.
•  There appears a serious security threat as legacy systems are prone to attacks, and without upgrades, your system may become insecure.

The list above can be expanded to many additional issues. But instead of describing challenges, let’s discuss  how they can be addressed using Kubernetes .

How to leverage Kubernetes supporting Windows workloads

There is a ton of code written on Windows. With the Kubernetes update, you don’t have to think about rebuilding your applications from scratch, so myriads of working hours spent by your team are secured. Most of the code can be moved to the Kubernetes container and there developed. It’s safer and cheaper.

Kubernetes supporting Windows workloads gives you time to navigate your journey to the cloud properly. First of all, it ends the discussion for all those excuses mentioned above. The moment is now. Secondly, you can now utilize an evolutionary approach by developing and upgrading your systems instead of building them from ground zero. Furthermore, with your key legacy systems moved to the cloud, you can accelerate the overall transformation at your enterprise towards an agile, DevOps-oriented organization open to innovation and developing highly competitive software.

What should be your next move?

By supporting Windows workloads, Kubernetes makes the life of many tech teams easier. But it would be too easy if everything worked by itself. Configuration of the Kubernetes cluster to utilize Windows workloads is demanding and time-consuming. Instead of doing it on your own, you can leverage the ready-to-use solution provided by Grape Up.  Cloudboostr , our Kubernetes stack, enables you to move your Windows-based apps to the cloud. Consult our expert on how to do it properly!

Digital Twin is a widely spread concept of creating a virtual representation of object state. The object may be small, like a raindrop, or huge as a factory. The goal is to simplify the operations on the object by creating a set of plain interfaces and limiting the amount of stored information. With a simple interface, the object can be easily manipulated and observed, while the state of its physical reflection is adjusted accordingly.

In  the automotive and aerospace industries , this is a common approach to use virtual objects representation to design, develop, test, manufacture, and operate both parts of a vehicle, like an engine, drivetrain, chassis/fuselage, or a full vehicle – a whole car, motorcycle, truck or aircraft. Virtual representations are easier to experiment with, especially on a bigger scale, and to operate - especially in situations when connectivity between a vehicle and the cloud is not stable ability to query the state anyway is vital to provide a smooth user experience.

It’s not always critical to replicate the object with all details. For some use cases, like airflow modeling for calculating drag force, mainly exterior parts are important. For computer vision AI simulation, on the other hand, user checking if the doors and windows are locked only requires a boolean true/false state. And to simulate the combustion process in the engine, even the vehicle type is not important.

Today,  artificial intelligence takes a significant role in a lot of car systems, to name a few: driver assistance, fatigue check, predictive maintenance, emergency braking, and collision avoidance, speed limit recognition, and prediction. Most of those systems do not live in a void - to operate correctly they require information about the surrounding world gathered through V2X connections, cameras, radars, lidars, GPS position, thermometers, or ABS/ESP sensors.

Let’s take Adaptive Cruise Control (ACC). The vehicle is kept in lane using computer vision and a front-facing camera. The distance to surrounding vehicles and obstacles is calculated using both a camera and a radar/lidar. Position on the map is gathered using GPS, and the speed limit is jointly calculated using the navigation system, road sign recognition, and distance to the vehicle ahead. This is an example of a complex system, which is hard to test - all parts of it have to be simulated separately, for example, by injecting a fake GPS path. Visualizing this kind of test system is complicated, and it’s hard to use data gathered from the car to reproduce the failure scenarios.

Here the Virtual World comes to help. The virtual world is an extension of the vehicle shadow concept where the multiple types of digital twins coexist in the same environment knowing their presence and interfaces. The system is composed of digital representation of physical assets whenever possible – including elements recognized via computer vision. Vehicles, road infrastructure, positioning systems, or even pedestrians are part of the virtual world. All vehicles are part of the same environment meaning they can share the data regarding the position of other traffic participants.

•  Such a system provides multiple benefits: Improved accuracy of assistance systems, as the recognized infrastructure and traffic participants can come from other vehicles, and their position can be estimated even when they are still outside the range of sensors.
•  Easier, more robust communication between infrastructure, vehicles, pedestrians, and cloud APIs as everything remains in the same digital system.
•  Possibility to fully reproduce conditions of system failure as the state history of not just vehicle, but all of its surrounding remains in cloud and can be used to recreate and visualize the area.
•  Ability to enhance existing systems leveraging data from the greater area - for example, immediately notifying about an obstacle on the road in 500 meters and suggestion to reduce speed.
•  The extensive information set can be used to build new AI/ML applications, like real-time weather information (rain sensor) can be built to close sunroofs of vehicles parked in the area.
•  The same system can be used to better simulate its behavior, even using data from real vehicles.
•  Common interfaces allow for quicker implementation.

Obviously, there are also challenges - the amount of data to be stored is huge, so it should be heavily optimized, and storage has to be highly scalable. There is also an impact of  the connection between the car and the cloud . Overall, the advantages overweight the disadvantages, and the Virtual World will be a common pattern in the next years with the growing  implementation of software-defined vehicles and machine learning applications requiring more and more data to improve its operations.

We're connected. There’s no doubt about it. At work, at home, in town, on holidays. Our life is no longer divided into offline and online, digital and analog. Our life is somewhere in between, and it happens in both worlds at once. Also in our car, where we expect access to data, instant updates, entertainment, and understanding of our needs. The proven IoT SaaS platform makes this much easier.  Today choosing this option is crucial for every company in the automotive industry. Without it, the connected vehicle wouldn’t exist.

    What you will learn from this article:  

•     Why an automotive company needs cloud services and how to build new business value on them  
•     What features an IoT platform for the automotive industry should have  
•     What cloud solutions are chosen by the largest producers  

Before our very eyes, the car is becoming part of the Internet of Things ecosystem. We want safer driving and 'being led by the hand', ease of integration with external digital services like music streaming, automatic parking payments, or real-time traffic alerts, and the transfer of virtual experiences from one tool to another (including the car).

The vehicles we drive have become more service-oriented, which not only creates new options and  business opportunities for companies from the automotive sector but also poses potential threats.

A hacking attack on a phone may result in money loss or compromising the user, whereas an attack on a car can have much more serious consequences. This is why choosing  the platform for a connected vehicle is crucial.

 Let's have a look at the basic assumptions that such a platform should meet. Let's get to know the main service providers and market use cases influencing the choice of the largest brands in the automotive industry.

5 must-haves for every IoT SaaS platform

1. Security

At the heart of the Internet of Things is data. However, no one will share it unless the system guarantees an appropriate level of security and privacy. Access authorization is meant for selected users and platforms only. Authentication is geared to prevent unwanted third-party devices from connecting to the vehicle. Finally, there is also an option of blocking devices reaching their limits of usage or ones that have become unsafe. These types of elements that make up the security of the platform are a necessary condition to consider the implementation of the platform in your own vehicle fleet.

2. Data

The connected vehicle continuously receives and sends data. The vehicle communicates not only with other moving vehicles but also with the city and road infrastructure and third-party platforms. Data management, storage, and analysis are the gist of the entire IoT ecosystem. For everything to run smoothly and in line with security protocols, devices need to get data directly from your IoT platform, not from devices. Only in this way will you get a bigger picture of the whole, plus the option of comprehensive analysis- hence the possibility of  monetization and obtaining additional business value .

3. Analytics

Once we have the guarantee that the data is safe and obtained from the right sources, we can start analyzing it. A good IoT platform allows it to be analyzed in real-time, but also in relation to past events. It also allows you to predict events before they happen - for example, it will warn the user about replacing a specific component before it breaks down. It is important that the platform collects and analyses data from the entire spectrum of events. Only in this way can it create a comprehensive picture of the real situation.

4. Integrations

The number of third-party platforms that the driver can connect to their car will continue to increase. You have to be prepared for this and choose a solution that will be able to evolve along with market changes. The openness of the system (combined with its security) will keep you going and expand your potential monetization possibilities.

When the system is shut down, you may have to replace some devices or make constant programming changes to communication protocols in the near future.

5. Reports

With this amount of data, since thousands or even hundreds of thousands of vehicles can be pinned to the platform - transparent data reporting becomes necessary. Some of the information may be irrelevant, some will gain significance only in combination with others, some will be more or less important for your business (different aspects will be pointed out by a company operating in the area of ​​  shared mobility , as opposed to a company managing a lorry fleet).

Your IoT platform must enable you to easily access, select and present key information in a way that will be clear to each employee, not business intelligence experts only.

We need data to draw constructive business conclusions, not to be bombarded with useless information.

Top market solutions - use cases of the biggest automotive brands

All right. So what solution should you opt for? There is no one, obvious answer to this question. It all depends on your individual needs, the scale of the business, and the cooperation model that is key for you.

You can focus on larger market players and scalable solutions - e.g. the  Microsoft Azure platform or  AWS by Amazon or on services in the SaaS model provided e.g. by players such as Otonomo, Octo, Bosch, or Ericsson.

Microsoft Azure x Volkswagen

The Azure platform, created by the technological giant from Redmond, has been known to developers and cloud architects for a long time. No wonder that it is often used by the most famous brands in the automotive industry. Microsoft is supported by the scale of its projects, excellent understanding of cloud technologies, and experience in creating solutions dedicated to the world's largest brands.

In 2020, based on these solutions,  Volkswagen implemented its own Automotive Cloud platform (by its subsidiary - CARIAD, previously called CarSoftware.org.)

Powered by Microsoft Azure cloud and IoT Edge solutions, the platform will support the operation of over 5 million new Volkswagens every year. The company also plans to transfer technology to other vehicles from the group in all regions of the world, and by doing this, laying the foundations for customer-centric services.

As the brand writes in its press release, the platform is focused on  „providing new services and solutions, such as in-car consumer experiences, telematics, and the ability to securely connect data between the car and the cloud.”

For this purpose, Volkswagen has also created a dedicated consumer platform - Volkswagen We, where car users will find smart mobility services and connectivity apps for their vehicles.

AWS x Ford and Lyft

Over 13 years on the market and  „165 fully featured services for computing, storage, databases, networking, analytics, robotics, machine learning and artificial intelligence (AI), Internet of Things (IoT), mobile, security, hybrid, virtual and augmented reality (VR and AR), media….” support AWS, or the Amazon cloud solutions.

For people from the automotive industry, a great advantage is a huge brand community and an extensive ecosystem of other services such as movie streaming (Prime Video), voice control (Alexa), or shopping in Amazon Go stores, which can create new business opportunities for companies providing automotive solutions.

The Amazon platform was selected, among others, by the  Ford Motor Company (in cooperation with Transportation Mobility Cloud), and by  Lyft in the shared mobility sector.

Ford and creators of the Transportation Mobility Cloud (TMC) Autonomic justified the choice of that solution as follows: [we choose]  „AWS for its global availability, and the breadth and depth of AWS’ portfolio of services, including Internet of Things (IoT), machine learning, analytics, and compute services”. The collaboration with Amazon is intended to help the brands expand the availability of cloud connectivity services and connected car application development services for the transportation industry”.

Based on the Amazon DynamoDB (NoSQL database) service, Lyft chose Amazon services to be able to easily track users’ journeys, precisely calculate routes and manage the scale of the process during the communication peak, holidays, and days off.

Chris Lambert, CTO at Lyft, commented on the brand's choice:  „By operating on AWS, we are able to scale and innovate quickly to provide new features and improvements to our services and deliver exceptional transportation experiences to our growing community of Lyft riders. […] we don’t have to focus on the undifferentiated heavy lifting of managing our infrastructure, and can concentrate instead on developing and improving services with the goal of providing the best transportation experiences for riders and drivers, and take advantage of the opportunity for Lyft to develop best-in-class self-driving technology.”

BMW & MINI x Otonomo

Transforming data to revolutionize driving and transportation. Otonomo, the IoT platform operating in the SaaS model, using this slogan is trying to convince the automotive industry to avail of its services.

Among its customers, BMW and belonging to the same MINI group are particularly noteworthy. The vehicles have been connected to the platform in 44 countries and are intended to provide additional information for road traffic, smart cities, and improve the overall driving experience.

Among the data to be collected by the vehicles, the manufacturer mentions information on the availability of parking lots, traffic congestion, and traffic itself in terms of city planning, real-time traffic intelligence, local hazard warning services, mapping services, and municipal maintenance and road optimization.

Volvo x Ericsson Connected Vehicle Cloud

Partnerships with telecommunications companies are also a common business model in creating cloud services for vehicles. This kind of cooperation was chosen by Volvo, e.g. whilst working with Ericsson. Anyway, this cooperation dates back to 2012 and is constantly being expanded.

Connected Vehicle Cloud (CVC) platform, as its producer named it, allows Volvo to  „deliver scalably, secured, high-quality digital capabilities, including a full suite of automation, telematics, infotainment, navigation, and fleet management services to its vehicles. All software is able to be supported and seamlessly updated over-the-air (OTA) through the Ericsson CVC”.

Mazda x KDDI & Orange IoT

In 2020, connected car services also made their debut in  Mazda, specifically the MX-30 model. Like the Swedish vehicle manufacturer, a local technology partner was also selected here. It was KDDI, the Japanese telecommunications tycoon. (Orange became a partner for the European market).

With Mazda's connection to the IoT cloud, the MyMazda App has also been developed. The manufacturer boasts that in this way they introduced a package of integrated services,  "which will remove barriers between the car and the driver and provide a unique experience in using the vehicle". The IoT platform itself is geared to offer drivers a higher level of safety and comfort.

What counts is the specifics of your industry and flexibility of the platform

Regardless of which solution you choose, remember that security and data management are an absolute priority of any IoT platform. There is no one proven model because the  automotive industry also has completely different vehicles, goals, and fleet scales.

Identify your key needs and make your final choice based on them. The IoT platform should be adjusted to your business, not the other way round. Otherwise, you will be in for constant software updates and potential problems with data management and its smooth monetization.