Menu
03 Mar 2023 | 4 min read
In our first opening chapter about Adapter we showcased the capabilities of the software solution that 2hire is offering, and we launched an initial lure into the world of standardization of all the different OEMs in the market to enable connected services providers to communicate indistinguishably with all these OEMs. Today we thought we would put a spotlight on Adapter’s technology stack and dive a bit deeper into how Adapter’s architecture actually works.
Adapter is the layer that enables communication between vehicles and end users. This cloud-based technology handles interactions from thousands of users engaging with thousands of connected vehicles all over the world. But how exactly does Adapter work? Let’s take a closer look at its components and mechanisms in a light-hearted way!
You might think that Adapter is just one piece of software, but it is actually a cluster of microservices working together to expose a unified and compact interface. There are around 20 different services that contribute to the Adapter architecture, and they’re growing very fast.
Let’s go over the microservices composing Adapter:
The ALB is a very common component in many of the services we use every day on the internet. Its responsibility is to distribute request loads over multiple replicas serving your application.
It’s crucial to ensure that the system can handle the high volume of incoming requests, particularly during peak times, by balancing the load evenly among the replicas. This not only improves the overall performance of the system but also provides a failover mechanism in case one of the instances goes down.
The API Gateway is the second component in the pipeline for communication between users and vehicles. It acts as the gatekeeper for incoming requests from the end-user. It’s responsible for checking the authentication of each request, verifying the user’s identity, and forwarding it to the correct sub-service within the Adapter. The API Gateway also performs other security-related functions, such as rate limiting and request throttling, to ensure the overall security of the system.
This macro-category (yes, Adapter in Adapter) is the heart of the Adapter service and refers to all the services that enable specific vehicle integrations. Right now there are around 15 different services under this category, including integrations with original car manufacturers such as Stellantis, Ford, Toyota, third-party providers such as E-GAP, Reefilla, WashOut, as well as the most important integration which is our proprietary 2hire box. The Adapter services form the core of the Adapter architecture: each service handles the communication with specific vehicles, processing the incoming commands or signals and forwarding them to the correct destination.
Like our 2hire box, even other integrations require a direct connection with the vehicle rather than through provided API services. The Gateway service handles direct communication with the vehicles, managing every aspect of it, from protocol connections to encoding and parsing messages.
The Webhook Publisher service closes the loop by forwarding all information from the vehicle to the end-user. The forwarded data is usually received and handled either by third-party services or our own Sharing service, which processes the data to make it available to the end user through their app.
To understand how the different services within Adapter interact with each other, let’s take a closer look at the two communication flows: from the User to the Vehicle, and from the Vehicle to the User.
When a User interacts with a Vehicle through their app of choice, the message is sent over to the cloud and routed to the Application Load Balancer (ALB). The ALB distributes the user-generated message load to the correct service replica. From there, the message is processed by the Api Gateway. This service acts as a checkpoint, verifying the authenticity of the message and directing it to the appropriate Adapter sub-service.
The selected Adapter then processes the command and forwards it either to the Provider API, if the message is meant for a third-party service, or to our proprietary Gateway service, if the message is meant for a vehicle powered by the 2hboard or another directly connected vehicle.
On the other end, depending on the connectivity provider, the vehicle data is either received through directly connected webhooks that pass through the ALB, or through the Gateway service that handles the communication specification. The parsed messages are then sent to the corresponding Adapter Service, which performs any necessary processing. This could include exposing command responses and received signals, such as generic signals for common usage or specific signals for the vehicle family or group.
Finally, to forward the vehicle data to the end-user, the Adapter services utilize the Webhook Publisher service.
This software gathers the vehicle data and makes it available to the end-users by sending it to any service or application that has subscribed to the Adapter webhook service.
Adapter is a complex piece of technology that handles the communication between vehicles and end-users. It’s composed of multiple microservices working together to provide a seamless experience for the users. Each service plays a unique role in the overall architecture, ensuring the secure and efficient delivery of information between the vehicle and the client. Adapter’s robust and flexible architecture enables it to accommodate the ever-evolving needs of the connected vehicle industry, making it a critical component in the future of transportation.
Senior Engineer at 2hire
Computer engineer with a passion for art. When not coding, you may find me painting, reading, binge-watching tv shows, or, most probably, sleeping.
