�FOSS collaboration �through API-first principles

Magnus Feuer | MBition | 2023-03-08

Internal

Part I

Mercedes‘ API-First Principles

Internal

How do we coordinate software development across �multiple ECUs, departments, and carlines?

• How do we manage cross-vehicle solutions without constraining individual ECU projects?
• How do we variance manage multiple ECUs across multiple carlines, markets, and configurations?
• How do we combine the worlds of AUTOSAR and POSIX (QNX, Linux, etc) into a single solution?

​

“

Internal

Principles derived from our MB.OS Manifesto

Use abstraction to decouple software from hardware

1

3

4

2

Separate APIs from their implementation

Evolve specification with implementation

Center around a machine-executable definition of done

Internal

Principle 1 | Use abstraction to decouple platform from hardware

Command & Control

Sensor

Actuator

Integration ECU – MB.OS Abstraction

Integration ECU – Carline Specific

IVI, ADAS, TCU, …

MB.OS Network Layer

• Sensor fusion signals
• Low frequency, high value

High-level commands

​

Real-time control loop management

• Raw sensor data
• High frequency, low value

Real-time actuator control

• API specifications are managed separately from carlines, car computers, and integration ECUs
• Projects across all carlines and hardware communicates using a single unified API specification
• Distinct separation between AUTOSAR (data plane) and POSIX (control plane) domains

Internal

Principle 2 | Separate APIs from implementations

• Have a clear API lifecycle management strategy
• Negotiate integration design across ECU teams via API specs and mockups
• Use mockups to integration test from day one

• Definition of Done
• Capture-replay & send-expect
• Delivered by architecture

• API Specification FrancaIDL/VSC/ARXML
• Delivered by architecture

• Network & language binding
• Treated as artifacts

fm-tuner-test.yml v1.5

fm-tuner-api.yml 2.3

fm-tuner-iface.hpp

fm-tuner-iface.cpp

fm-tuner-impl.cpp 2.8

Auto-tests

Generates

Wraps

• Delivered by implementation team
• Manage separately from API spec.

fm-tuner-mock.cpp 2.3

Wraps

• Delivered by architecture
• Released with API specs

Internal

Principle 3 | Evolve Specification with Implementation

• Incrementally update requirements. design, code, documentation, and test scripts to stay ASPICE compliant
• Release-manage API specification, code/documentation, and test scripts separately
• Push back against BDUF to avoid expensive dead-ends

Updated API Spec

Updated Test spec

Network and Language bindings

Mockup code

Automated integration tests

Implementation

Automated call flow tests

Documentation

Release

Updated�Requirements

Internal

Principle 4 | Center around a machine-executable definition of done

• Test scripts are single source of truth to define done
• Separate validation from verification
• API-, Implementation-, and Test changes are versioned managed into change requests

SW Element

Component

Subsystem

Component Test Script

Aggregate Test Script

Integration Test Script

API

API

API

Internal

What do we want to achieve?

• Shorter time to market with increased confidence
• Engineer around call flows instead of requirements
• Mitigate vendor lock in
• Mitigate variance management risk

Internal

Part II

API First and Open Source

Internal

Create Open Vehicle API Standards

• Focus non-differentiating services to enable new features
• Erase the boundary between the cloud and vehicle
• Use open standards as a foundation for industry collaboration
• Open APIs tend to act as seeding point for OSS projects

Internal

Left-shift testing with a new class of tools

• Enable validation tests from day one
• Single integration test strategy for Components, SW Elements, and Subsystems
• Feed simulated sensor and network traffic into integration tests
• Seamless transition from Cloud- to SIL- to HIL- testing

Test Scripts

Test Manager

Mockup Code

Code Under Test

Internal

Leverage FOSS for innovation

• A rich, well-known open API ecosystems invite to new thinking and ideas
• Provides a clear pathway to market for OEMs and Tier 1s engaging with startups
• Open Source implementations provide a higher starting point for innovators

​

Cloud

In-Vehicle

Internal

MBition and Open Source

• We have a clear FOSS mandate from Mercedes’ C-suite
• We are building up our internal FOSS organisation across Mercedes
• We will incrementally engage with open source projects
• Focus on projects that enable automotive software
• Development & Test tools
• API Standardization
• Foundational components

​

Internal

What is next?

• Find more engagement points between API-first and FOSS
• Explore new FOSS projects together with AGL
• Run a FOSS pilot between multiple OEMs to validate process
• Comfort API
• Business logic implementation of Comfort domain
• Comfort BYOD App

​

Internal

Magnus Feuer | MBition | magnus.feuer@mercedes-benz.com

Thank you!

Internal