When we talk about the communication of smart cars, what are we talking about? Is the hot SOA technology the "endgame" of smart car interaction mechanisms? Let's dig deeper and explain these concepts with an article.
(Image from the Internet)
Basic concepts of communication
Communication technology is very diverse, and the characteristics of each technology in transmission rate, cost, maturity, latency, stability, security, etc. are also different, but their structure is similar.
Discussions on communication technologies generally begin with the Open System Interconnection Reference Model (OSI).
Application layer: Some service interfaces for users
Presentation layer: Translate, encrypt, and compress data
Session layer: Establish, manage, and terminate sessions
Transport layer: Provides end-to-end communication connectivity, including subcontracting, reorganization, flow control, etc. (segment segmentation)
Network layer: responsible for the end-to-end transmission and interconnection of packets, similar to the start and end points of mailing (packagepacetT)
Data link layer: responsible for the actual transmission pipeline, the data is reliably transmitted to adjacent nodes, similar to the logistics transit station (frame Frame)
Physical layer: responsible for transmission over the physical medium, similar to a van (bit)
The choice of communication technology is determined according to the business requirements and the characteristics of the technology itself. For example, the hierarchical design of the Ethernet (TCP/IP) protocol is more complex, so it can support the diverse needs of Internet services. The can protocol on the vehicle side simplifies the design of each layer to meet vehicle reliability and low latency requirements.
Communication technology is commonly used in the whole vehicle
Further, we list some of the communication means currently used by mainstream smart cars, as shown in the following table:
A LIN network is a low-cost serial communication network that primarily functions as an auxiliary CAN. In many communication scenarios where bandwidth and functionality are not required, the use of the LIN bus can save costs. LIN adopts a single master controller/multi-slave mode, which is generally used with CAN, at the end of the entire electrical architecture, connecting some terminal equipment (doors, seats, etc.) with low real-time requirements.
A FlexRay network is a high-speed deterministic, fault-tolerant bus system that is typically a two-wire connection. Users can configure static transmissions to send more secure periodic information, using the Time Division Multiple Access (TDMA) method for scheduled time allocation for each communication node; they can also configure dynamic transmissions to send unstable non-secure messages using the Flexible Time Division Multiple Access (FT-DMA) method. Poll each communication node to confirm that no information is sent. Compared with CAN communication, FlexRay is more expensive but more real-time, and is generally used for controller communication with high safety requirements.
Low-Voltage Differential Signaling (LVDS) is a low-power, low bit error rate, low crosstalk and low-emission differential signal technology, with the advantages of small power consumption, strong noise resistance, small electronic interference, etc., generally used for high-speed I/O (such as camera video streaming) transmission tasks.
In addition to the above communication technologies, the hottest in the industry at present, still CAN/CAN-FD networks and Ethernet-based SOA (SOC) communications, we focus on.
CAN/CAN-FD communication
CAN/CAN-FD network is the absolute main force of intelligent vehicle communication at present, with better performance, high reliability and low price. Unlike Ethernet communications, CAN/CAN-FD networks exist more to accommodate interconnections between multiple controllers in a distributed architecture.
The principles of CAN have been introduced in many articles, and this article will not be repeated as a focus.
The CAN-FD protocol can be understood as an upgraded version of the CAN protocol, the physical layer has not changed, but the transmission rate, data length, frame format, etc. of the protocol layer have changed. For example, increasing the 8 bytes of data per frame of CAN to 64 bytes, the baud rate is increased from the highest 1Mbps to 5Mpbs, which greatly improves the communication efficiency of the vehicle.
CAN-FD increases the flexibility of packet organization and can support the PDU concept under the AutoSAR framework. PDUs are divided into two categories: Container PDUs, the former being the container of the latter and the latter for storing specific signals. Compared with traditional fixed-length CAN information, CAN-FD can dynamically configure the location and number of embedded Signal PDUs at the time of sending according to the requirements, so that it can more flexibly adapt to loads and service requirements.
This flexibility often requires a higher level of professionalism on the part of the tester, as configuration flexibility increases the difficulty of signal resolution and inspection.
Whether it is CAN or CAN-FD, it is still essentially a signal-based communication, no matter how much flexibility the PDU adds, CAN/CAN-FD still carries a strong "communication" brand, in essence, the organization of the sender, receiver is still fixed, and the adjustment is also slow. The Ethernet-based SOA we are going to talk about next is relatively more flexible. Although SOA is often used to compare with CAN, it is no longer a means of communication.
Ethernet communication
The protocol stack of intelligent car Ethernet communication is more complex than CAN, of course, its coverage of the business surface is also wider, the flexibility is also higher, is the current communication between domain controllers the mainstream scheme. As shown in the following figure:
At present, there are two development routes for Ethernet communication in smart cars.
One route is time sensitive networking (TSN), which is a comprehensive improvement from the link layer upwards, is an Ethernet communication protocol with great potential in the future, but the current application is still being explored. At present, it is more of another technical route, that is, the improvement of conventional Ethernet technology, mainly adjusting the design of the underlying layer and the application layer, but retaining the design of most of the network layer and the transmission layer, which can be seamlessly connected with the traditional Internet.
SOA on top of Ethernet
Now that we have learned the basics of Ethernet communication, we can discuss SOA, which is Service-Oriented Architecture. SOA is not actually a specific technology, but a guiding ideology or paradigm at the level of architectural strategy, a distributed design to better organize and utilize information under the control of different ownership areas.
SOA is not a pure communication mechanism, although it looks similar to signal-based communication such as CAN. But a closer comparison reveals that there is a fundamental difference between the two. As shown in the following figure:
Service-oriented communication defines "service party" and "consumer", "service party" is the sender in the traditional sense, and "consumer" is a receiver.
In the vehicle application, we can complete the generation of CAN-like communication matrix through AutoSAR AP or self-developed generation tools to meet the communication needs of various domain controllers. Compared with CAN, in addition to the different communication carriers, SOA also has the service discovery function supported by Ethernet SOME/IP, which can dynamically establish the transmission link between domain controllers, thereby realizing the construction of a dynamic topology, thereby improving the flexibility of the software update process.
Unlike fixed information transmission, consumers can use "service discovery" to subscribe to the information output services prepared by certain service providers. Applications are loosely coupled connections, where the needs of consumers change and service providers often do not need to make changes. But this often only reaches the level of service-oriented communication (SOC), has not yet risen to SOA, and is still a kind of thinking from the perspective of "communication".
Because SOA is more likened to CAN, many practitioners responsible for communication network configuration are often accustomed to thinking about it from a "communication" perspective, which makes the role of SOA much less effective. In the early days of SOA, many of the definitions and designs of SOA were also very poorly understood, in large part because they were constrained by the inherent mindset of "communication".
In fact, understanding SOA is very simple, if you start from the perspective of "calculation", many problems will be solved.
As the following diagram shows, if we look at it from the perspective of a software developer, SOA is actually more of a function interaction. The call to a function looks like a "computation" process, but of course the concept of "communication" is hidden behind it. In general, through the pull of memory pointers, we can find the corresponding methods and data when calling a function, and SOA is largely more like turning the "pointer and memory" of the function call into "ID and network".
Understand SOA with object-oriented programming in mind
Continue the analysis from the perspective of "functions". As shown in the following figure, we look at the types of services provided by SOME/IP, and the services (Services) described by them are more of a "class" concept. Instance is an adjustment to the method of the "class", while the interface and event group markup are to adjust the data structure of the "class". The Event, Method, and Field under Interface are more like constraints on the read and write permissions of a data structure and the design of the output method. Class interactions tend to be "bidirectional", and SOA is actually bidirectional. However, due to the constraints of the concept of "communication", SOA is often forced to be designed as a "one-way" process.
Some/IP service type
This article argues that SOA was designed to be developed on multiple domain controllers as convenient as developing on one domain controller. If you look at SOA design from the perspective of software design patterns, it is indeed easier to achieve this goal. However, in practice, there are very few network configuration engineers who have done software development at the same time, and most of the configuration engineers with different domain controls do not understand each other's business areas, and the software architecture engineers who can coordinate multiple domain controllers are even rarer, and the implementation of SOA is often stuck at this point.
Is SOA the end of the smart car?
So, is SOA the end of smart cars?
Not really. As shown in the figure below, we compare the evolution of the transportation business with the evolution of the communication architecture.
In the transportation system, private cars represent the fixed mapping relationship between people and vehicles, in the case of unconstrained demand, the overall load of the transportation system and the balance of load are difficult to achieve, traffic congestion and parking resource mismatch and other issues, will inevitably appear frequently. After the emergence of the logic of shared cars, the fixed relationship between people and cars has been broken, the situation has improved, and the utilization rate of the transportation system has increased. But after all, it is still the driver who drives the car, although there is a reward system adjustment, but it is still affected by personal life schedules and operational preferences. The next step in shared travel is based on driverless intelligent travel, because the relationship between people and vehicles is untied, and from energy replenishment to driving routes are the optimal results of the overall planning of the system, so it is very likely to become the end of the development of the transportation system.
The development of communication is actually a truth, signal-based CAN communication, reflecting a fixed signal interaction process, can not effectively meet the changes in the service.
SOA changes this process by establishing a variable relationship of signal interaction, like supermarket shopping, which communication process is valid no matter which goods (services) you choose in the supermarket. However, there are also many constraints: first, the bandwidth load and computing consumption of communication will still produce operational instability along with the adjustment of the link, so engineers are also required to participate in some adaptive design; second, no matter how flexible the service design is, its interface still relies on manual design, and the services it can provide still need to be designed by people, and it is impossible to exceed the cognitive scope of developers.
In the future, will there be a communication mechanism that will have a more delicate interaction process and that can still ensure the stability of the operation after the change? The answer is yes, and that's deep learning.
Let's take a typical example. Imagine one day, you sit in the car with a sad face, and the car offers you a song that you often listen to when you are sad. You seem a little moved when you are surprised by its performance. But the machine may not be so emotional, it just has been analyzing the interaction data between you and all the interfaces in the car, and found a clear correlation between the expression recognition results and the playback of the song. We can capture this correlation with deep learning models, and this level of network model training can even be done in the car. When the system finds that there is a regularity in your behavior patterns, you can actively complete the subsequent action the next time the trigger condition is met.
In this case, we can see that deep learning has a new advantage over SOA. Everyone not only subscribes to the existing services, but also has a private customization and fine-grained service. And this change may not need to be obtained through OTA upgrades, but will be cultivated by users locally.
Based on the above analysis, this paper summarizes the three stages of intelligent driving services:
The first stage is to build a fixed and stable relationship;
The second stage is to construct variable but not necessarily stable relationships;
The third stage is to build variable and stable relationships.
We are currently in the transition from phase I to phase II, and to move into phase III, the core is to remove as much human intervention in service execution as possible.
Smart Cars from "Communication" to "Communication"
People's general understanding of communication has always been stuck in the entire process of transmitting information from one place to another without loss. But that's not all there is to communication.
If we model a basic communication process, we find that there are two basic conditions: first, a codebook is shared between the encoder and decoder to ensure that the information is consistent; second, there is a common understanding between the recipient and the sender, which promotes consistent action. But the noise in the whole process has always existed, and the noise of the codec process is more of a transmission loss, and the deviation between the sender and the receiver is often a difference in understanding.
The situation is similar when this model is introduced into human-to-human communication and machine-to-machine communication. There are deviations in understanding between people and people, and the same is true between machines and machines. Although information transmission is one-way, the understanding and conversion of information is often a process of repeated two-way running-in.
Real interaction processes are the result of a combination of communication and computation. As shown in the following figure:
There is an example of online fraud that may give us a deeper understanding of the differences and relationships between consistent messaging and consistent action. Once a male fraudster packaged himself as a woman associating with another man and defrauded a lot of money, one of the chat records was exposed, the woman (pretending) said: "You have no money yourself, don't lend me, I don't like that boys don't have money." This sentence is very interesting. Scammers need to make sure that their ideas are consistent with the actions of the other party, that is, to make the victim hand over the money, but the actual message is completely opposite to their own ideas. Intriguingly, because this sentence stimulates the victim's self-esteem as a man, making him more willing to lend out the money, thus allowing the fraudster to achieve his goal in action.
The same is true for the current smart car, in addition to ensuring that the underlying communication is "not damaged", but also to explore the experience of the communication process. From CAN to SOA to deep learning, in the evolution of smart cars, the concepts of communication and computing will be further blurred, and machines need to shift more from "information transmission" to "communication and communication".
Reprinted from Yanzhi Intelligent Car, the views in the text are only for sharing and exchange, do not represent the position of this number, such as copyright and other issues, please inform, we will deal with it in a timely manner.