Run Safety Service (as Unikernel)

Safety-critical applications in vehicles require minimal latency, high isolation, and deterministic behavior. Running the safety service as a unikernel allows you to achieve these requirements by combining the application and minimal OS into a single specialized executable that runs directly on a hypervisor like Xen.

---

Concept

Unikernels are ideal for safety applications because:

• They eliminate unnecessary OS layers, reducing attack surface and overhead.
• They boot extremely fast and run deterministically.
• Communication with other services can be controlled via virtual NICs, vsock, or shared memory.
• On Xen/Zephyr architecture, each service runs in an isolated domain, enabling safe inter-service communication without interfering with unrelated processes.

By structuring your safety service as a unikernel, you can implement direct communication channels to other safety-critical services or monitoring nodes while maintaining strong isolation and resource efficiency.

---

What's Unikernel?

A unikernel is a single-purpose virtual machine where:

• Your application is compiled together with only the necessary OS components.
• There is no general-purpose OS, only minimal drivers and libraries.
• The resulting image can run directly on a hypervisor (Xen/KVM/Firecracker) or sometimes on bare metal.

Advantages for safety applications:

• Smaller attack surface
• Predictable boot and execution times
• Direct and efficient communication between unikernels

---

Choose a Framework

Choose a framework based on your language, target hypervisor, and service requirements. Popular frameworks include:

Framework	Language	Hypervisor	Notes
Unikraft	C/C++/Rust	KVM/Xen	Modular, modern, easy to integrate with AoS-style services
IncludeOS	C++	KVM	Minimal, fast boot
OSv	Java/C++/Go	KVM/VMware	Supports POSIX APIs, good for service migration
MirageOS	OCaml	Xen	Extremely minimal, functional approach
Rumprun	C/C++	Xen/KVM	Lightweight, NetBSD-based

For AoS-based safety services, Unikraft or IncludeOS are often recommended due to modularity and hypervisor support.

---

Write the Application

Develop the service in a supported language:

• Implement core safety logic.
• Include communication handlers to interact with other services or monitoring nodes.
• Example: TCP/UDP server-client for status updates, or vsock/shared memory for low-latency signaling between unikernels.

Example (C, TCP server):

int sock = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in addr = { ... };    // IP + port
bind(sock, (struct sockaddr*)&addr, sizeof(addr));
listen(sock, 1);
int client = accept(sock, NULL, NULL);
write(client, "safety OK", 10);

---

Configure Minimal OS

Unikernel frameworks allow you to configure only the OS components your service needs:

• Network stack (TCP/UDP, lwIP, uknetdev)
• Memory management
• Device drivers (NICs, timers)
• Optional: inter-unikernel communication support (vsock, Xen grant tables)

Example (Unikraft):

make menuconfig
# Select platform: Xen
# Enable network libraries: uknetdev, lwIP
# Include your application

This ensures a small, efficient image optimized for safety services.

---

Build Unikernel Image

Compile the application and minimal OS together to create a single image:

• Unikraft: make → produces build/app_kvm-x86_64
• IncludeOS: make → produces unikernel.img
• OSv: scripts/build image=myapp

The result is a ready-to-run VM image containing the safety service.

---

Package, Sign & Upload as Service

To deploy the service in a production environment:

1. Package the unikernel image (raw .img, ELF, or .qcow2).
2. Sign the image for integrity and authenticity.
3. Upload to the deployment platform (AoS Edge/Cloud service).

Once deployed, the unikernel can:

• Communicate with other safety services via virtual NICs or vsock.
• Run in a fully isolated, high-performance domain.
• Be monitored and orchestrated via AoS management tools.