Embed applications in AutoSD¶
When you need your software running on an AutoSD-based system, you have two primary methods for embedding applications in an OS image: RPM packages and containers. Both methods integrate your software at build time, since AutoSD images are immutable after they are built.
This section covers the full application embedding workflow, from packaging your software to configuring communication between services and orchestrating multi-node environments.
Choose your embedding method¶
- RPM packages
-
Package your application as an RPM and embed it directly in the OS image. RPM packages are well-suited for system-level services and applications that need tight integration with the host OS. You can embed RPMs in both the root and QM (safety-critical) partitions.
- Containers
-
Build your application as a container image and embed it in the OS image. Containers provide isolation, portability, and are the recommended approach for most application workloads. Container images can be pulled from remote registries or embedded from local storage.
After embedding your applications¶
Once your applications are running in the image, you may need to:
- Configure inter-process communication between containers across root and QM partitions using UNIX domain sockets and shared memory.
- Orchestrate services across multiple nodes using BlueChi, which extends systemd to manage services in a multi-node, mixed-criticality environment.
Important
AutoSD is the public preview of the Red Hat In-Vehicle Operating System (RHIVOS) product and contains all of the technology and tools necessary to run a mixed-criticality workload on that safety certified product. The documentation on this page presents the technology underlying and available in the product, but all safety requirements and documents are not covered here and are available only to RHIVOS customers. These safety documents impose some limitations and additional activities necessary for safety workloads.