Software is eating up cars! When digitalization and intelligence gradually penetrate the car, it also brings many technical challenges to traditional car companies. In this context, the authors of this paper conduct in-depth research on the many characteristics of cloud-side collaboration and the Internet of Vehicles, and conduct in-depth car-cloud practice based on microservices and containerization.
Author | Jiang Biao Wang Han Zhao Wei Responsible Editor | Tang Xiaoyin
Produced by | new programmer
Challenges faced by traditional car companies in the Internet of Vehicles
In recent years, with the rapid development of modern technologies and innovative ecosystems such as big data, new energy, intelligent networking, and automatic driving in the automotive industry, the connection between automobiles and people's daily lives is becoming more and more close. How to achieve the business goal of "product-centric" to "user-centric", how to quickly respond, explore, excavate and lead the needs of users, how to form contact points with users, understand users, and communicate effectively with users are the fundamental footholds of the digital transformation of traditional car companies. In the face of the impact of new things, new technologies and new ideas, the transformation of traditional car companies to digitalization, intelligence and networking is imminent, but in this process, it is also facing many technical challenges.
First of all, how to accelerate the data integration of enterprise retail, technology, production, quality and other departments, connect the "data islands" of various business areas, establish a unified data view, and ensure data sharing at the enterprise level to the greatest extent?
Second, how to achieve intelligent networking? Cloud-side collaboration is key. Between the cloud and the vehicle, edge computing needs to be used to solve the collaboration of distributed infrastructure resources, computing resources, security policies, data policies, and application management. However, according to Academician Yao Jianquan (Academician of the Chinese Academy of Sciences) in his report "Preliminary Study on the Scientific Problems of Edge Computing Theory" in December 2020, there are still two aspects of edge computing that need to be implemented urgently, one is the decoupling of software and hardware similar to PC, the decoupling of data planes and control planes in SDN (software-defined networking), and the decoupling of cloud and data centers, so as to achieve dynamic adaptive support for the convergence of edge virtualization of various granularities, and the realization of network surfaces on edge hardware. The full integration of data surface and business surface is emphasized; the second is to emphasize the unification of edge technology stacks in heterogeneous scenarios, study general software and hardware technologies, and fully realize the edge fusion of IT (Internet Technology, Internet technology) - CT (Communication Technology, communication technology) - OT (Operational Technology, operational technology).
Third, in addition to the large amount of data, many types, low value density and fast speed of the Internet of Vehicles, the data characteristics of the Internet of Vehicles are professional, relevant and time-series. How to achieve the effective utilization and elastic expansion of storage resources in the cloud, and realize the separation of heat and cold and data disaster recovery of industrial big data? This is a problem that car companies need to consider in the design and implementation of cloud services.
Finally, traditional car companies lack rational cognition of cloud computing, and lack of experience in cloud design and data center construction. Under the scenario of mixed public and private clouds of multi-cloud service providers, how to establish a unified cloud security policy and defense measures? How to centrally control the consistency of cloud applications and block the heterogeneity of cloud IaaS and PaaS? How to balance the computing advantages of public cloud resources with the security advantages of private clouds, and rationally plan the storage and migration of data resources?
Ford China's architectural practice
Architectural concept and panoramic design Some people say that architecture is art- the art of language or the art of trade-offs, and I feel that architecture is the logical generalization of the worldview. Below we try to outline the architectural idea in quasi-logical terms. First, we propose the following architectural theorem1:
Theorem 1. Architecture is the skeleton of the product, and philosophy is the principle of architecture!
Just as a building cannot be without a steel skeleton, a bridge cannot be without piers and columns, a product without the right structure is bound to fail. But what determines if the architecture is correct? As architectural methodologies such as TOGAF (Open Group Architecture Framework) point out, the principle is the soul of the architecture, and the idea is the principle of the architecture.
In our architectural practice, we have found that the biggest problem of many traditional OEMs in the process of digital transformation is not that there is no technology or product, but that there is no concept. I don't know who I am, where I came from, or where I'm going. Some OEMs are accustomed to looking at the car from the perspective of the Tier1 supplier, or from the perspective of the cloud vendor, and from the perspective of the hardware vendor, but rarely from the perspective of the car. That is to say, most people do not realize that the core concept of the car architecture is actually to make a good car.
So, what architectural concept is correct? We next propose theorem 2:
Theorem 2. Software-defined cars, service-defined software
The concept of software-defined cars is clear to everyone and I will not repeat them here. I would like to point out that for OEMs, how to define "software"? When many people talk about software, they think of the in-car SOA (service-oriented architecture) ecology, which separates the in-car ecology from the cloud ecology. However, the car can not be separated from the cloud ecology and exist, if it is separated, then what is the difference between the main engine factory and the foundry?
So, if we look at the "in-vehicle SOA+ cloud ecosystem" as a whole, is it enough? The answer is still not enough, because many connected vehicle functions rely heavily on traditional IT systems. For example, users need to set user preferences from the mobile Internet portal before picking up the car, and the biggest problem in this link is not how the car hardware ISTA (wireless firmware upgrade), nor how the cloud is delivered, but when the manufacturing system sends the vehicle metadata. Therefore, OEMs need to look at software from the overall situation, that is, to stand in the perspective of services and define software with services.
How do you deliver the concept of delivery service-defined software at a concrete, hands-on level? We propose the following definition 1:
Definition 1 SDN (Service Delivery Network) provides services to producers and consumers in the Internet of Vehicles across multiple communication networks (WAN/In-Vehicle Ethernet/Edge Network), as well as a variety of basic capabilities such as traffic routing, vehicle metadata, authentication, and circuit breaking.
SDN is a conceptual service delivery network that is somewhat similar in concept to a middle office, but very different. Our common middle offices are data middle office, business middle office, technology middle office, etc., but they all have a characteristic - from the perspective of the cloud to see the overall business. In many cases, OEMs are just the opposite, need to stand at the end, and it is a heterogeneous and multi-terminal perspective to sort out the business.
As shown in the logic diagram shown in Figure 1, we use the channel to link the end and the cloud in SDN, define the software product from the perspective of the main engine factory, and realize the software-defined car in the true sense, rather than the software grafting car.
Figure 1 Linking the cloud and the end with a channel
Further, how do you define a service? What are the boundaries of the service? Is the service a logical unit or a physical unit? To this end we propose definition 2:
Definition 2 Service is a deployment unit based on an entity that provides services externally in the form of APIs that can perform heterogeneous computations across hardware.
Here we first emphasize that the cornerstone of a service is a logical entity, such as vehicle metadata is a typical logical entity. It should be noted here that there is no emphasis on the granularity of logical entities, and if the granularity is required to be too fine to be indivisible, then the service here is very similar to the microservices concept. However, in automotive software, all services are not required to have a uniform granularity, because the same logical entity has different computing resources and distributed environments in different hardware and environments, and is not suitable for one-size-fits-all.
Second, the service requirements here are provided externally in the form of APIs, and not only communication protocols, but also Socket interfaces, RESTful, or message brokers. However, it will require a unified interface Uniform Resource Name, a unified security mechanism, a JSON-based data structure, and a unified Error Code.
Last but not least, the requirement is that it can be computed across hardware, which is in preparation for edge computing or hybrid cloud. For OEMs, ensuring the free scheduling of computing power and transporting data to computing nodes is a very critical core capability, in order to achieve this purpose, container technologies such as Docker and WebAssembly can be used.
Container-based hybrid cloud model
A hybrid cloud strategy is one that combines public and private cloud environments, enabling enterprises to combine the benefits of both. The advantage of public cloud is that it can be paid as needed and elastically expanded according to the needs of enterprises, and private cloud provides enterprises with environmental isolation of sensitive data to ensure enterprise data security. In order to effectively use the advantages of various cloud service providers in network resource integration, vertical field development, traffic promotion, etc., and to avoid being deeply bound by a single cloud service provider, enterprises often dock multiple public cloud providers in public cloud cooperation.
While hybrid clouds integrate the benefits of public and private clouds, they also introduce more costs of security precautions, and data interaction control and design between clouds bring greater complexity to heterogeneous resource management. Only from the perspective of application management, in the context of hybrid cloud, it is necessary to use containerization technology to achieve the abstraction of the application layer, and to use large-scale distributed resources and service management tools to dock different cloud service vendors, and it is necessary to mask the heterogeneity of the IaaS layer (see Figure 2).
Figure 2 Hybrid cloud architecture design
Establish an abstraction layer to mask cloud service differences:
The Serverless features of cloud service providers usually work in the same way, with specific differences in specific scenarios. A BOSH engine similar to Cloud Foundry can decouple the differences in dependencies between applications and service management and down-level resource management by establishing an abstraction of IaaS resources. The core functions of the resource abstraction layer are:
Connect to the cloud platform interface of the cloud service provider. Through the resource management interface of the integration service provider, a unified resource management API is provided upwards to shield the heterogeneity of the resource layer.
Provides monitoring data of resource running status, and performs unified anomaly detection, automatic recovery, and alarm notification for VMs of each cloud provider.
Provides a unified resource management portal. Abstract descriptions of IaaS layer resources provide a unified resource management interface and management APIs.
Container-based platform-independent practices:
Containers offer lighter isolation than virtual machines, like Docker and Cloud Foundry's Garden. Under the background of the gradual user-centric digital transformation of the automotive industry, a set of distributed service governance system based on containerization is very important for car companies, which is mainly reflected in the following aspects:
Major cloud service vendors support container technology. The environmental adaptability brought by container technology to car companies is irreplaceable, and car companies can focus on their own business development and development without worrying about the bundling of specific cloud platforms.
Container technology masks differences in system environments, allowing developers, testers, and operators to focus solely on image deployment, testing, and release of applications and services, simplifying communication and environmental costs.
The container ecosystem is well developed, and the Open Container Initiative (OCI) has developed specifications for the two core parts of the container runtime environment and the container image format.
Finally, container technology, combined with Kubernetes orchestration tools, can further improve the resource utilization of applications, simplify deployment and increase scalability.
Vehicle-cloud collaborative computing based on containers and microservices
With the gradual promotion of automobile intelligence, the automobile has changed from a simple means of transportation to a carrier that undertakes more and more functions. For example, the recently popular concepts such as intelligent cockpit and unmanned driving, whether it is the main human-computer interaction experience of the intelligent cockpit, real-time safety reminders, intelligent AR navigation and other functions, or the capabilities of unmanned L2 ~ L5, behind which many services and calculations are needed to support. Whether these service capabilities can be quickly delivered to customers has become an urgent problem that OEMs need to solve.
For traditional vehicle development, a longer cycle is usually required. To deploy a function to a vehicle, it usually takes 3 to 4 years from design to production, which results in relatively conservative hardware specifications on the vehicle. In addition, due to cost and energy consumption factors, hardware computing power may not be enough to meet the requirements, especially in unmanned driving scenarios, requiring a large number of services such as real-time analysis of road conditions based on computer vision or radar data. So the idea of moving these services to the cloud came naturally. This can not only greatly reduce the manufacturing cost of the vehicle, but also based on the high-performance and scalable computing power of the cloud, it can also do many computing tasks that the car side is not competent for.
However, there is a latency problem with cloud computing. Automatic driving for intelligent decision-making latency requirements are very high, if moved to the cloud to calculate, will inevitably cause an increase in latency, which will have a serious impact. For example, if a vehicle travels at a speed of 120 km/h on a highway and can travel more than 30 meters per second, an increase in time delay can cause serious traffic accidents. This leads to edge computing solutions to solve latency problems, that is, to move those computing tasks in the cloud to the edge computing platform on the side of the road, so as to assist the vehicle to make real-time intelligent reminders and decisions. It brings three benefits: first, the computing power is greatly improved, which is conducive to improving accuracy; second, it does not need to occupy too much core network or backbone network bandwidth; third, it can effectively reduce the delay, and the vehicle can connect to the terminal on the road through the base station, shortening the data transmission path and canceling the time from the Internet to the wireless core network to the wireless access network.
There are multiple deployment locations such as vehicles, clouds, and edge computing. If each scenario is developed separately, it will inevitably bring huge costs and inconveniences. Therefore, building a unified runtime environment through containers has become an inevitable choice. According to the needs of the scene, a service can run on the car, cloud or edge node, and the use of a unified technology stack can not only reduce the cost of deployment, but also adjust it according to the actual situation, which brings a very large space for the main engine factory to play.
In addition, the data of the Internet of Vehicles has the characteristics of large data volume, many types, and fast speed, which are what microservice architectures are good at. The ease of horizontal scaling of microservices allows for deployment across multiple servers and infrastructures, well supporting the need for high concurrent connections and high throughput. At the same time, the use of microservices architecture can also decouple different services, reduce the complexity of the system, and make it easier to deploy.
By combining containers and microservices, OEMs can quickly deploy services where they need them, and they can also face the growing number and demand of customers, which shows that this is a very suitable solution.
Elastic scaling capacity based on throughput and off-site active-active
Sales of a model usually go through a development process, if you build a large amount of cloud infrastructure at the beginning, there will be a huge financial cost, based on containerization technology rapid expansion and dynamic adjustment can significantly reduce costs. For example, deploying a small number of containers when the number of vehicles in the early stage is not large, and deploying corresponding services according to the actual throughput after sales expansion, you can reduce unnecessary cost waste and reduce financial pressure.
And, because containers are created very quickly, the number of nodes can be rapidly expanded or contracted as throughput changes, which can further save costs.
"User-centric" car companies need to consider the continuity and availability of cloud services, which is reflected in the technology of off-site dual-life. The container platform based on Kubernetes management can achieve a multi-computer room, multi-region, multi-cluster unit architecture through the control capabilities of the federation, and provide unified release control and disaster recovery and emergency response capabilities for the service in some complex scenarios.
Federation has the following characteristics:
Simplify the management of Kubernetes API resources for multiple federated clusters.
Distribute workloads (containers) across multiple clusters to improve the reliability of applications (services).
Applications (services) can be migrated more quickly and easily in different clusters.
Cross-cluster service discovery, where services can be accessed nearby to reduce latency.
Implement multi-cloud or Hybird Cloud deployments.
By utilizing these features, we can coordinate the resources, applications, and configurations of each cluster to achieve application change control, group publishing, image management, traffic allocation, metadata management, and cluster resource management, thereby reducing O&M costs. But no technology is a panacea, and here we must recognize several problems:
Off-site multi-activity has costs, including development costs and maintenance costs. The more business that needs to be multi-active offsite, the more design and development time will be invested. At the same time, it will also increase maintenance costs, requiring more machines and bandwidth.
Not all services are necessarily suitable for off-site active-active, which is more typical of businesses with strong data consistency, because data synchronization takes time and inconsistencies may occur.
Therefore, when considering off-site multi-activity, it is necessary to identify the core and key businesses from the perspective of business and users, and clarify which businesses must achieve off-site multi-activity, which can not be multi-active off-site, and which cannot be multi-active off-site. For example, "login" to achieve off-site multi-activity, "modify user information" and "registration" do not necessarily achieve off-site multi-activity.
summary
Finally, with the continuous advancement of technology, especially the gradual use of driverless technology, the automotive industry is bound to have a big change. People are becoming more and more convenient to travel by car, enjoying more and more personalized services, and the car will evolve from a simple means of transportation to a mobile home. How to quickly provide users with these services has become a problem that OEMs must face, which is also the origin of software-defined cars. The practice of vehicle cloud based on microservices and containerization is an exploration of our future and closer to users.
—END—
This article is from The New Programmer 002: The New Database Era & Software-Defined Cars, created by more than 60 experts. The book is accompanied by "2021 Database Panorama V1.0" and "2021 Automotive Technology and Industry Ecology V1.0", as well as "2021 Database Development Research Report" and "2021 Software-Defined Automotive Research Report", which are presented with graphics and video multimedia.
This book's high-level industry analysis and trend prediction are suitable for the reference decisions of middle and high-end practitioners. At the same time, the introductory and practical journeys experienced by many experts also provide a professional path for beginners to learn from.