A car as eye-candy? We will use a showcase to demonstrate how modern car services are created in the software-defined vehicle. Knowledge of E/E architectures and AUTOSAR is essential for in-car software development. The end result is a car with personality. Take a look under the hood with us.
I wrote a post about the importance of the new E/E architectures for the software-defined car some time ago. Without modern architectures, the path to the digital car would be rocky, and the management of in-car software for new services time-consuming.
In this post, I would like to approach the topic of in-car software from a different angle - the practical one. E/E architecture as a solution sounds great, but it tells us little about the specific components needed to develop and operate in-car software. And most importantly, what capabilities does it need to have?
We used a showcase to demonstrate how two typical application scenarios for modern car services can be implemented with the help of exterior lighting (entry and exit). – At the same time, we also wanted to take advantage of the possibilities offered by modern hardware such as matrix LEDs. It is, therefore, not a simple act of switching the vehicle lighting on and off, but rather a small lightshow that follows a predefined choreography. In our case, the animation starts at the rear of the car, goes around the car several times, and finishes with a seductive glance at the front headlights. Besides the emotional entertainment effect, the solution also has some practical significance: it makes it easier for the driver to find their way from and into the car in the dark.
But there was still far more to it than these two scenarios. We knew we also had access to sensor data that records information about people near the car. We decided, therefore, to add an anti-theft device.
We used real situation examples and first designed a hardware/software architecture based on common components, which served as a guide for the complete showcase, one which extends well beyond development. We wanted a car with our embedded software on board.
Modern E/E architectures provide for one (or more) higher-level control unit(s) to implement service-oriented architectures. These central control units are nothing more than powerful computers. The necessary control software for the car is stored in libraries on these computers. These libraries service individual functions in the car and access the relevant microcontrollers (MCUs). AUTOSAR, the Automotive Open System Architecture, has been used as a standard library for functional software for some time.
In our case, the microcontroller MCU PSoC 5LP is particularly relevant to the outdoor lighting, including the headlights. . It turns our LEDs on and off with pinpoint accuracy, and it "coincidentally" also manages the proximity sensor that detects if a person is near the car. With a suitable library, i.e. in-car software, we can determine when and how the controller switches the light on and off. If the AUTOSAR Classic does not have such a library, developers can easily add it, which is pretty much what we have done.
We used a development software called AUTOSAR Builder for this purpose. After determining the exact specifications for the scenario-specific animations (e.g. lighting duration, LED lighting sequence, control of the matrix LEDs for gesture simulation), we programmed the new functions quite conventionally in C or C++. The AUTOSAR Builder compiled the code to be compliant with the AUTOSAR library on board the vehicle. This completed the development part of the system. This software could now be added to the on-board library with the next software update of our car. While the easiest way to do this would be an over the air update, we decided to copy our library directly to the MCU using a laptop.
The next step was to find a car which we could use to test our development. We decided to go with Audi Q2. Not a real one, but 1:8 scaled model, measuring 22 x 52 cm, which was equipped with the necessary technology: first the vehicle lighting in the form of individually addressable LEDs (addressable 5V RGB LED strips for the rear and 11x7 Matrix breakout LEDs for the front). These LEDs are widely used; they can be found in similar form in many modern vehicles today.
The LEDs were soldered to the MCU PSoC 5LP, which takes over the control. Nevertheless, PSoC is not directly addressed in reality. There is also a type of concierge that takes care of the connection to the outside world and the processing of the input and output signals, which is the MCU ESP32. Once we added it, the E/E setup for our showcase was complete.
ESP32 functions as a gateway into the car, which can be accessed using cable or Wi-Fi. At the same time, it has an integrated web server, which in turn can be addressed using a standard browser or CANoe (a test and development software). This was enough for us in the laboratory to trigger the functions. Et voilá - everything works: Light becomes a service with the help of software.
In the real world, lighting control depends on a variety of input signals, such as door status ("front left door open/closed"), terminal status ("ignition on/off"), or vehicle lock/unlock. Typically, however, the driver triggers the animation by pressing the car key - and the whole world of on-board hardware and software remains "under the hood".
Developers of in-car software not only need expertise in software development, they also need to be familiar with modern E/E architectures. In particular, they need AUTOSAR expertise. It is also crucial to take security aspects into account.
In fact, there are at least two other parameters that are relevant to the success of a professional in-car software project: The development team must think beyond just the control software in the AUTOSAR library. Additional code may be required to make AUTOSAR work with the hardware. What is more, the code needs to be tested in different scenarios.
This showcase will show you how in-car software is developed and what needs to be taken into account. If you are planning relevant projects, talk to us and let us walk together on the path to the "software-defined car". It does not always have to be just an eye candy for the car.
