## 3 Measurement, Control, and Communication Architecture
### Software and Communication
#### 3.2.2 Communication and Data Management Layer: Raspberry Pi(r)  
The Raspberry Pi(r) 3 Model B+ operates as the embedded host system responsible for managing the communication between the Arduino(r)-based measurement/control layer and the MATLAB(r)-based supervisory application [40]. Its role is to ensure reliable, low-latency transmission of measurement data and control commands over a TCP/IP network using the WebSocket protocol. This system is programmed and executed in Python, using the latest version of Python 3.x [41].  
To achieve asynchronous and isolated handling of data streams, the Raspberry Pi(r) executes a master script (maestro.py) that launches two independent processes in parallel--one for data acquisition (process1.py) and another for control command handling (process2.py). This multiprocessing approach prevents resource contention and improves system responsiveness.  
* Data Acquisition Server--process1.py  
This process handles the reception and forwarding of measurement data. It initializes an UART serial connection with the Arduino(r) (configured at 9600 bps) and sets up a WebSocket server on port 8081. Upon establishing a client connection, it continuously reads up to 32 bytes from the UART buffer. If additional bytes remain in the buffer (in_waiting), these are appended to complete the full message.  
Once the complete data packet is received, it is transmitted directly to the client (the MATLAB(r) app) via WebSocket. A basic acknowledgment mechanism ensures that the next reading cycle begins only after the previous packet is confirmed as received, avoiding data overlapping or congestion.  
* Control Command Server--process2.py  
This process is dedicated to receiving commands from the client and relaying them to the Arduino(r). It opens a WebSocket server on port 8080 and listens for incoming messages. When a control command is received (e.g., setpoint update, mode switch), it is converted into an ASCII byte string and sent over the same UART interface to the Arduino(r). After transmission, a confirmation message is returned to the client to complete the cycle.  
This separation of concerns between data acquisition and control allows for full-duplex communication and increases the system's tolerance to high-frequency messaging or command bursts.  
* Process Management--maestro.py  
The multitasking behavior is managed by a master script that defines and initiates both processes using Python's multiprocessing module. Once launched, both child processes run indefinitely, each handling their respective WebSocket service.  
The internal logic of this process management scheme is outlined in Algorithm 1, which presents the pseudocode implementation of the master script and its associated communication servers.  
```
mmentro.py  process1.py (Process2.py) (Process Manager) (Measurement Data Server) --------------------------------- Define list of subprocesses: Initialize UART port (9600 bps, timeout 2.5 s) [process1.py, process2.py]  Geru WebSocket server on port 8081  For each process in list: On client connection: -Create a new worker process -Lesign target: run process as Python script  Start all worker processes in parallel -Read remaining bytes (in waiting)  Unit for processes to run continuously (blocking)
```  
**Algorithm 1**Pseudocode--Process Management and Communication Logic  
Under normal conditions, the total system latency--from signal acquisition on the Arduino(r) to data visualization on the MATLAB(r) app--remains under 200 ms, supporting effective real-time control. A timeout supervision is implemented to monitor UART activity: if no valid frame is received within two seconds, a warning is raised to notify potential communication failure.