Communication Architecture for a Hydraulic Simulation System

Abstract

HedoN is a high-tech electronic development and production company that tasked a group of six TU Delft Electrical Engineering bachelor students to design a simulation system for hydraulic plants. This simulation system consist out of a central Hydraulic Simulation Unit (HSU) that runs a hydraulics simulation and controls various electrical components. This thesis describes the Ethernet communication between that HSU and the electrical components.
As per Requirement 4, the communication system has to be designed to operate on a 1 millisecond tick. Every millisecond the HSU communicates new data with the various electrical components. This data consists of currents, voltages and operation modi for the components. Various Ethernet protocols were considered and in the end raw Ethernet communication on the OSI data link layer was selected. This is the most lightweight possible communications protocol through Ethernet to ensure the communication is fast enough and lightweight on processing power.
Every millisecond the HSU broadcasts a big packet with all the data to every component. These components will then extract information relevant to their operation. This design choice moves the computational effort of selecting relevant data per component from the HSU to the components. This is desirable since the HSU needs enough processing power to run the simulation as well as the communication in parallel. The components will then process the data and provide their response with unicast packets.
For every component to know exactly what data from the broadcasted packet is relevant to them, an initialisation phase is required. This phase is executed before the 1ms tick communication and ensures the components know at what offset they can find their relevant data.
This communication system was then tested to check if it does meet the 1ms requirement. It turns out the communication has some issues achieving the 1ms Requirement 4. The problem could be the non-realtimeness of the Linux kernel running on the HSU which leads to packets not meeting the 1ms requirement. A possible solution to this problem would be to program the HSU on a realtime OS or even baremetal C.