It was morning and I was at the wheel, driving along the Tokyo Metropolitan Expressway. It was a break in the rainy season, and the blue sky was refreshing. I felt the urge to accelerate into a curve, when all of a sudden the voice of the car’s navigation system intoned, “You are now entering a short stretch where there have been many traffic accidents.” I instinctively let up on the accelerator. After a little bit, it spoke up again: “The lane is about to become narrow due to construction, so please drive carefully.” I did drive carefully, but there was no construction. And when I was coming out of a tunnel, it spoke up once more: “Past the xx Tunnel there is no congestion.” I thought to myself, “What?”, but I did faintly appreciate its kindness. The morning sun shone on the wet road surface.
Cars nowadays are connected to various things. In the case mentioned above, it was a connection to the Tokyo Metropolitan Expressway’s Vehicle Information and Communication System (VICS). Although there are unfortunately still many things about the VICS, especially the precision of its real-time traffic congestion information, that leave me with doubts, I am more or less satisfied with those features of the system that are backed by past data, such as warnings about the potential for accidents. In fact, I do instinctively become more attentive when it tells me that an area has had a lot of traffic accidents. In this respect, cars have certainly become smarter and safer than they used to be.
What a “connected car” is
“A connected car is an automobile that is equipped with functions that permit it to be constantly connected to a computer network” (Wikipedia).
Through the incorporation of IT technology, cars are steadily evolving. The implementation of electronics and IT in cars, which got its start with the use of electronic controls on internal-combustion engine systems, has, by means of external communication connections (via the use of onboard navigation systems) and the implementation of a complete set of onboard sensor functions, evolved to the creation of internal communication systems in cars (controller area networks — CANs) and subsequently to the point where cars are constantly connected with the outside world via onboard communication devices (data communication modules — DCMs), etc. Although significant progress can be expected, not just in the area of safety but also in the areas of efficiency and convenience, problems are developing too, mainly with regard to the entry of another industry (i.e., IT) into the world of cars and the question of how such functions are to be used and applied. Connectedness is changing the structure of cars themselves, and it is also changing the organizational and industry structure of automobile OEMs. Connectedness is truly the fundamental technology of today, and beginning with connectedness, cars are currently evolving and changing in a variety of ways.
The origins of connectedness
At the 1939 New York World’s Fair, General Motors exhibited Futurama, a diorama of a city of the future. In the exhibit, a 3-dimensional design by “the genius of streamlining,” Norman Bel Geddes, showed a city center filled with high-rise buildings, and residential areas in the suburbs, and between them an automated highway system, i.e., a highway network that made automated driving possible. It is said that it was in about 1937 that America achieved motorization; at that time, 4.0 million new cars were being sold per year, but as cars became more widespread, new problems such as traffic accidents and air pollution became evident. Futurama showed an America of the 1960s that had solved such social problems.
However, things did not turn out the way GM had depicted them.
Instead, in 1956 an evening newspaper showed a family playing games while riding in a self-driving car on the highway.
The caption in the newspaper explained, “The Electric Super Highway, with electronic control devices buried in the ground beneath it, will free you from traffic jams, collisions, and driver fatigue.” But this was more than just a concept illustration. In fact, in the late 1950s the Radio Corporation of America (RCA) and GM jointly carried out — on an actual road — “highway of the future” experiments in which signals from electronic circuits embedded in the road drove a car automatically. However, because obviously it would not be possible to have advanced equipment located under a roadway that bears heavy loads, in the end the concept did not get put into practice.
But, how did they end up with something impossible like that? It was because computers, which at that time had only begun to be put to practical use, were large, and nobody thought that they could be put in cars. However, as a result of remarkable advances in technology, computers later became smaller and could easily be placed in cars, so the approach used for automating driving changed from making roads smart to making cars smart. In the meantime, attempts to make cars more convenient by connecting them to a variety of external things were advancing continuously as ICT technology evolved. Cars, like other devices, became part of the Internet of Things (IoT); they were constantly connected to the Internet, and this gave birth to the connected car of today.
The spread of connected cars
According to data from IHS Markit, 93% of new cars sold worldwide in 2030 are predicted to come with connectedness functionality. Considering that the figure in 2015 was 27%, it is clear that connectedness will spread rather quickly worldwide. With that being the case, although some people are claiming that as cars get more and more connected to networks, the added value that was in the car itself will shift to the network, as happened in the past with personal computers, and that the auto industry will therefore face major structural change, with ICT companies coming into and taking over the industry, and these claims may seem plausible, I myself am not convinced. That is because cars, which are entrusted with people’s lives, have evolved constantly over the past 100-plus years, and even the individual units that make up cars are aggregations of complex functions, aggregations in which controls and operations, and software and hardware, work together in superb fashion. So, it is very hard to imagine that the value of these units will simply be replaced by network value.
The increasing implementation of electronics in cars
The first real use of electronic controls in cars took place back in the 1970s. In response to the Muskie Act in the US and other emissions restrictions, cars were equipped with electronic control units (ECUs) that used micro controlling units (MCUs) to control the engine digitally. Then, in the 1980s, there was heightened demand for safety and comfort in cars, so ECUs came to be installed in a large number of places other than the engine, such as the transmission, the suspension, digital meters, the air conditioning, and side mirrors. In the 1990s, many models were equipped with car navigation systems, which became quite widespread and gave cars telecommunications functions for the first time. Then cars came to be equipped with a variety of sensors, making them even more multifunctional. In addition, at the end of the ‘90s, hybrid vehicles appeared and cars’ motors began to be driven electrically. As these implementations of electronics were moving forward, there was demand for the electrical and electronic systems in cars to be reorganized, onboard LANs came into use, and the internal connectedness of cars advanced. Since the year 2000, the telecommunications functions of cars have been increased further, infotainment functions have become more and more common, and the connectedness of cars with roads and other infrastructure has advanced due to intelligent transportation systems (ITSs) and the above-mentioned VICS. Cars today are able to remain connected constantly, like smartphones and tablets, and cars are now connected to the outside world in a major way.
As I have explained here, as cars’ functions have become more advanced and their hardware has become more electronic, the software incorporated into these systems has rapidly become more important. The number of lines of code in the software in cars has increased dramatically, from 1.0 million lines in the year 2000 to 100 million lines — or 100 times more — in 2016. The number of lines of code in cars is now equivalent to four times what is found in an F-35 fighter. And it is said that as the CASE trend continues, the number of lines of code will increase to 10 billion.
As a result of these advances in implementing electronics in cars, the electrical and electronic elements in a car — including software — now account for the majority of the value of the car as a whole. In other words, cars have undergone a major change, from being mainly made up of mechanical elements, hardware, and units to being mainly made up of electrical elements, software, and systems.
Onboard networks
As electronics have come to be used more and more in cars, the number of ECUs in cars has increased rapidly, and it is said that cars now come with more than 100 ECUs. In addition, the individual ECUs have been made larger in order to increase their information-processing capacity. As the implementation of electronics progressed, the sensors, ECUs, and actuators that made up individual operational systems, and the wiring between those systems, became much more numerous and also more complex. As a result, it became necessary to organize the inside of the individual car as a network, replace wires with harnesses, and reorganize things. Then, in 1985, Bosch announced its Controlled Area Network (CAN). CANs came to be used in cars in about 1990, and in 1994 the ISO made CANs the international standard. Currently, almost every car comes equipped with a CAN.
A CAN is an in-vehicle LAN communications protocol developed for use in cars. What is most significant about CANs is that with them, controllers and devices in the car are connected without passing through a host computer. Car users’ preferences and applications vary quite widely; not only do people select and combine options at the time they buy a car, they also want to be able to add on standard options later. It is in order to provide this kind of flexibility that CANs are used, since with a CAN, the control functions in a car are not centralized via a host computer but instead distributed to each ECU.
Today, CANs are used in a variety of in-vehicle applications, such as powertrain systems, vehicle control systems, body control systems, and information systems (except for car navigation systems, which require high-speed communication).
However, what is expected of cars today is very different from what was expected of cars in the 1990s, when current CANs began to be used in cars. As cars come to be more and more electronically controlled, there are limits to the advances that can be made in a distributed system that relies on the information-processing capacity of individual ECUs. What is more, functions themselves are becoming more diverse. In particular, advanced driver-assistance systems (ADASs) are now being used, more importance is being placed on connections between the functions within individual units in cars, and the configuration of onboard networks needs to change to satisfy demands for connectedness between cars and the outside world. Manufacturers are considering abandoning the concept of a simple aggregation of distributed units and, in its place, reorganizing everything once again by creating a system that is structured as an architecture, centralizing control in each of the onboard applications (such as those described above), and putting a central processing unit in each application.
The evolution of software in computers
Computer “hardware” refers to everything in computer equipment that is visible. However, hardware is used by incorporating software into it; the hardware and software mutually complement each other, and together they constitute a computer system. And “software,” incidentally, is defined as “an intellectual creation — that includes programs, procedures, controls, related documentation, etc. — for the purpose of making a data-processing system function” (JIS’s “Glossary of Terms Used in Information Processing”).
Reading over the history of computers, one finds that software initially was provided free, as an accessory to the hardware. However, computer systems became more advanced, and as the hardware was becoming more advanced, the software that drove the hardware was also becoming more advanced. Finally, IBM proposed that the two be unbundled, i.e., that they be priced separately. It was in 1968 that IBM made this proposal.
After that, software began to be differentiated into system software (the operating systems — OSs), which handled basic control functions, and application software. The result was that if machines were running the same OS, it did not matter whether their hardware was different. When the age of personal computers arrived, Windows became the overwhelmingly dominant OS, so hardware became commoditized, and the source of added value shifted to software. And Linux, a free, open-source OS that was intended to rival Windows, also evolved and became more widely used. Thus, application software satisfying the demand for various applications was installed on the OS by means of an interface that was commonized, and computers turned more and more into platforms.
In addition, at the end of the 20th century, Sun Microsystems developed and rolled out the Java programming language, making it possible for programs to be created that did not depend on any specific OS platform. This signaled the beginning of an era of truly open platforms using the Java application programming interface (API). Because it was now possible to make certain software functions usable externally by publishing them as APIs, outside developers were able to imbed these functions in their own software without developing programs on their own, and applications were also able to work together. Both Amazon and Twitter greatly expanded their business through the use of open APIs.
APIs are also already playing an active role in the world of mobility. For example, Uber has need of a variety of functions, i.e., maps, phone calls, text messages, and payments. By means of APIs, Uber uses the functions of Google’s Google Maps for its maps, uses the functions of Twilio for calls and text messages, and uses the functions of PayPal’s Braintree for payments. Thus, the companies that provide these open APIs are providing their services to many companies other than Uber and enhancing their position as platformers of these services and functions.
The above is a review of the process by which computers and ICT technology have evolved. The process can be summarized in the following steps:
- Prices for software came to be shown separately (unbundling).
- Individual software applications came to be differentiated.
- OSs and application software came to be differentiated, and computers turned into OS-centered platforms.
- Open platforms via APIs took off.
It seems likely that as the share of added value in cars that is due to electrical and electronic elements increases, a similar sort of evolution will take place in connected cars.
Cars are being systematized
Turning our attention back to cars, as I wrote above, the independent value of cars has evolved from mechanical elements, hardware, and units to electrical elements, software, and systems. Nevertheless, it remains the case that these two sets of things are mutually complementary, and that together they make up a single system.
Although the total can vary depending on how you count them, it is said that altogether there are about 40,000 parts in a car. At one time, each part in a car was manufactured separately and then modified differently for each model so as to end up with an integral system. Similarly to what has happened with other industrial products, however, the concept of a car being a complex structure consisting of a jumble of functions and component parts came to be reconsidered, and cars got divided up into a number of subsystems. And, as I touched on above when discussing CANs, each subsystem has its own recognition, decision-making, and operation functions. Today’s cars have a closely fitted, two-level structure, consisting of an overall architecture and, within it, modules that control subsystems. The pioneer of this architecture/module structure is Volkswagen’s MQB architecture, in which roughly 70% of the 40,000 parts in a car are integrated into approximately 500 modules, and each module is standardized; as a result, Volkswagen is increasingly commonizing its vehicles across different models and chassis. And in the architecture/module structure, each module is made up of software, which is in charge of control, and hardware that consists of actuators and a foundation. Incidentally, this architecture/module concept is similar to structural theory used in ICT. In other words, as cars, like computers, become more connected, both their actual structure and the theory underpinning that structure are getting transformed along ICT lines.
The structure of cars in the age of the connected car
As cars become more connected, hardware and software will become more and more clearly separated in cars, too. This is taking place much later in cars than it did in ICT, since it is occurring 50 years after IBM became the first to unbundle software, and even more than 25 years after the rollout of the Windows OS caused a real separation between hardware and software. This, too, shows how complicated cars are. As ICT technology evolves at an exponential speed, a separation between software and hardware cannot be postponed any longer: over-the-air (OTA) operations that update a system by sending software to the car via wireless, without any change to the hardware, are expected to be officially approved for 2020 in laws and regulations.
In addition, as cars become more connected, the amount of data and information that cars process will increase dramatically. To deal with the increase, contemporary CANs are undergoing structural changes so that ultimately they will no longer have their current distributed structure but instead a centralized structure in which onboard applications are (to a certain extent) integrated individually and then bundled together centrally. And this change is moving ahead in sync with the change to an architecture/module car structure. In short, progress in connectedness will be driving modulization, and then standardization and commonization.
Using data from connected cars in business
Earlier I discussed the example of Uber’s business model and the APIs. That example illustrates the way that insurance, parking facilities, medical institutions, e-commerce for services and products, logistics services, public services, etc., are now built into platforms for mobility services by means of connected-car technology. All of these services are aiming to capture information and data on drivers and mobility via connected cars and thereby increase their efficiency and — by combining with other services — become more advanced and add more value. Even in the world of cars and mobility, it is absolutely true that data is an important resource for future business growth.
From the standpoint of the protection of personal information, automobile manufacturers, suppliers, etc., are not free to use as they wish the data generated in cars via the onboard ECUs in the CAN. However, if, for example, the user agreement for a car navigation system, etc., contains provisions that permit data to be used for certain purposes, then if the owner or driver of the car agrees to those provisions, the company will be able to use the data.
In addition, the 2017 revisions to the Act on the Protection of Personal Information cleared the way, under certain conditions, for data to be provided to third parties without the consent of the individuals involved so long as the data is “anonymously processed information,”, i.e., it has been anonymized so that no specific individuals can be identified.
In this way, the data generated in cars via the onboard ECUs in their CAN represent, for automobile OEMs, an important business resource that only they are able to obtain, one that will bring about service differentiation and the creation of new business models, and the OEMs have kept their CANs extremely closed in order to prevent the data from being captured by GAFA or other parties. Nevertheless, APIs are being used more and more in the automotive field, too, and as platforms are becoming more open, the relationships between GAFA and Japanese automobile OEMs are not becoming thoroughly antagonistic but are instead moving in the direction of becoming somewhat closer and more cooperative.
(To be continued)
