Retrofit Archives

Hardware retrofit

The tried and tested Motorola 68HC12 ran for decades in simple industrial applications. Now it is no longer available and a replacement is needed, because in industry, for example in machine tools, the service life of the mechanics is much longer than that of the electronics. Customers expect the manufacturer to supply spare parts for the electronics. Manufacturers are therefore faced with the question: How do we replace the discontinued processor? This applies not only to the 68HC12 or 68HC08, but also to various processors such as the 8051 derivatives, the MSP430 or the C167xR.

The first, pragmatic reaction of many manufacturers is to replace the processor and its function 1:1 with a current, low-cost microprocessor. As the software has to be rewritten and the electronic print re-layouted, this results in development costs of several hundred thousand francs – without the machine having any new functions afterwards. In the worst case scenario, the new processor is also discontinued 5 years later.

System on Module

SCS therefore suggests to many manufacturers not to replace the processor 1:1 in a retrofit, but to use a miniature computer with a Linux system, which not only implements the existing functions, but also enables new features for customers thanks to modern communication interfaces.

Such systems on modules (SoM) are widely used as miniature computers, a typical example being the Raspberry Pi. They are plugged into the electronics via standardised interfaces. The advantage is that they already support various interfaces such as USB, Bluetooth, Ethernet and WLAN and provide enough computing power to take on more complex tasks.

Many compatible alternatives

Thanks to the widespread use of Raspberry Pi, many manufacturers have already brought alternatives onto the market that copy the form factor and interface positions. Even the Raspberry Pi’s own pin header is adopted by the manufacturers for compatibility purposes, so that you are not tied to one manufacturer. While some manufacturers of these competing products concentrate on differentiating themselves from the original with more computing power (up to 8 times), others focus on lower prices (up to a fifth). This battle for market share means that the end customer has a wide choice of modules and can switch to other modules in the event of supply bottlenecks without incurring development costs. This drastically reduces dependence on specific suppliers.

The Linux system runs on all these products, the application is abstracted at a higher level and does not need to be customised. The Linux operating system takes care of the physical interfaces.

Manageable costs

In terms of costs, an SoM is somewhat more expensive than a single processor: while a processor may cost CHF 8 per unit, an SoM is more likely to cost CHF 13. The development costs are also typically around 20% more expensive. This opens up opportunities for new applications. For example, machines can be operated via a nearby PC (Ethernet) or via an app on a tablet/mobile phone (Bluetooth, WLAN). If the display/touch panel on the machine can be minimised or omitted, the slightly higher costs for the SoM are already saved again.

Retrofit of old interfaces

Old interfaces are often a challenge for retrofits: These can be the common serial and parallel interfaces (RS-232 or LPT), but also devices with IDE and ISA bus. Linux computers can emulate these interfaces without any development effort. They are already integrated into the Linux operating system as device drivers.

At SCS, proprietary interfaces for retrofits are also implemented time and again. Sometimes this requires reverse engineering if the documentation for the interface is missing. The implementation of such special interfaces through software brings advantages for the future: on the one hand, backwards compatibility is established and, on the other, it facilitates the integration of new ideas and possibilities. Switching to newer interfaces is also greatly simplified without jeopardising backwards compatibility. This means you are not restricted by existing, old hardware interfaces.

Hard real time

There are electronics that support hard real-time and sometimes have to react within microseconds. A Linux operating system is too slow for this, even if the software is executed in “real time”. Here, SCS recommends isolating the relevant functions/machine parts and separating the real-time capabilities from the business logic. Even for machines where this approach does not seem possible, it is worth analysing and segmenting the functions in detail. In this way, the advantages of an SoM can be utilised, while the parts that absolutely must comply with real-time capabilities can be covered by traditional microprocessors.

This approach also has advantages for further developments: A much smaller processor can be used for this delimited area, which reduces production and development costs. It increases machine security, as the real-time processor does not communicate and cannot be compromised via Bluetooth, for example. This means that security mechanisms can be realised with little effort without having to use the SoM. In the event of a power failure or other events, it can simply be switched on. Meanwhile, the real-time processor, supported by a small battery or capacitors, continues to control the machine until it comes to a standstill.

Retrofits open up new possibilities

Machine manufacturers should bear in mind that a retrofit is an opportunity to provide customers with new functions. With a solid platform, you are also well positioned for future standards/customer requirements. While every centime counts with consumer electronics, the service life and customer relationship take centre stage with machines. If you replace an outdated microprocessor with an SoM and a Linux operating system during a retrofit, you will have a stable platform in future that is not dependent on the hardware. This not only facilitates the further development of your own product line, but also makes it easier and quicker to respond to customer requests. This makes new functions possible that are not even thought of today.

Save Resources

Retrofits are not only economically viable, but also an environmentally friendly solution. SCS has already successfully implemented numerous retrofits, particularly for ticket machines, but also, for example, for automated storage systems or display and announcement systems. It was awarded the Solar Impulse Efficient Solution Label in 2020 and 2023 for its innovative and sustainable approach.

Project insights

The rail network is equipped with balises, i.e. magnetically coupled transponders, which are mounted between the rails of a track. Each of these has a unique identification number. An antenna under the locomotive excites the balise with a 27 MHz RF field, whereupon the balise returns the identification number at 4 MHz. The identification number is used to reliably localise the train for the ETCS train protection system.

Diagnostic train reads balises

To monitor and maintain the infrastructure, SBB uses diagnostic trains that record the condition of the tracks with various sensors and cameras. In addition to odometry and GPS, the balises are also used as fixed objects for locating the diagnostic data on the topology of the infrastructure, as they are entered in the database with their position. For this purpose, SBB has a handful of non-safety-related balise readers in use that are not connected to the train control system.

The balise readers currently in use cannot be reordered as the two current manufacturers of these devices no longer offer support and the devices are no longer in production. For reasons of cost-effectiveness and availability, a new balise reader should be developed that can be produced in a small series at a low price.

Reverse engineering

No documentation exists for the existing balise readers, which is why a supplier’s type was analysed by reverse engineering and compared with the specification of the Eurobalises. The key components are

a TX transmitter at 27.095 MHz as a telepower source, the exact power is unknown, but is around 3 to 5 watts due to the power consumption.
an RX amplifier with a low-pass filter (DC to 5MHz) with an attenuation of -50dB at 27MHz.
a duplexer to separate transmitter and receiver at the antenna.
a Software Defined Radio (SDR) to switch on the transmitter and demodulate the balise signal.
an industrial PC that decodes the signal.

Retrofit: Not just a copy

A retrofit should not only produce a copy, but also learn from the existing system. In the existing balise reader, for example, the transmitter is switched on and off via a USB-attached relay from the software, but could also be controlled directly via the SDR board. In addition, the SDR board is only used for sampling (and demodulation) of the received signals – the data is then decoded on the integrated PC. Many different supply voltages (+5V, +15V, -15V, 24V) are also used. The system architecture is quite complex and takes up valuable space in the measuring train (4U height units in a 19-inch rack).

The new system is to be significantly simplified:

TX control directly on the SDR board
Reduced number of supply voltages (amplifier not symmetrically supplied)
Decoding directly on the SDR board, without a separate PC

The new design has been reduced in size by a factor of 4 (to one height unit in a 19-inch rack) without making any relevant compromises in terms of functionality. Less complexity also means greater reliability and better maintainability.

New system design

In the new balise reader, the 27 MHz signal is generated directly in the SDR board and only amplified by the RF module. As the SDR board works with a clock frequency of 125 MHz, the harmonics are filtered out after the amplifier for a clean output signal.
The received signal is decoded directly in the SDR board. This means that the new system consists of just three essential elements: a power supply unit, the SDR board and the RF front end. The latter was customised for the balise reader.

RF front end

The TX, RX and duplexer paths are integrated in the RF front end. The picture (below) shows the TX path at the bottom and the RX path at the top. On the right is the connection for the antenna. The output power of 35dBm (3.2W) is sufficient to reliably read the balises. The power consumption of the RF module is 700mA/12V.

Software Defined Radio (SDR)

The SDR platform is based on a Red Pitaya board with 125MHz clock and a resolution of 14bit. It is equipped with a Xilinx Zynq 7010 FPGA. The operating system is a Yocto-based Linux with a U-Boot bootloader. Secure software updates are possible at any time via the web interface. The application (decoder) is written in Python3.
During the early development phase, various algorithms for demodulation and decoding were evaluated with the help of GNU Radio and a hardware-in-the-loop setup. In the finished product, the FPGA handles the computationally intensive demodulation, while the subsequent decoding is performed in the Python application.

Websocket application

The application is designed as a web socket server. Compared to an HTTP server, a web socket can also send data on its own when a connection is open without waiting for a new connection from the client. As soon as a balise is recognised, the server sends the identification number and a time stamp. Because the balise is detected several times during the crossing, it is possible to determine very precisely when the balise is in the centre under the reader. The accuracy (jitter) of the time stamp is better than 200 microseconds if the time is synchronised using the Network Time Protocol.

The new balise reader was implemented for SBB and integrated into the OpenTLS measurement application in the diagnostic vehicle. Thousands of balises are reliably read every day. The status or the live log can be called up via a web interface. And thanks to open source code, production data and IP rights, the availability of balise readers for SBB is now guaranteed.

Solution: Retrofit

When the microprocessor is cancelled