Architecture of Qt Embedded Systems: Operating Conditions

Operator conditions like light, temperature, water, dust and vibration are a rich source for constraints and qualities of a system architecture. They affect the SoC, display and connector selection, the touch gesture recognition, the communication between system components, the cabling, the use of a window manager and more.

Introduction

In the initial post Gettting Started of the series on the Architecture of Qt Embedded Systems, I posed over 50 questions in seven areas – without answering them. In this post, I’ll answer the questions for one area: operating conditions. My running example is a fictitious driver terminal for a harvester architected in 2021.

Harvesters must run day and night on the field – best with no down times. They must do their job in the summer heat of Italy and the winter cold of Russia. Terminals must cope with dirt and the inevitable coffee spill in the driver cabin. The terminals cable connectors must withstand the vibrations from the field work powered by a 1000 horse-power engine.

Looking at different operator conditions has important architectural consequences and gives rise to architectural significant requirements (ASRs, for short) – especially to constraints and quality attributes (qualities, for short). Operator conditions heavily influence the hardware selection and the software architecture. We’ll unearth a constraint and several qualities by considering the influence of light, temperature, water and dust on Qt embedded systems.

Light

Some years ago, I had a Ford Mondeo as a rental car for a month. When the sun shone outside, I couldn’t see anything on the display. And the sun didn’t even shine directly on the display. I can easily read the display contents in my BMW under the same conditions. Readability is reduced slightly when the sun shines directly on the display. If Ford had tested the displays in typical lighting conditions, it would have avoided this slip-up.

The harvest period is short with 4-6 weeks. Agencies rent out the expensive harvesters with drivers to the farmers. Hence, the harvesters run at day and night – nearly 24/7. At day time, sunlight must not wipe out the display. At night time, the display must not be too bright. The driver would have difficulties to adjust to the high contrast between the display and the field.

Harvester cabins sport multiple displays, because there is too much information for one display. Two displays are pretty much the rule. Three or four displays are not unusual. The main display is attached to the end of the armrest. Additional displays are attached to the left or right front beam at 1-2m height. Hence, the displays must have a wide horizontal and vertical viewing angle. They should also have filters to reduce reflections.

These considerations give rise to the following quality attribute, where the lighting conditions define the specific operating context:

Quality – Readability in different lighting conditions. The display must have a brightness of at least 1200 nits, a contrast of at least 600:1 and a viewing angle of at least 150° so that the driver can easily read the contents on the displays in the cabin under different lighting conditions (e.g., daylight, nightlight, direct sunlight).

Some manufacturers put a display with a high brightness (e.g., 1500 nits) into their terminals. This measure increases the readability in daylight. It also increases the temperature inside the terminal. At 40°C, the terminal software must reduce the brightness to 70% of the maximum brightness (e.g., 1050 nits) to avoid overheating of the processor and other electronic components. Cranking up the brightness may turn out to be counterproductive.

The terminal software should automatically adapt the brightness and contrast of the display depending on the ambient lighting conditions. Many laptops and phones do this. This requires the terminal to have a light sensor. The light sensor can also tell the system when to switch from day mode to night mode.

Temperature

Special machines are used to load the sugar beets from heaps onto trucks. This happens well into the winter with temperatures down to -15°C in Russia. When the sugar beet harvest starts in August in Italy, the cabin temperatures can reach +60°C and more. Harvester terminals (electronics, displays and materials) must work continuously in temperatures from -15°C to +70°C. They must work for 15 minutes in temperatures from -25°C to -15°C and from +60°C to +70°C, until heating or cooling kick in.

As we cannot change the temperatures, in which the harvesters work, we found a constraint.

Constraint – Temperature range. The terminal must operate continuously in temperatures from -15°C to +70°C and for 15 minutes in temperatures from -25°C to -15°C and from +60°C to +70°C.

For comparison, electronic control units (ECUs) – e.g., for controlling the steering, engine or harvesting header – must stand even harsher temperatures from -40°C to +125°C (automotive temperature range). Manufacturing machines, which stand in halls, are happy with temperatures from 0°C to +70°C (industrial temperature range). Smartphones operate in very benign temperatures between 0°C and 40°C. That’s why they black out on ski tours or in cars heated up by the summer sun.

A computer-on-module for the automotive temperature range can be 20-30% more expensive than the same module for the industrial temperature range (see comparison of Verdin i.M8M Mini modules). Other components – electronic or not – are subject to similar premiums. We can reduce the terminal costs significantly, if we choose the least demanding and still sufficient temperature range.

Water and Dust

The ingress protection or IP rating tells us how well terminals are protected against water and dust. The CCpilot VS, a terminal used in thousands of agricultural machines, is rated IP65. The first digit denotes the protection against dust and the second digit against water. “6” means that the terminal is dust-tight. “5” means that the terminal withstands normal water jets.

An IP65-rated device would be protected against heavy rain. So, it’s far too much for a harvester cabin. An IP53 or IP54 rating is enough. Such terminals are dust-protected and withstand spraying water or splashing of water. So, they survive the occasional coffee spill, which is probably the gravest danger for terminals in a driver cabin.

Quality – Water and dust protection. The terminal shall have an IP rating of not less than IP53.

A higher IP rating implies a better protection against dust and water entering the terminal. It also seals off the terminal against air flowing in and out. This becomes a problem, when the terminal case cannot dissipate the heat produced by powerful processors like the i.MX8 Plus and the i.MX8 Max. Processors and other electronics overheat and fail.

Overheating is the reason why we find less powerful processors like the i.MX6, i.MX7 or i.MX8M Mini with one or two cores in IP69K-rated terminals. Such terminals are dust-tight and withstand high-temperature high-pressure water jets.

Vibrations

A 750 horse-power harvester digging sugar beets out of the ground develops some serious vibrations. Standard RJ45 (Ethernet), DSUB-9 (CAN), USB or HDMI plugs would wiggle loose in their sockets or even fall out. One solution is to use M12 and Deutsch connectors.

The photo shows an M12 connector for Ethernet and two 12-pin Deutsch connectors for 2x CAN, 1x USB, 1x RS232 and power. The M12 connector is screwed tight. The Deutsch connectors snap in very tightly. We need pliers to wiggle them out patiently. Besides withstanding heavy vibrations, these connectors protect the terminal very well against water and dust ingress (IP64 and higher).

One M12 connectors for Ethernet, two 12-pin Deutsch connectors for 2x CAN, 1x USB, 1x RS232 and power
Backside of ROPA terminal prototype: M12 for Ethernet (left), Deutsch for 2x CAN, 1x USB, 1x RS232 and power (middle and right).

Quality – Vibration-resistant connectors. Connectors for Ethernet, CAN, RS232 and other communication means must withstand heavy vibrations of the harvesters.

The M12 and Deutsch connectors solve the vibration problem nicely. They do not solve the problem of replacing multiple terminals (display computers) by one computer with multiple displays. Such a replacement would significantly bring down the cost for the complete system as I argued in my post What’s Wrong with Multiple Display Computers in Driver Cabins.

Deutsch connectors do not support the high-date rates required to transfer the contents of HD, full-HD or 4K displays over HDMI or DisplayPort (DP) cables. M12 Ethernet cables can handle high data rates of up to 10 Gb/s. However, they only support up to 12 pins. HDMI has 19 pins and DP 20 pins. So, we would have to add some circuitry on the terminal’s PCB to adapt the 19 or 20 pins to 4 pins. A similar approach is used for High-Speed-Data (HSD) cables (see my post High-Speed-Data (HSD) Connectors in Heavy-Duty Vehicles).

Type-E HDMI connectors could be an alternative that doesn’t require PCB modifications. They are built for automotive use. They have a locking tab to keep the cable from wiggling loose due to vibrations. They operate in the automotive temperature range and have sufficient water and dust protection for driver cabins.

Medium-sized manufacturers of agricultural, construction and forestry machines don’t have the expertise for PCB modifications in-house. They shy away from the costs of PCB modifications, although the costs would probably be offset by the savings from replacing multiple terminals by multiple displays. Architects should calculate the costs. The terminal manufacturers have little interest in providing vibration-resistant HDMI and DP connectors, because they would sell less terminals.

Whether we have one computer with multiple displays (1:m approach) or multiple terminals (m:m approach) has implications for the software architecture of our system. The 1:m approach leads to a system with multiple GUI applications: one GUI application for each display. A window manager like Weston makes the coordination of multiple GUI applications on multiple displays easier. The m:m approach gets by with a single application per terminal. This approach can do without a window manager.

The ROPA harvesters have two terminals following the m:m approach. Drivers can change most ECU parameters (e.g., light configuration, steering mode, turbine speed) and settings (e.g., language, day/night mode, user privileges) from both terminals. Hence, the data between the two terminals must be synchronised. The ECUs must publish all parameter changes on the CAN bus and the terminals must subscribe to them. If the driver changes settings on one terminal, the terminal must send the changes to the other terminals over CAN bus or over Ethernet.

If ROPA used the 1:m approach, the GUI applications could use inter-process communication (e.g., Qt Remote Objects) to synchronise parameter and setting changes. A service with digital twins for each ECU would notify all terminals about parameter changes and would change the parameters on the ECUs. Another service for system-wide settings would handle setting changes.

Vibrations do not only affect the selection of connectors but also the selection of touch screens. In 2012, I helped KRONE build the terminal for their forage harvesters. The terminal had a resistive touch screen. Flicking a list view and selecting an item from the list view worked fine in the office. On the field, the drivers weren’t able to select an item. Their fingers moved slightly with every tap. The list view interpreted that as a drag and started moving. We fixed this problem by providing an Up and Down button above and below the scroll bar, respectively.

Capacitive touch screens may have problems to recognise gestures properly. A continuous swipe on a phone becomes a discontinuous jumpy swipe on a harvester terminal due to vibrations and shocks. This demands fine-tuning of the gesture recognisers. We found another quality attribute for vibrations.

Quality – Vibration-tolerant gestures. The software components participating in gesture recognition must enable the correct detection of touch gestures in the presence of heavy vibration.

Cabling

Cabling is obviously not an operating condition. However, water ingress, dust ingress and vibration heavily influence which cables we can use. M12 and Deutsch connectors and cables are expensive. For example, a 3m M12 Ethernet cable costs 50-60 Euros. These cables are stiff and have diameters of 10mm and more. Running bundles of these cables through the cabin is similar to making a donkey move. Reducing the number of cables decreases the costs and makes it easier to harden the terminal against water, dust and vibrations.

Both ROPA terminals have one normal USB port, one M12 connector for Ethernet and two Deutsch connectors for 2x CAN, 1x RS232, 1x USB and 1x power. Only the primary terminal needs all these interfaces. If the primary terminal acted as a CAN-to-IP gateway, the secondary terminal would get away with one Ethernet interface and the obligatory power supply. If the primary terminal additionally acted as a WiFi access point, the secondary terminal could drop Ethernet in favour of WiFi. Wireless communication is an excellent protection against water, dust and vibration.

In the 1:m approach, the computer is connected over a type-E HDMI cable with each display. The display-less computer plays the role of the primary terminal and handles the communication with the CAN bus. The digital twins of the ECUs pass the CAN messages on to the GUI applications and vice versa. WiFi isn’t needed any more.

In 5-10 years, we may see the first wireless displays using UWB in the automotive sector. Starting with version 11, iPhones support UWB and could beam their screen contents wirelessly to UWB-capable displays – once available. The computer in the 1:m approach could do the same and could get rid of the HDMI cable, the last remaining cable.

Quality – Less cabling. We shall minimise the number of cables between terminals by introducing gateways and wireless communication.

So Far in the Series

So far, the series on the Architecture of Qt Embedded Systems comprises the following posts.

  • Getting Started. Lists 50+ questions about the architecture of Qt embedded systems, defines architecturally significant requirements (ASRs) and classifies architectures in good, right and successful.
  • Operating Conditions (this post). Explores how operating conditions like light, temperature, water, dust and vibration influence the system architecture.
  • Single vs. Multiple GUI Applications. Discusses when a single-application system is good enough, when a multi-application system with a window manager is the best choice and when even a single-application system needs a window manager.
Scroll to top