Basic Networking with PikeOS
Networking Architecture in PikeOS
Because PikeOS is based on a microkernel, developers have flexibility in how networking is structured. While it is technically possible to place the Ethernet driver, TCP/IP stack, and application all within a single user partition, this architecture is discouraged due to the following limitations:
- No multi-client access: Only one partition can access the Ethernet port at a time, making it unsuitable for shared or modular system designs
 - Low portability: Changing Ethernet hardware would require changes to the user-space application that contains the driver
 - No observability: The Ethernet port cannot be used for tracing or debugging during development if fully encapsulated
 
Optional: Ethernet Driver in Kernel Space
For use cases that require minimal latency or tight real-time constraints, the Ethernet driver can also be placed inside the kernel partition instead of user space. However, this reduces modularity and flexibility.
Modular Networking: The recommended Approach
A more maintainable and scalable architecture separates networking into three logical components:
Link-Level Ethernet Driver
- Handles direct access to Ethernet hardware
 - Runs in a dedicated service partition (or optionally in kernel space for low-latency needs)
 - Smallest code size of all components
 - Abstracts hardware differences and is the only component needing change when switching NICs
 - Can expose virtualized network interfaces (channels) to guest OSs via PikeOS file providers or queuing ports
 
TCP/IP Network Stack
- Runs in its own partition or together with the application.
 - Communicates with the Ethernet driver over virtual channels.
 - Can be reused across projects and remains hardware-agnostic.
 
Application
- Operates at the highest layer, using a standard socket interface provided by the network stack.
 - Remains cleanly separated from hardware-specific dependencies.
 
PikeOS Networking Architecture with Partitioning
The recommended Solution
Here we show a PikeOS system that is implementing the recommended networking model using four partitions. The architecture enables secure, scalable sharing of a single Ethernet interface across multiple components and operating systems.
Key Benefit: Shared Ethernet Access across Partitions
This architecture enables multiple network stacks to coexist on a single physical Ethernet port. Each partition can have its own IP address, while development tools continue to operate independently. The modular approach improves flexibility, debuggability, and scalability across mixed-criticality systems.
➡️ Service Partition: Virt Ethernet Driver
- Hosts the low-level Ethernet driver, responsible for direct hardware access
 - Provides virtual Ethernet channels to other partitions via PikeOS file providers or queuing ports
 - Also connects to development tool agents (e.g., for debugging, tracing, and monitoring) via dedicated virtual interfaces
 - For more details, see Multiplexing Application Input/Output
 
➡️ Linux Partition
- Contains both the Linux kernel and network applications.
 - The kernel includes a full TCP/IP stack, which accesses the virtualized Ethernet interface via the PikeOS file system abstraction.
 - Applications interact with the stack using the standard BSD socket API.
 
➡️ lwIP-based Partitions
- The other two partitions integrate the lightweight lwIP TCP/IP stack directly
 - Applications are statically linked with lwIP and use either its native API or optionally a BSD socket layer
 - lwIP’s minimal footprint is ideal for real-time or resource-constrained tasks but may have feature limitations
 - For further technical details, see lwIP on Wikipedia
 
Note: lwIP is not intended to be used within Safety-relevant applications. That is because this network stack is not certifiable.
Please refer to Networking in Safety-critical Environments for a network solution that can be used in projects that have high Safety requirements
 (even up to ISO 262626 ASIL D/ DO-178C DAL A).

