The tricky road to autonomous cars

The moment is a turning point for autonomous cars. Automakers and tech companies are still dealing with major problems. Spindox’s vision of the data layer.

The first race for autonomous cars took place last week in Buenos Aires. The competition, named Roborace, occurred between two vehicles, one of which crashed before the race ended. Can we regard this episode as the epitome of the current state of self-driving car? Are we driving too fast?

Autonomous cars are communication machines

Driving a car is communication. When you drive, you interact with many elements: the car itself, other cars, the environment (road, weather, …). In this regard a self-driving car is hypercommunication. An autonomous car is not “autonomous”: it interacts with the context even more than a traditional one. It interacts with more elements, more frequently, and faster (basically real-time).

So we better start thinking of a car as a SIM-based device. The engine is no longer the heart of a car. Even more: the car will no longer be the heart of the automotive company. By the way, on January Tesla officially changed its corporate name from “Tesla Motors” to “Tesla Inc.” Does it mean something?

As every other complex communication system, autonomous cars generate a huge amount of information. We talk about two sets of data. One is produced by the car itself, the other by people traveling with the car: data about users’ journeys and behaviours. In 2016 Chevrolet collected 4,220 terabytes of data from customer’s cars.

According to figures by Intel, an autonomous car will be generating approximately 4,000 GB — or 4 terabytes — of data a day, the data equivalent of almost 3,000 people. It is no surprise that Intel is investing $250 million for autonomous driving.

Connected cars need to play with a smart environment

We can certainly agree with a statement in the recent IDC PlanScape Collaboration Between Automotive OEMs and City Leaders for Implementing Connected Car and Smart City Solutions:

Automotive OEMs and smart city leaders will need to work closely to ensure the continued development of, and support for, connected car capabilities and services such as vehicle-to-vehicle and vehicle-to-infrastructure communications that will increasingly include autonomous operations.

By 2017 worldwide spending on connected vehicles will be $29.6 billion. In the same timeframe government spending on intelligent transportation systems will be $16.5 billion. There is a clear interplay between the two figures.

The question is: are smart city programs considering the integration of autonomous cars into the roads of the future? Mostly no. However auto manufacturers are focusing more on the technical self-sufficiency of their vehicles.

The competition between tech companies and auto manufacturers

Despite their capacity for innovation, tech companies like Google, Apple, Uber, and even Tesla are understanding of how hard is the move to mass production. On the other side, traditional manufacturers, including FCA, launched significant in-house programs. Tier 1 suppliers like Delphi are in the track as well.

Now we know that Google and Apple are not making cars in the future. This doesn’t mean that they are going out of the auto industry at all. There’s still a lucrative business for them: accessing and managing car-based data through artificial intelligence technologies. According to McKinsey, this could be a $450 to 750 billion market by 2030.

How will the new scenario affect the evolution towards autonomous cars? We should expect things will proceed slower than we thought up until very recently.

But another important paradigm shift involves ownership. Companies like Uber and Lyft are the center of the movement toward self-driving cars. Conversely, if we stay with the current personal car ownership model, everything will happen much more slowly.

From a technical perspective, many issues are still unresolved. Some of them relates with hardware and sensors. For instance, in many difficult situations, such as snow, foggy or icy roads, autonomous vehicles are not able to ensure a safe experience. In particular, rain and fog can interfere with LIDAR, a sensing device that bounces laser light off surrounding objects and build a 360-degree picture of the environment. Tech companies and auto manufacturers are studying alternative solutions, some of which are based on a common philosophy: mash collaboration between vehicles.

This brings us to a further open point: which standard are we adopting to provide wireless communication to the car? Short-range ad hoc networks (vehicle-to-vehicle) or 5G GSM? both are contenders.

But Spindox is focusing on a different aspect. We are looking at how to support an efficient and secure data management process within the autonomous car ecosystem. And we see it as part of a broader problem, that typically affects the IoT world: how to handle complex, vast, and fast-moving flows of information through the pipeline. I will take up this point at the end of the story.

Spindox collaboration with CRF in Trento

In Trento Spindox is partnering with Centro Ricerche Fiat within the program named “Digital Vehicles on Digital Road”. The program focuses on the relationships between car digital capabilities and the road infrastructure, both physical and digital. Since the final objective is to define the model for a coordinated ecosystem, many stakeholders are involved.

Overcoming a car-centric vision of mobility and thinking about the interplay between cars and their environment means that communication is not just for the sake of the car. It is at the service of mobility. In this scenario self-driving cars are much more than independent actors dealing with the traffic flow. They became instruments for the coordination of mobility. In a way, we can say that autonomous vehicles not only drive themselves. Thay share what they know in order to drive a smarter and safer mobility ecosystem.

Between Torino and Detroit

Spindox is also cooperating with the automotive industry in Torino and Detroit. The goal here is to define a conceptual framework for the communication between car, infrastructure and environment. We have already argued that a smart car is hypercommunication: a lot of data are continuously flowing from and to the vehicle. But to what extent can unmanned vehicles trust communication to make their own decisions? In other terms, how autonomous will be autonomous cars, once they reach the so-called “fifth level of autonomy”?

We understood that a self-driving car must be able to operate properly regardless of the infrastructure. No communication system is enough efficient and effective, at the present time, to encourage the idea of a car that entrusts its decisions to a remote platform. The role of the infrastructure is to provide reliable ad useful information about traffic, weather conditions, parking availability and so on. But at the end of the day, the final decision is up to the car. And the car itself must be able to make its decisions in any situation, even if it is not connected.

From a technical standpoint we have to manage three major areas:

– transport layer

– messaging pattern

– delivery platform

GSM is nowadays the only reliable network for the transport layer, due to its capillarity worldwide. Over the transport we see another standard that is emerging: the MQTT message protocol. It’s an event-driven, binary protocol, very efficient, light and scalable.

However different strategies can be implemented to address problems with communication in autonomous cars. They include fog computing (the car itself becomes a small data center, where most of workload is installed), shadowing (communication takes place between on board systems and a copy of them in the cloud: a double, which operates as an intermediary), mesh networks.

A lot of confusion still remains about the delivery platform. Car manufacturers are confronting with different philosophies. Some of them are more innovative, but sometimes the auto industry looks at these solutions with suspicious. An interesting platform for scalable deployment of secure connected car services is provided by Mojio, funded by Amazon, Deutsche Telekom and others. Elektrobit, a wholly owned, independent subsidiary of Continental, developed a similar solution called EB Connected Car. Another company, CloudMade, is providing content for smart vehicles, map data enrichment and car & driver analytics. Even more focused is Civil Maps, which provides cognition for autonomous vehicles, enabling them to crowdsource a dynamic 3D map for safe driving: a context engine and augmented reality tools are used to create rich maps that enable autonomous cars to traverse any road safely and comfortably without any human intervention.

Containers and microservices

Spindox has been working hard, over the last year, on the data flow management layer. We are applying our framework to many contexts, including the autonomous cars ecosystem. It is well known that traditional 3-layer architectures don’t provide the right answer in the context of mobile, IoT and social applications. Even if stateless, traditional architectures don’t scale. Or, when they scale, the do it at high cost.

The answer is distributed computing. But distributed computing poses serious challenges from a technological point of view, both on a physical and a software level. We believe containerization can address these challenges, offering a new paradigm for virtualization. We move from a vertical schema (every virtual machine executes its operating system) to a shared one (containers share OS and bin/lib directories): each application is self-contained and consumes part of host’s physical resources, with no dependencies.

Containerisation requires a new approach to software design, based on microservices. In reality, the paradigm is not so new: microservices are as old as Linux is. But they went into new life with containers. We should point out that a microservice is not merely a “very small service”. It is a discrete piece of logic, with narrow functional boundaries: each service does just one job. Applications become modules, or workloads.

Self-containment is a great advantage of microservices: it assures a stronger control on quality of software and an easier deployment. The same artifact can be moved from development, integration, staging, and production tiers with no changes. Even better if you develop isomorphic code, that can run both in the server and the client. Furthermore you can have multiple instances of the same artifact.

The central nervous system

Microservices solve many problems, but create new ones. The two major issues within a distributed architecture are related to orchestration and observability of a lot of self-contained, specialised modules.

Spindox designed a new kind of message bus, acting as a universal mechanism for communication between the microservices. We can see it as a sort of central nervous system, because it has many conceptual similarities with human bone marrow. In our body the marrow is the orchestrator and neurones are the microservices. Synapses are the connections between the modules, that in our model communicate using plain text format on TCP. More properly we can call it a real time stream processing engine.

We see a lot of advantages in this solution. First, you get a complete decoupling between parties. Services are single-threaded and communicate only for data structures (plain text over TCP, as already said). Basically, they share nothing. This is a valid alternative to concurrent programming, multi-core, and hyper-threading approaches, based on array conditions.

Our engine addresses scalability and software lifecycle efficiency as well. Software design is more efficient, because it is partitioned in functional boundaries. You get parallel concurrent development, more code reusability, and technology independence (in fact every technology can send and receive plain text with TCP), easier running, easier maintenance.

The real time engine is designed for large-scale data processing, providing instant feedback to any request. Data are collected through different connectors and ingested. The gathering module includes several streams of events, like a pipeline system. Flows are defined in a similar way of MapReduce.

Data are enriched, aggregated and triggered in the real-time processing module, and delivered for consumption. The module, highly scalable and maintainable, is controlled through a rule engine separated from application code. Rules and process models are changed using a high-level language. The engine supports cross host architectures, as well as cross datacenter and even cross provider.

Finally, the consumption provides a business oriented instant feedback to the user, in the form of dashboards and other real time applications. Think about trading, safety, telemetry, and other use cases. And autonomous cars, of course.

[This post was originally published on Spindox.it]