On the interdependency between in-vehicle networking and the EE-architecture – survey results
The complexity of electronically supported and/or enabled functions in cars is increasing and will continue to do so. The ultimate use case is autonomous driving, for which a large number of functions have to interact seamlessly and faultlessly. The in-vehicle network (IVN) and the EE-architecture are important enablers that have to provide for this. The survey results presented in this article describe how players in the market are currently seeing the challenges, needs and interrelation between the IVN and the EE-architecture.
One of the main observations of the survey is that there is very little variation between the different groups of participants, namely car manufacturers, Tier 1s, semiconductor vendors, and others. For many questions there is a harmonious undecidedness among all participants. Everybody knows that changes are immanent. There is agreement that the challenges on the IVN increase in the future, but what the consequences are and how to tackle them, seems unsure. Examples: The participants agree that technologies like CAN, LIN, FlexRay and Ethernet are part of the IVN. For everything else (software, power, wireless/mobile, P2P, …) they are not sure.
Does the IVN technologies decide on the EE architecture or the EE architecture on the IVN? Undecided, too. There is no clear picture on the amount of redundancy an IVN has to provide (in contrast to redundancy in sensors and electronic control units (ECUs)). The participants agree that the support of software is getting more important, which reflects on the IVN and its capabilities. Not surprisingly software updates and software upgrades are seen as very important for the future. How to provide for additional resources the new software might need, in contrast, seems to be yet another open question in the industry.
Overall 119 persons participated in the survey (see also Figure 1). The survey distinguishes between four groups of participants: Employees from car manufacturers (33), from Tier 1s (32), from semiconductor vendors (34), and others (20). “Others” consisted of a large number of different entities ranging from to tool and software suppliers to market intelligence. All participants were selected based on their involvement with IVN. The survey additionally asked the participants for their assessment of the market position of their company. Like for the survey conducted in the previous year on the future of IVN-technologies (see Hanser Januar/Februar 2016 or http://go.hanser-automotive.de/1299263) the majority, about 2/3 of the participants, works for innovation leaders. Only among the participants from car manufacturers the assessment is somewhat different. Here, the relation here is about 40%/60% (innovation leader/follower). However, the evaluation of the answers showed little differences between the groups; neither between different players in the supply chain, nor when looking at their market position. A distinction will thus only be made when noteworthy.
Naturally, 119 participants is not a statistically relevant number. The answers are thus not proof of what is going to happen in the future in the market. The answers give indications only; albeit interesting ones.
2. IVN and EE-architecture
In order to be able to explore the relationship between IVN and architecture, the first question assessed what the IVN actually is/comprises. Figure 2 shows the respective survey results. There is no question that CAN, LIN, FlexRay, and Ethernet are part of the IVN. Apart from that, the understanding is quite ambiguous. (Only) just more than 50% of the participants are sure that the power supply network and the backend, are NOT part of the IVN. For the other aspects – software, power in form of power-over-dataline (PoDL)/powerline communication (PLC), wireless communication inside the car (Bluetooth, Wi-Fi), (digital) P2P communication, (analog) discrete links, cellular communication links – (only) between 50 and 25% of participants are sure they are part of the IVN.
Between 34% and 42% think the listed aspects are partially part of the IVN. This means that almost four out of ten people working in the realm of IVN, cannot commit, if these aspects are part of the IVN or not. The questionnaire did not ask why these answers were given or what portion exactly is part of the IVN and which one is not. Clearly, the aspects have some impact, but how to handle them or what they are exactly remains unclear. Potentially, the different aspects have different responsibilities in the organizations; something that might require rethinking in the organizations with increasing complexity of the IVN. What is also clear: the IVN is more than just Ethernet, FlexRay, CAN(-FD), and LIN.
The next question discussed the current and future challenges in the IVN (see Figure 3). More than 50% of the participants see the number of IVN technologies (66%), costs (66%), enough data rate (59%), time sensitive data (58%), and the car as a software product (56%) as a big or the biggest challenge. Less than 50% of the participants think that the number of gateways (48%), the power consumption in the IVN (38%), the space needed by the IVN (30%), and the reliability (30%) are an issue. Two aspects are noteworthy: a) participants from car manufacturers rate all aspects as more challenging than the rest of the participants (in average by 6.5%, not shown in Figure 3) and b) in the future almost all aspects (except for the number of IVN technologies) are rated as more challenging than today (by 9%).
The responsibility of the overall function in the car and thus the functioning of the IVN is the responsibility of the car manufacturer. Consequently, participants of car manufacturers are more sensitive about the effort and costs the IVN entails. Concerning the increase of the challenges: The requirements on the in-vehicle communication are still continuously increasing, especially with new functionalities like autonomous driving. I.e. a robust and powerful IVN becomes ever more important. When looking at the differences between innovation leaders and followers (not depicted), the innovation leaders among the car manufacturers rate most challenges above average, especially the number of IVN-technologies, today and in the future.
One additional aspect repeatedly mentioned by the participants and not provided in the list in the questionnaire, were the number and types of connectors and cabling options needed in cars. For the future, additionally a flexible, automatic network configuration was seen as necessary. It was surprising to the author that reliable communication received the lowest rating. After all, it is the basis for everything else. It includes compliance with the EMC requirements, not being disrupted, and not disrupting other functions in the car. However, as EMC was mentioned a few times as additional challenge, maybe EMC was simply not seen as part of the question for reliable communication by the participants.
Last but not least, security was mentioned as an additional challenge. Figure 4 shows the results of the question, whether the IVN was more a threat or more a solution to security. 60% of the participants think that IVN technologies play a vital role in supporting security, 11% think IVN technologies are a major threat to security, 25% agree with both and 4% with neither.
In contrast, the participants are completely undecided, whether a) the EE architecture determines the design of the IVN or whether b) the capabilities of the IVN determine the design of the EE architecture (see Figure 5). 38% agree more with a), 39% agree more with b) and 23% agree equally with both. For the author this is a surprise, too. In my experience, the EE architecture today is designed along the capabilities the IVN provides (i.e. b)). It is one of the goals of introducing an Ethernet-based in-vehicle network and to design different speed grades for it that this is no longer the case, but that the EE architecture can be designed independent from the capabilities of the IVN. The switched architecture of an Ethernet network allows flexible topologies and “plug&play” (see e.g. M. Ziehensack, “Automotive Plug&Play”, Hanser Automotive Networks Conference, November 2016). The strict layering allows the use of higher layer protocols like SOME/IP and service based architecture, mechanisms, which are needed to create a transparent network.
Naturally, it is true as well to some extent that IVN-technologies are being developed and enabled along the communication needs of the EE architecture. Especially in the past the automotive industry has developed a number of different technologies in order to support future needs in the EE-architecture. Today it seems that car manufacturers focus on the development of Ethernet while semiconductor companies propose different new technologies.
3. IVN and software
The survey results give a more harmonious picture, when asked for the interrelation between software and IVN. Figure 2 and 3 both emphasize that software is important in the context of IVNs. The statement that future IVNs need to support the communication for software instead of the communication between ECUs is supported strongly (see Figure 6). 50% of the participants totally agree and 46% somewhat agree, whereas only 4% disagree.
With the increase of software also the importance for software upgrades and updates increases. 93% of the participants agree that in the future remote software upgrade (for new functions) will be important or very important. Even 98% think that remote software update (bugfix) will be (very) important in the future (see Figure 7). Today, remote software upgrade for new functions, is still (very) important for 50% of the participants, even though has been productized in few cases only. It can thus be concluded that it is an important topic for everybody in the industry.
Software upgrades inherently provide new functions. Quite possibly, these new function will require more processing power and/or memory. In case of upgrades, a car manufacturer thus needs to provide these additional resources. The participants have been asked questions about three different ways of doing so: 1. To provision the resources with the production of the car 2. To use external computing power e.g. in the back end for it or 3. To add hardware modules later. Figure 8 shows the answers on the percentage of extra resources the participants think the car manufacturer have to provision upfront. As can be seen: Clearly a difficult question to answer. About a third of the participants did not know; fewer among the car manufacturers (20%) and over 60% of “others”. The average value estimate for additional resources that need to be provided upfront was 32%.
More participants think that hardware plug-ins are a more likely solution than external resources like the backend for providing additional resources (see Figure 9). However, the majority or participants are uncertain in both cases and think them “likely to some extend”.
No question was asked about the exact interdependencies between the IVN and software. However, when we think of upgrading new functions into the car, it is important that the IVN does restrict neither the upgrade process in itself nor the new function. Ideally, the IVN is transparent to the software, so that the car can be seen as a single computing platform, where it does not matter, how distributed the software is and where it runs exactly. The limiting power should be the CPU, not the network.
Last but not least, the survey addressed the topic of redundancy. With the advent of autonomous driving the question is how much redundancy is needed in the EE architecture and the IVN. Figure 10 looks at the necessity of redundancy today and in the future. It can be seen that the situation reverses: Whereas the majority of participants considers redundancy of only some importance today, 87% think it is important or very important in the future. 16% think that redundancy is NOT important today. Everyone gives it at least some importance in the future. When distinguishing between the different groups of participants (not visualized), there is no particular deviation from the average results noticeable, with one exception: No car manufacturer participant thinks redundancy is very important today. When distinguishing between innovation leader and follower, one interesting observation among the participants from the car manufacturers can be made: For participants working for innovation leaders redundancy is more important – today and in the future – than for participants from followers (see Figure 11).
In the end, this can be explained based on two aspects a) the point in time a car manufacturer is going to introduce automated driving (or has already introduced driver assist functions to that end) and b) costs. Redundancy costs money, because car manufacturers have to provide for functions that are not needed as a rule but only in exceptional cases. This is a similar to providing additional computing resources a car does not need to start with. It can be expected that followers will need respective redundancy later and potentially in different forms.This can change, if certification in the realm of ISO 26262 requires some form of redundancy for certain functions. Note though, that this is just a tendency among those who participated. Within a larger group, the result might have been different.
Figure 12 investigates the importance of different types of redundancy. Most important for the participants are redundant sensors and redundant ECUs. In the context of autonomous driving this makes sense as it is core to autonomous driving that a car recognizes (sensors) and interprets (ECUs) the surroundings correctly. Furthermore, steering and brake control need to be redundant ECUs as well. Concerning the redundancy in the IVN, half or fewer participants think redundant communication links, redundant communication technologies on separate connectors, or redundant communication links using different technologies is important or very important. Sending the same information twice is not seen as very helpful. Redundant software also does not have many supporters either.