Sabaton has the following architectural goals

Rust as the programming language

Rust is the primary development language. We believe that Rust is the right language to develop stable and secure system software.

Rust has finally arrived in the automotive industry. Autosar has announced a working group for the use of Rust in an automotive context.

SAE has started the SAfEr Rust Task Force to define how Rust can be used in the automotive context, including safety relevant software.

Ferrous Systems and ADACore are working to bring Rust into ASIL-D environments by the end of 2022 Ferrous Systems announcement

Rust is already the language of choice for secure and safe software on the cloud native environment, and Sabaton brings Rust into the automotive environment. Sabaton is the first automotive platform the embrace Rust completely, which means the developer will use the Rust development tools for working on the Sabaton platform. If you can develop a Rust crate on Linux you can develop for the Sabaton platform.

Read the whitepaper here. The Case for Using Rust in Automotive Systems

Developer Tooling

We believe that developer experience is critical to success. We must attact more developers towards system software. The developer experience for Linux embedded systems today is far from optimal and there is a lot to learn and adapt from modern software development practices. Sabaton uses Rust's cargo as the build orchestrator, giving the developers a familiar environment to develop software for Sabaton.

Network-centric architecture

Network-centric architecture. The architecture of a Sabaton system is network centric. Dive in deeper at the above link to see how this is implemented.

Opinionated approach

An opinionated and minimalist approach to build the system. When using open-source software in a product, it is very easy to quickly lose control over what software the developers use on the system. We want to avoid being overly flexible with core software pieces. There will be standardized ways to create applications on the Sabaton platform.

Linux Kernel

The Linux kernel must be buildable from the Sabaton build environment. We tend to make adaptations to the Linux kernel during product development. This is mainly to adapt to specifics of the hardware platform that is used. There is also close interaction needed between user-space and the kernel, especially for security use-cases, eBPF for example. Having the kernel buildable along with user-space allows us to make changes and see their effects immediately.

So you want to enable eBPF in the Kernel and develop and compile an eBPF application, all this can be done without leaving your workspace.

C and C++ Applications

Sabaton supports developing C and C++ Applications. The GNU toolchain is part of the Sabaton NDK.

Key components

1. Toolchain and NDK. The toolchain and NDK is probably the slowest moving piece. The Sabaton NDK ships currently with GCC 11 and a curated list of open-source packages. It is not mandatory to use the Sabaton NDK as you can also build your own NDK using Yocto.
2. Sabaton builder The second and probably the most critical piece is the build infrastructure. The Sabaton builder is a tool that orchestrates the build. It supports declarative configurations for the Flash layout, filesystem layout and content. Making a change in an application software and building the flash image is done in a matter of minutes. The tool supports creation of CPIO, Ext2, Ext4 and FAT partitions.
3. DDS . DDS is an open standard for Data connectivity built for critical IOT systems. Data is the currency of IOT system, and DDS brings a standards based, reliable, secure, and robust data-sharing mechanism. The Eclipse Cyclone DDS implementation is used. A Rust binding to CycloneDDS provides Rust developers a pure Rust interface to CycloneDDS.
4. Vehicle Signal Specification Library. W3C Vehicle Signals Specification Library. This is a library crate that is based on the W3C VSS. This library allows applications to publish and subscribe vehicle specific data over the DDS protocol.
5. SOME/IP. While DDS provides the standards based data sharing mechanism, we still need an RPC protocol to implement services with the system. As systems are increasingly network based, we choose to use SOME/IP as the RPC mechanism. A pure Rust SOME/IP implementation gives developers a pure Rust experience without having to work with IDLs or code-generators. DDS and SOME/IP makes it convenient to develop applications on your Linux or Windows PC while connecting to real hardware over the IP network. The application can be moved to the target during deployment. (This implementation may not be compatible with third-party SOME/IP implementations)

The diagram shows a minimalistic view of one execution instance of the platform. The vehicle will likely have more than one instance running, each instance providing the platform on which the applications run on.

Description

• Linux Kernel and drivers. This is the device specific Linux kernel port and the board specific drivers for the necessary features.
• systemd : The init process. SystemD is a powerful init system even suitable for embedded devices. Sabaton uses a tailored set of systemd unit files that can be fine-tuned for fast startup.
• corelibs : The core libraries needed by the system. This includes, but is not limited to, ** C-Library ** C++ library
• logger : The logger is a standalone service that is mainly used to collect debug logs either during development, or in deployment. Logs can be collected via a TCP local connection or could also be pushed to cloud infrastructure depending on the needs.
• cyclonedds : Cyclone dds is an open source implementation of the DDS protocol. Eclipse cyclonedds. The DDS protocol is described separately. DDS provides the data-plane of the system.
• Eclipse iceoryx : This is a shared memory based interprocess communication library. Iceoryx is used to enable high bandwidth, low-latency inter process communication. Eclipse Iceoryx.
• OpenSSL is a software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites. OpenSSL is a very popular library for TLS and SSL protocol and is made part of the infrastructure libraries.
• Some/IP is an RPC protocol that runs over TCP and UDP. SOME/IP provides the control plane of the system.
• PARSEC is the Platform Abstraction for Security. PARSEC. It is an open-source initiative to provide a common API to hardware security and cryptographic services. While OpenSSL is still available for use by applications, this interface will provide a hardware agnostic interface to Crypto accelerators, HSM and TPMs.

Data and RPC bus

• The data-bus and RPC bus are IP based. This allows extending buses across multiple execution environments that may run on an adjacent device, on the edge or even on the cloud. The Data bus is also supported by a shared memory transport for local communication and this is automatically used when applicable.

Definition of Interfaces and Types

Sabaton uses cargo crates as containers for interfaces and types. This makes it easy to define, deploy and distribute interface definitions. See Interface and Type definitions for more details.

Middlware Services

The platform defines certain middleware services that are expected to be running on each instance. These are,

• Identity Manager. The identity manager provides an API for other applications to allow or deny access to API services. The Identity manager uses a combination of mechanisms such as certificates for network based protocols and unix credentials for local protocols. Note that this is not related to the identity of the user of the vehicle.
• Diagnostics Service. The diagnostics service provides a DOIP ISO 13400 interface
• Service Manager. The service manager is responsible for managing the lifecycle of the services running on the system. It implements the Lifecycle state machine and orchestrates the lifecycle of the entire system.
• Network Manager. The device may have one or more physical or virtual network devices. The network manager is responsible to configure and monitor these interfaces, providing a consistent API to other applications.
• Update Manager. The update manager is responsible for over-the-air software updates. The system supports A/B update and the update manager is able to download an update while the system is fully operational

Multiple Instances forming a Data Plane

A typical vehicle will have multiple instances running. The hardware capabilities of the different instances may be different with even completely different hardware architectures. They all get unified by the logical data plane and control plane defined by the network architecture.

Multiple instances may be needed either for redundancy or to distribute the features across the system.

The data is accessed in the DDS topic space using the topic names. The topics are accessible for read and write depending on the access priveleges provided by the platform.

Product Lining

A platform must support the idea of a product line. A product-line enables you to perform a "configuration" of the core-assets in order to produce a product. The same line of development supports multiple products at the same time.

To pull-off a successfull product line, you need the right architecture with variability mechanisms, the right build system with configuration mechanisms and last but not the least a CI/CD pipeline to continuosly build and test the different variants, automating all the aspects of the build and test cycle.

Failure to achieve any one will result in inefficiences while scaling and result in a clone-and-own approach of building standalone products.

Configurability

The source code structure and tools used in the platform will allow a developer to build any product variant from the mainline. The selection of a product will result in selection of the corresponding set of features from all the included applications in the product.