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).