--- title: "ZonalArchECU_W_SomeIP — A Scale-Model Zonal ECU Prototype with W5500 Ethernet Backbone" url: "https://maker.wiznet.io/matthew/projects/zonalarchecu-w-someip/" markdown_url: "https://maker.wiznet.io/matthew/projects/zonalarchecu-w-someip/md" type: "UCC: User Created Content" author: "ngxx-fus" author_url: "https://github.com/ngxx-fus/ZonalArchECU_W_SomeIP" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "ngxx-fus" original_url: "https://github.com/ngxx-fus/ZonalArchECU_W_SomeIP" published: "2026-04-20" language: "en" likes: 0 views: 641 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # ZonalArchECU_W_SomeIP — A Scale-Model Zonal ECU Prototype with W5500 Ethernet Backbone > An ESP32 zonal ECU prototype, developed on Ubuntu/Linux, using W5500 Ethernet to explore vehicle-style networking and early SOME/IP. Original author: ngxx-fus (source: https://github.com/ngxx-fus/ZonalArchECU_W_SomeIP) ## Article Thumbnail Image: AI-generated image ## 📌 Overview `ZonalArchECU_W_SomeIP` is a **scale-model zonal ECU prototype** that explores how a modern vehicle-style zonal architecture can be implemented on a small platform. According to the repository, the system is built around **two zonal ECUs (front and rear)**, **one central switch**, and **one central computing unit (CCU)**. The zonal ECUs are intended to handle local motor control and sensing, while the CCU is responsible for high-level behavior such as path planning. What makes this project stand out is that Ethernet is treated as the **backbone of the architecture**, not just as an extra interface. The public materials clearly position the system as a layered zonal network, where local ECUs are separated from centralized compute and linked through a switch-based communication fabric. In that context, the W5500 is not merely a connectivity chip — it is the hardware link that allows an ESP32-based zonal node to behave like a networked ECU. ![](https://maker.wiznet.io/upload/ckeditor5/634768210%5F1776680500%2Ejfif) ![](https://maker.wiznet.io/upload/ckeditor5/634768210%5F1776680480%2Ejfif)AI-generated image **SOME/IP** is an AUTOSAR-defined automotive Ethernet protocol. Its concept is **service-oriented communication over IP**. It is used when ECUs need to exchange software functions and data as network services. Its role is to provide **remote procedure calls, event notifications, and serialized inter-ECU communication**. **A zonal ECU** is not a protocol but an **area-based vehicle controller**. Its concept is to group sensors and actuators by **physical vehicle zone** instead of by isolated function. It is used when a vehicle architecture connects many local devices in one zone to a central compute ECU. Its role is to provide **local I/O aggregation, data and power distribution, and a network connection between the zone and the central compute unit**. **In this repository**, the front and rear nodes are treated as zonal ECUs, while the CCU handles higher-level control through an Ethernet backbone built around the W5500 interface. --- ## 📌 Features **Scale-model zonal vehicle architecture** The repository explicitly presents the prototype as a zonal architecture with a CCU, a communication layer, zonal ECUs, and a sensor/actuator layer. This makes it more than a simple robotic car controller. **Dedicated W5500 Ethernet module** The project includes a full `EthernetW5500` subsystem with custom SPI transaction framing, register definitions, payload buffers, helper functions, and a dedicated runtime service task. **Motor-control service already integrated** A separate H-bridge service manages local motor control, exposing safe set/get functions and a task loop that continuously applies pending updates. That gives the zonal node a real local actuation role. **Static network bootstrap for deterministic bring-up** The public snapshot defines a fixed gateway, source IP, subnet mask, MAC address, and a `SOMEIP_PORT` constant. This is a practical prototype choice for repeatable bring-up and early debugging. **Linux/Ubuntu host development workflow** The visible project metadata suggests that development is being done on a **Linux/Ubuntu host** with **ESP-IDF 6.1.0** and the `xtensa-esp32-elf-gcc` toolchain. This matters because the project is not a native Ubuntu application — it is an ESP32 firmware project developed from a Linux workstation. --- ## 📌 System Architecture ![](https://maker.wiznet.io/upload/ckeditor5/634768210%5F1776675727%2Epng) AI-generated image The readme describes the design in four layers: **Central Layer**, **Communication Layer**, **Zonal Layer**, and **Actuators & Sensors Layer**. At the top sits the **CCU**, which handles path planning and overall behavior. The **central switch** sits below it and forwards packets between compute and the zones. Then come the **front and rear zonal ECUs**, which act as local gateways to the actual motors and sensors mounted on the vehicle model. That is exactly the key idea behind zonal E/E architecture: instead of scattering separate ECUs across every function, the system groups electronics by **physical zone**, then links those zones over Ethernet. Even on a small model, the project is clearly trying to mirror that industry direction. The firmware layout reflects this architectural split. On startup, `app_main()` calls `AppInit()`, which launches separate services including `MotorCtl` and `EthernetAdapterCtl`. This means the zonal ECU is already structured as a **multi-service node** rather than as a single control loop. --- ## 📌 Development Environment and Runtime Context One detail worth making explicit is the difference between the **development environment** and the **runtime target**. This project appears to be developed on a **Linux/Ubuntu host**. The VS Code configuration points to `/home/fus/esp/...`, uses an ESP-IDF toolchain, and targets `xtensa-esp32-elf-gcc`. The generated `sdkconfig` also confirms **ESP-IDF 6.1.0** and `CONFIG_IDF_TARGET="esp32"`. So the most accurate description is: - **Host development environment:** Ubuntu/Linux - **Runtime environment:** ESP32 firmware on ESP-IDF + FreeRTOS That distinction matters because the project may be developed from Ubuntu, but the actual ECU logic runs on the ESP32, not on the Linux machine. --- ## 📌 Role and Application of the WIZnet's Chip ![](https://maker.wiznet.io/upload/ckeditor5/634768210%5F1776675934%2Epng) AI-generated image **WIZnet chip used: W5500** In this project, the W5500 is the **Ethernet backbone interface for the zonal ECU node**. It allows the ESP32-based controller to join the prototype’s Ethernet network and communicate as part of the zonal architecture described in the repository. Without it, the board would remain only a local control unit; with it, the node becomes part of the larger vehicle-style communication fabric. The public implementation is quite low-level and therefore especially informative. The project defines its own packed SPI transaction headers, its own common/socket register mappings, and its own read/write helpers for the W5500. During initialization, it writes the **gateway address, subnet mask, source IP, and source MAC** directly into the W5500 common registers. That design choice tells us something important about the communication stack. ### What communication path is actually used? **lwIP is enabled at the project level**, because the ESP-IDF configuration includes `CONFIG_LWIP_ENABLE=y` and `CONFIG_ESP_NETIF_TCPIP_LWIP=y`. However, the **visible W5500 path does not appear to run through lwIP or ESP-IDF’s **`**esp_eth**`** layer**. Instead, the public code directly drives the W5500 over SPI and manipulates its internal registers and socket state. ### Is this MACRAW mode? Based on the startup documentation, **no**. The public W5500 startup sequence explicitly shows: - interrupt setup and RAM allocation for Socket 0 - `Sn_MR` set to **UDP mode (0x02)** - local port assignment - `OPEN` command execution - expected `SOCK_UDP` socket status That means the visible path is **not MACRAW mode**. It is closer to a direct **W5500 hardware UDP socket bring-up** flow. ### Does it use the W5500 hardwired TCP/IP engine? **Yes — that is the most accurate interpretation of the public snapshot.** The code is directly configuring W5500 common and socket registers, allocating socket buffers, and preparing Socket 0 for UDP communication. That is exactly the kind of usage model associated with the W5500’s **hardwired TCP/IP / socket engine**, even though the visible implementation currently centers on UDP setup rather than a full higher-layer protocol stack. ### Does it use WIZnet’s official socket library? In the public repository snapshot, it does **not appear to use WIZnet’s standard ioLibrary**. There is no visible `wizchip_conf.h`, `socket.h`, or the usual ioLibrary file layout. Instead, the project provides its own `EthernetW5500.c/.h` and `EthernetW5500Cmds.h`, which strongly suggests a **custom low-level W5500 driver** rather than a wrapper around WIZnet’s standard socket library. So, the cleanest summary is: - **Host development:** Ubuntu/Linux - **Runtime target:** ESP32 + FreeRTOS - **Project-level TCP/IP stack:** lwIP enabled - **Visible W5500 path:** custom SPI/register driver - **Mode:** not MACRAW - **Likely communication approach:** direct use of W5500 hardwired UDP socket flow - **WIZnet ioLibrary:** not visibly used in the public snapshot --- ## 📌 Market & Application Value The clearest value of this project is as a **research and prototyping platform** for zonal automotive networking concepts. For students, labs, and embedded developers, this project provides a small-scale way to explore how Ethernet-based zonal ECUs might be structured without immediately moving to full-size automotive hardware. The layered system diagrams, explicit W5500 startup sequence, and separated motor/network services make it a useful learning example for modern vehicle E/E architecture. It also has practical value as a prototyping framework. Many small robotic or mobility models remain function-centric, with isolated boards connected by ad hoc logic. This prototype instead asks what happens when you treat the platform more like a vehicle, with a compute node, a central switch, and zone-level ECUs connected through Ethernet. That makes it relevant not only to scale-model cars, but also to academic mobility platforms, robotics networking experiments, and service-oriented ECU research. At the same time, the public code still looks like a **work-in-progress engineering prototype** rather than a complete end-to-end SOME/IP demonstration. The communication direction is clear, but the visible implementation is strongest today as a zonal ECU backbone prototype with motor control and W5500 bring-up already in place. --- ## 📌 External Indicators The repository includes both **logical and physical architecture diagrams**, which is a positive sign that the author is thinking at the full-system level, not only at the code level. The docs folder also contains a dedicated **W5500 startup sequence** in Mermaid format, which is especially helpful for understanding how the network node is supposed to boot and enter UDP communication mode. There is also a small Python ARP test script that repeatedly probes the ECU IP address. That suggests the author is actively validating Ethernet visibility and network presence during bring-up. --- ## 📌 Summary `ZonalArchECU_W_SomeIP` is a scale-model zonal ECU project that explores how a vehicle-style zonal architecture can be implemented with front/rear ECUs, a central switch, and a CCU. The public code already shows real motor control, a structured FreeRTOS service model, and a substantial custom W5500 Ethernet subsystem. A key technical takeaway is that this project is **developed on an Ubuntu/Linux host but runs as ESP32 firmware**, and the visible W5500 path is **not MACRAW** and does **not appear to use WIZnet’s standard socket library**. Instead, it uses a **custom low-level SPI/register driver** to access the W5500’s **hardwired socket engine**, with the current public snapshot showing a UDP-oriented bring-up flow that appears to be laying the groundwork for future SOME/IP-style communication. --- ## 📌 FAQ **Q1. Does this project run on Ubuntu?** Not as a runtime application. It appears to be **developed on Ubuntu/Linux**, but the actual runtime target is **ESP32 firmware built with ESP-IDF and FreeRTOS**. **Q2. Is lwIP involved?** Yes, **lwIP is enabled in the ESP-IDF project configuration**, but the visible W5500 code path does not appear to rely on lwIP sockets or `esp_eth` integration. **Q3. Is the W5500 used in MACRAW mode?** No, the public startup sequence shows **Socket 0 being opened in UDP mode**, not MACRAW mode. **Q4. Is it using the W5500 hardwired TCP/IP engine?** Yes, that is the best interpretation of the public code. The project directly configures W5500 common/socket registers and prepares a UDP socket using the chip’s internal socket engine. **Q5. Does it use WIZnet’s official socket library?** It does not appear so in the public snapshot. The repository exposes a **custom W5500 low-level driver** rather than the typical WIZnet ioLibrary file structure. **Q6. Is SOME/IP fully implemented?** Not visibly, at least not end-to-end in the public snapshot. The repository clearly points toward SOME/IP, but the visible network bring-up is still centered on **UDP socket initialization and Ethernet backbone work**. --- Source: https://maker.wiznet.io/matthew/projects/zonalarchecu-w-someip/