While our development test vehicle continues to accumulate kilometres, the digital infrastructure of the TWIKE 5 is evolving as well.
Over the past few weeks, we have therefore integrated our first AutoPi into the test vehicle, establishing a mobile data connection to the vehicle.
The current test setup is still decidedly pragmatic – cables, antennas and the gateway are clearly visible between the sidesticks and the rest of the test equipment. But its purpose is all the more interesting: for the first time, it creates a wireless bridge between the TWIKE 5 and the outside world.
First things first: the wireless connection
The first step is deliberately simple.
The AutoPi is connected to the vehicle and can, in principle, read data from the TWIKE and transmit it remotely via the mobile network.
We have now established exactly this connection for the first time.
At this stage, we are not yet recording extensive measurement data or performing remote diagnostics. The next step will first be to define and connect the required vehicle data, interfaces and applications.
But the technical foundation is in place:
For the first time, the TWIKE 5 has its own communication channel to the outside world.
From remote access to TWIKE Commander
This connection becomes particularly interesting when we look ahead to the next development steps.
The same technical foundation could in future be used to read selected vehicle data, transmit it and make it available for a variety of applications.
Our working title for this potential functional layer is:
TWIKE Commander.
We are explicitly not interested in putting as many functions as possible online simply because it is technically possible.
The Commander should provide genuine value wherever a connection to the vehicle makes sense.
Possible applications could include information on charging and vehicle status, selected consumption or driving data, diagnostic information, or functions relating to the charging process.
Which of these functions will actually prove useful and eventually become part of a potential production package is something we do not want to determine solely from behind a desk. Technical possibilities, our own ideas and, above all, the requirements of our future pilots should come together in this process.
Not an IT project for the pilot
One point is particularly important to us.
If TWIKE offers a Commander as an option, the customer should not have to turn it into their own IT project.
A potential basic package should therefore already provide a clearly defined and immediately usable range of functions. Ideally, the technical installation would already be complete and the pilot would simply set up their personal access.
Log in. Set up access. Connect TWIKE.
Done.
However, when energy management enters the equation, things quickly become more individual.
One person simply charges from their wallbox. Another wants to use as much of their own solar power as possible. Someone else may already have a basic electricity meter, an energy management system or an existing home automation setup and would like to incorporate its information.
Here, we deliberately want to distinguish between two levels.
TWIKE provides the foundation – extensions remain open
The basic package should function independently of any additional home automation and already provide genuine value on its own.
Anyone wishing to go further could later connect the Commander to additional components within their personal energy environment.
One possible example would be the integration of an existing electricity meter or energy monitoring system. In the future, this could allow the TWIKE to recognise when excess self-generated energy is available in the home and use it more selectively for charging or intermediate storage.
TWIKE does not need to integrate every conceivable smart-home system itself.
Instead, we could recommend proven interfaces and components while creating an open extension layer in which technically interested pilots can develop additional solutions and share their experiences with one another.
The basic system remains simple – and those who want more are given room to expand it.
Thinking of vehicle, energy and pilot as one system
This is where the topic becomes especially interesting for us.
The TWIKE 5 has been designed from the ground up for very low energy consumption. The next logical question is therefore no longer simply:
How much energy does the vehicle require?
Increasingly, it is also:
When is that energy available, and how intelligently can we use it?
A vehicle with comparatively low energy demand can be integrated into a decentralised energy supply much more easily than one with very high consumption.
In the long term, this means the TWIKE Commander could become much more than just a remote connection to the vehicle.
It could become an interface between mobility, energy and the pilot’s personal everyday life.
The first signal is already live
At this early stage of development, we do not yet have a finished list of functions. What we do have is the technical connection.
The AutoPi currently installed in our development test vehicle provides the first test platform for this. Which data we will use through it in future, which functions will emerge from it and how a future TWIKE Commander could ultimately be integrated into the production vehicle will be defined in the next development steps.
The wireless connection itself is already working.
And that means we can now begin answering the key question:
What should a TWIKE Commander really be able to do for you?
Let’s TWIKE!
Header Image source: AutoPi – AutoPi CAN-FD Pro
