Projects

Vehicle testing is an important part of the development cycle in automotive development.

Due to the large number of control units and communication systems in the vehicle, a very large amount of data is generated that must be analyzed afterwards in the event of an error or undesirable behavior.

Therefore, a data logger is installed on test drives that records all communication.

A small team designed a data logger that can record several

• CAN
• Flexray
• LIN
• Ethernet
• MOST
• Analog channels

Three Infineon TriCores, an FPGA, a CPLD and an embedded PC were installed. The data was stored either on a CF card or SSD.

The development of safety-critical control units according to standards such as ISO 26262 or ISO 13849 requires extensive and complete documentation at all levels.

If the firmware is then written and managed in a modular manner, e.g. to have a high reuse factor between control units, the number of documents required can run into the hundreds.

It is very difficult to keep an overview of which documents are in which state and which versions belong to a package.

A Confluence dashboard was therefore created that loads, processes and displays current data from the requirements management system every day.

This includes, for example:

• Document Status
• Review Status at item/requirement level
• Test Coverage
• Status of test execution at item level
• Calculation of a score value per document for a traffic light display

The application was written in Python and executed daily using Jenkins jobs. The content in Confluence was uploaded via the REST API. The page was designed so that only certain areas are automatically filled and the layout of the dashboard can be created using the Confluence web editor.

Overall project management of a customer project for the development of a CAN-Ethernet gateway in the agricultural machinery sector.

Support from specification drawing up to series acceptance.

• Project scope >2 million €
• Team size approx. 15 people in hardware, software and testing
• Development according to ISO 13849

Overall project management of a customer project for the development of an overload protection ECU in the construction machinery sector.

Support from specification drawing up to series acceptance.

• Project scope >1 million €
• Team size approx. 15 people in hardware, software and testing
• Development and certification according to ISO 13849 Pl c and IEC 61508

Requirements management systems are very well suited to recording requirements, breaking them down for all disciplines and linking them to tests. Versioning of documents is often also supported.

If certification is sought or documents must be exchanged with customers and partners, a PDF export is required. This must always look the same, regardless of who exports and when.

However, some systems can only export Word documents, which requires some manual processing steps.

A tool was therefore developed to automate all manual steps and create a reproducible PDF.

The program was written in Python, with PySide6 as a graphical library and communicated with the requirements management system via a REST API and with Microsoft Word via the COM interface.

Electronic products must pass a wide range of environmental, EMC and electrical tests before they can be placed on the market.

Many of these tests have a processing time of several hours to days.

To ensure that the test items do not have any errors or failures, the test sequences were automated using LabView and the devices were continuously monitored via XCP.

After the tests have been completed, test reports are generated for each test item and marked with a PASS or FAIL.

Maintenance of existing products is a crucial point for customer satisfaction. The older a product is, the more likely it is that the tools used are long outdated and no longer available to developers. Ensuring that all necessary artifacts are created and packaged for a customer release is also an important point for delivery quality.

Therefore, it is helpful to create a virtual environment in which the software necessary for debugging and creating firmware is available.

To enable automated creation and testing of an older product, the build environment was mapped in a virtual machine. All processes for creating the firmware, documentation, tests and their execution were implemented in Jenkins Pipelines.

Developers only have to check in new code to get a release-ready package.

Many vintage car owners value an original appearance. However, they also don't want to do without modern amenities, such as a radio with Bluetooth and a modern amplifier. In US vehicles, there is also the fact that most radios often only offer AM reception, which makes them useless in Europe.

As a solution, a radio is often installed in the glove compartment or hidden somewhere else.

With the vintage car radio, this is no longer necessary. The inner workings of the radio are replaced by modern electronics, while the original controls are retained.

Switching between radio and Bluetooth is done by selecting the frequency, which means that, for example, Bluetooth mode is active instead of the frequency 87.50 MHz. The frequency band is shifted accordingly so that no frequencies are lost.

The radio has a modern amplifier with 2x30Wrms output power and can be operated in stereo or mono.

A display is not absolutely necessary, but an LCD/OLED/ePaper display can be installed to show RDS data and the current artist and title.

The fuel gauge in my vintage car never showed the right value. The main reason for this was that the fuel sender and the display didn't match.

The fuel gauge works electro-mechanically with a wrapped bi-metal strip through which a current, limited by the fuel sender, flows and thus heats the strip. The heating causes the strip to bend and move the fuel needle.

In order to properly calibrate the system, a small electronic device was inserted that reads the resistance value of the fuel sender and allows a current to flow through the wire around the bi-metal strip.

The ATtiny402 used has characteristics for converting resistance value into tank level and level into output current stored in the EEPROM.

The characteristics can be set in the vehicle. The ATTiny can be used to communicate via UART and the characteristics can be read/written and the live data can be read out.

Using a PC application written in Qt/C++, the characteristics can be calculated and transferred to the electronics.