We will walkthrough this evolution of simple program in phases

1. Setup Example - Obstacle detection program
2. Refactor monolithic program to Functions
3. Seperate functionalities into modules
4. Real-car analogy
5. Write ARXMl for same example
6. Refactor modules to autosar format
7. Conclusion

Phase 1: Setup Example​

Simple Obstacle Detection Program The initial step involves creating a straightforward C program that encompasses all functionalities within the main function. This program reads sensor data and actuates a motor to stop when an obstacle is detected.

#include <stdio.h>
#include <stdbool.h>

int main() {
    bool obstacleDetected = false;
    int sensorData = 0;

    printf("Reading sensor data...\n");
    // Simulate reading sensor data
    sensorData = 10; // Assume 10 is the threshold for detecting an obstacle

    if (sensorData >= 10) {
        obstacleDetected = true;
    }

    if (obstacleDetected) {
        printf("Obstacle detected! Stopping motor...\n");
        // Code to stop the motor
    }

    return 0;
}

Phase 2: Functions​

We refactor the initial program by breaking down the logic into separate functions. This enhances readability and maintainability.

#include <stdio.h>
#include <stdbool.h>

bool readSensorData(int *sensorData) {
    *sensorData = 10; // Simulate reading sensor data
    return *sensorData >= 10; // Returns true if obstacle is detected
}

void stopMotor() {
    printf("Stopping motor...\n");
    // Code to stop the motor
}

int main() {
    int sensorData = 0;
    bool obstacleDetected = readSensorData(&sensorData);

    if (obstacleDetected) {
        stopMotor();
    }

    return 0;
}

IN PROGRESS

YAML ("YAML Ain’t Markup Language") is a human-readable data-serialization format commonly used for configuration files, data exchange, and templating.

It emphasizes simplicity and readability, supports comments, anchors, and complex data structures.

Official Site & Specification​

• YAML Official Site
• YAML Specification

YAML Syntax & Features​

• Scalars: Strings, numbers, booleans
• Sequences: Ordered lists (dash-prefixed)
• Mappings: Key–value pairs (colon-separated)
• Comments: Start with #
• Anchors & Aliases: Reuse/refer to nodes
• Multiline & Folded Blocks: Handle long text

Basic Rules​

• Indentation-sensitive (use spaces, not tabs)
• Case-sensitive keys
• Quotes optional unless special characters appear

Simple YAML Examples​

Flat Mapping​

server:
  host: example.com
  port: 8080
debug: true

Sequence of Mappings​

databases:
  - name: users
    host: db1.local
  - name: logs
    host: db2.local

Anchors & Aliases​

defaults: &def
  adapter: postgres
  timeout: 5000

production:
  <<: *def
  database: prod_db

Advanced Anchors & Aliases​

Anchors and aliases can be used to create complex reusable structures, reducing duplication and improving maintainability.

# Define reusable anchor for default settings
defaults: &defaults
  adapter: postgres
  timeout: 5000
  retries: 3

# Use the anchor in multiple environments
development:
  <<: *defaults
  database: dev_db
  debug: true

staging:
  <<: *defaults
  database: staging_db
  debug: false

production:
  <<: *defaults
  database: prod_db
  debug: false
  timeout: 10000  # Override specific values

Nested Anchors & Aliases​

You can also nest anchors and aliases to handle more complex configurations.

# Define base anchor for server settings
server_defaults: &server_defaults
  host: localhost
  port: 8080

# Define another anchor for database settings
db_defaults: &db_defaults
  adapter: postgres
  timeout: 5000

# Combine anchors in a service configuration
services:
  web:
    <<: *server_defaults
    endpoints:
      - /api/v1
      - /api/v2
  database:
    <<: *db_defaults
    database: app_db
    replicas: 3

These examples demonstrate how anchors and aliases can simplify YAML configurations by reusing and combining settings across different sections.

Multiline Strings​

description: |
  This is a multiline
  literal block.
notes: >
  This is folded into
  a single line.

Templating with ytt​

ytt is a simple YAML templating tool that lets you add logic to your YAML files without making them complex.

Installation (macOS/Linux via Homebrew)​

brew install ytt

Basic Usage​

YTT Basics

For more examples and documentation, visit Carvel ytt.

Can YAML Import from Another YAML File?​

YAML itself does not natively support importing data from another YAML file. However, this functionality can be achieved using external tools or libraries. Here are some approaches:

1. Using Templating Tools: Tools like ytt (covered earlier) allow you to merge or include YAML files during rendering.

2. Custom Scripts: You can write scripts in Python, JavaScript, or other languages to load multiple YAML files and combine them programmatically.

3. Third-Party Libraries: Some libraries, like ruamel.yaml in Python, can be extended to support custom import logic.

While YAML does not natively support imports, tools like ytt or custom scripts can provide this functionality. This approach ensures modular and maintainable configurations.

VS Code Extensions for YAML​

• YAML by Red Hat: Provides YAML language support.
• YAML Support by GitHub: Enhances YAML editing.
• YAML Path: Simplifies navigation in YAML files.
• YAML Formatter and Tools: Formats and validates YAML.

Python YAML Libraries​

• PyYAML: A popular library for parsing and writing YAML.
• ruamel.yaml: A more advanced YAML library with better support for YAML 1.2.

Pros & Cons of YAML​

Pros​

• Human-readable & concise
• Supports comments & anchors
• Widely adopted (e.g., Ansible, Kubernetes, CI configs)
• Flexible data structures

Cons​

• Indentation-sensitive: Can cause errors
• Ambiguous syntax (e.g., tabs vs. spaces, boolean parsing "on/off")
• No built-in schema (relies on JSON Schema or custom validators)
• Harder to parse with regex

Best Practices​

• Use 2 spaces per indent; never tabs.
• Quote strings with special characters or leading zeros.
• Define and reuse anchors for repeated data.
• Validate against JSON Schema (many CLI tools exist).
• Keep documents small to maintain readability.
• Use CI linting (e.g., yamllint).

YAML remains a dominant choice for config files and data exchange due to its readability and expressiveness. With tools like ytt for templating, VS Code extensions for editing, and robust Python libraries for parsing, you can build, manage, and validate YAML-based configurations efficiently.

Keep best practices in mind to avoid common pitfalls, and happy coding!

We all know plain XML (eXtensible Markup Language) file is a text-based file format that stores data in form of tags and text. Whereas ARXML is AUTOSAR XML file to store AUTOSAR parameters with added AUTOSAR specific tags and constraints.

Instead of delving into AUTOSAR parameters or the various types of ARXML files, let’s focus on a broader question:

Why was ARXML chosen initially, and what alternative might be selected if AUTOSAR was initiated in 2023?

Why ARXML?​

The answer is relatively straightforward. ARXML is based on XML. Whereas XML’s significant rise to prominence in the late 1990s and its adoption as a W3C recommendation in 1998 made it an ideal choice for data interchange and storage. Due to its flexible, human-readable, machine-readable nature and its widespread use in enterprise applications, web services (SOAP), and configuration files cemented its reputation well before the emergence of modern formats.

Essentially, XML was at the peak of its popularity when AUTOSAR was established.

ARXML’s Place in Today’s Landscape​

Since the early 2000s, the landscape of data serialization and configuration management has evolved considerably with modern formats like JSON (JavaScript Object Notation), YAML (YAML Ain’t Markup Language), and TOML (Tom’s Obvious, Minimal Language) or Data Modeling languages like ASN.1 or Protobuf.

Now, let’s not dig into JSON format much as it’s already been replaced by YAML and TOML in many areas.

Also, TOML is not as widely adopted as XML or YAML but it is gaining popularity for its simplicity and ease of use, particularly in smaller-scale applications and open-source projects, especially in the Rust and Go communities.

CAN YAML replace ARXML?​

Probably yes in some areas. YAML (YAML Ain’t Markup Language) is a human-readable data serialization standard that can be used in conjunction with all programming languages.

Structured Data Representation: YAML excels at representing structured data with a focus on human readability. It supports scalars (strings, numbers, booleans), arrays, and maps (key-value pairs), allowing for deeply nested data structures.

Namespace Support: YAML itself does not natively support XML-style namespaces. However, it can represent namespaced keys in a map through naming conventions or application-specific designs.

Schema Validation: While YAML does not have a built-in schema validation feature like XML Schema Definition (XSD), it can be used with external tools like JSON Schema for validation purposes. There are also custom schema validators for YAML, such as Kwalify or StrictYAML.

Widespread Tooling: YAML is widely supported across various programming languages and platforms with numerous libraries available for parsing and generating YAML data. It is commonly used in DevOps tools like Docker, Kubernetes, and continuous integration systems.

Industry Precedence: YAML has become a standard for configuration files in software development, particularly due to its clarity and ease of use. While not as entrenched as XML in enterprise data interchange.

Can ASN.1 or Protocol Buffers replace AUTOSAR data exchange format?​

ARXML is a file format used within the automotive industry to describe the configuration and behavior of automotive systems and their interactions. It is specifically tailored to the requirements and standards of the automotive domain.

While ASN.1(Abstract Syntax Notation One) and Protocol Buffers (protobuf) are powerful data modeling languages commonly used for defining data structures and serialization formats for network communication and data interchange across various industries, they are not designed specifically for the same purpose as ARXML.

Conclusion​

In my opinion, should the AUTOSAR team be in the position to choose today, they might consider YAML and come up with ARYAML or build a new data modelling language and call it as ARDML (AUTOSAR Data Modelling Language) to support “code first” approach.

If the AUTOSAR team decides to redefine the file format, I suggest considering the adoption of multiple data exchange formats that are best suited for use-cases. It’s important not to restrict the industry by using a single data exchange format for everything.

However, replacing ARXML would not be a simple task, given that it has been deeply entrenched in the industry for over two decades with extensive tools, workflows, and processes built around it. Transitioning to a new format raises interesting questions but also presents significant challenges that would require considerable effort, retooling, and retraining across the entire ecosystem.

Potential for Change in the AI Era​

Nevertheless, in an era where artificial intelligence and rapid technological advancements are the norms, change is always on the horizon. The industry’s mindset is increasingly open to innovation, suggesting that a shift, while complex, is not beyond the realm of possibility.

As the automotive industry continues to evolve with smart vehicles and connected infrastructure, the demands on software architecture will undoubtedly lead to new considerations for data interchange formats.

Now, before we dive into the specifics of the AUTOSAR methodology, let’s take a moment to explore some of the more traditional or widely-used strategies for crafting an embedded system.

Regular embedded system development techniques​

Traditional or regular embedded systems are less standardized and more diverse.

Bare-Metal Programming

In this methodology, developers write code that runs directly on the hardware without an operating system. It’s often used for simple or resource-constrained devices where maximum performance and minimum overhead are required.

Development is highly hardware-specific, with direct manipulation of registers and use of interrupts for task management.

Actuators for specific functions like mirror adjustment, seat position, or window control can be implemented with bare-metal programming, as these tasks usually require simple, deterministic control loops.

RTOS-Based Development

Real-Time Operating Systems (RTOS) are used when deterministic behavior and timing are crucial. The RTOS abstracts some of the hardware details, but developers still need to have a good understanding of the system’s timing and resource constraints.

Examples include FreeRTOS, VxWorks, and QNX, which provide a framework for task scheduling, inter-task communication, and timing services.

Linux-Based Development

For more complex systems that require networking, file systems, or high-level application frameworks, a full-fledged operating system like Linux might be used.

Linux offers a rich set of features and is supported by a wide variety of processor architectures.

Development can leverage standard programming languages and open-source tools, but may still require customization of the Linux kernel or device drivers.

Proprietary or In-House Frameworks

Some organizations develop their own proprietary frameworks or libraries tailored to their specific hardware and application requirements. These frameworks can range from simple hardware abstraction layers to complex software ecosystems.

They may offer advantages in terms of performance or integration with company-specific technology but can also lead to increased maintenance and portability challenges.

Model-Based Development (MBD)

MBD uses high-level modeling tools like MATLAB/Simulink to design the system, which can then automatically generate code for various hardware targets. This approach is useful for complex control systems and signal processing applications.

Vendor-Specific Ecosystems

Many microcontroller and processor vendors provide integrated development environments (IDEs), software libraries, and tools specific to their hardware. These ecosystems simplify development for the vendor’s hardware but can lock you into using that vendor’s products.

Some examples are Microchip’s MPLAB X, Texas Instruments’ Code Composer Studio, and STMicroelectronics’ STM32Cube.

AUTOSAR Methodology​

AUTOSAR provides a standardized architecture for automotive software development. It aims to improve software reusability, scalability, and interoperability between different vehicle components and vehicle manufactures.

The AUTOSAR methodology roughly describes the concept of ECU (Electronic Control Unit) development by the basic work product flow from a global view.

Example: Temperature Control System Let’s dive a bit deeper by comparing AUTOSAR methodology with regular embedded system development using an example of developing a temperature control system.

A temperature control system typically consists of several key components that work together to regulate temperature within a desired range. The exact configuration can vary depending on the complexity of the system and the specific application, but here are the fundamental components you would generally find

• Sensor(s) — To measure current temperature.
• Controller — The brain of the system which processes input from sensors and determines output to heating or cooling devices.
• Actuator(s) — Heating or cooling elements.
• User Interface — Allows user to set desired temperatures.
• Regular Embedded System Development approach
• Requirements Analysis : Determine the functional requirements, such as the desired temperature range and response time.

Hardware Selection:
Next, you pick out a microcontroller that’s got enough oomph to run your code and a sensor that’s accurate enough so you don’t end up sweating or freezing.

Software Design:
Now you sketch out how your code’s going to work. You’ll need some loops to check the temperature, some logic to decide when to turn on the heat, and a way for people to adjust the settings.

Implementation:
Time to get coding. You roll up your sleeves and start writing lines of C or C++ that tell the microcontroller what to do.

Integration and Testing:
You’ve got to make sure your code plays nice with the hardware. Integrate the software with the hardware and test the system to ensure that it meets the requirements.

Maintenance:
After everything’s up and running, you’re not done yet. If a bug pops up or you want to add new features, you get back in there and update your code.

Now if you want to add touch screen, there is high chance of touching almost all modules because you never thought to standardize your interfaces.

AUTOSAR Approach​

Think of AUTOSAR like a big LEGO kit for car software. It’s got all these standardized blocks you can snap together to build software for cars.

It’s all about making sure the pieces you create can be used in different cars and play nicely with parts from other car makers.

Now, let’s see how we’d whip up a temperature control system with this toolkit.

Requirements Analysis:
Just like when you’re planning any project, you gotta figure out what you need. In the car world, there are some extra rules to follow, like making sure everything is super safe because, well, it’s a car.. For example, ISO 26262 for functional safety.

Software Architecture:
AUTOSAR sets up a neat structure for your code with different blocks.

You’ve got the Application Layer where your temperature control magic happens, the Runtime Environment (RTE) that’s like a middleman passing messages, and then the layers that talk to the actual car hardware.

Component Design:
Now, you get to create the bits and pieces of the software that control the temperature.

The best part is that you can use them over and over in different areas. Just like libraries.

You describe these pieces with a fancy instruction manual called ARXML.

Configuration:
You’ve got your pieces ready, but you need to set them up for your specific ride. That’s like tuning your sound system to get the perfect bass.

You use some special AUTOSAR tools to make sure all the software bits are working together properly.

Integration and Testing:
It’s time to put your creation into action and make sure it doesn’t go haywire.

More of like connecting blocks.

You’ll run it through some virtual tests on your computer (that’s SIL) and then with real car parts (that’s HIL) to catch any gremlins before they cause trouble.

Maintenance:
Since you’ve used these standardized LEGO-like pieces, when it’s time to update or fix something, it’s way easier.

You can just swap out the old piece for a new one, and you’re good to go.

So, there you have it. Using AUTOSAR is a bit like having a guidebook that makes sure everyone’s building their temperature control systems with the same set of rules, which is pretty handy when you’re making something as complex as a car.

Key takeaways with a different example for better visualization​

Standardization:
Like I mentioned, With AUTOSAR, it’s like everyone’s using the same cookbook, which makes it easier to share recipes and tools.

In regular embedded development, each chef might have their own secret recipes and special kitchen setup.

Abstraction:
AUTOSAR is like having smart kitchen appliances that adjust themselves to the recipe.

In regular development, the chef has to fiddle with the knobs and settings for each dish.

Interoperability:
AUTOSAR’s like a potluck where everyone brings dishes made using the same cookbook, ensuring all the food goes well together.

Regular development is more like everyone bringing a dish without knowing what the others are making, which can lead to a mismatched meal.

Tooling:
Working with AUTOSAR might mean you need some pricey, high-tech kitchen gadgets that take time to learn how to use.

For regular embedded development, you might get by with more basic tools, or even DIY some gadgets to suit your needs.

Scalability:
AUTOSAR’s like having a cookbook that covers everything from making toast to preparing a five-course meal. It can handle recipes for all sorts of occasions.

In traditional embedded development, you might need a new cookbook — or even a new kitchen — every time the scale of your cooking changes.

Not everyone grasps AUTOSAR as originally intended, and since the AUTOSAR methodology doesn’t clearly define roles and responsibilities. Whereas, company-specific processes and vendor tools tend to complicate it further.

Motivation​

Roughly two decades ago, the automotive industry operated with proprietary software development, hardware dependency, a lack of standards, and diverse interfaces. Basic software modules were tailored to specific electronic control units (ECUs).

The frequent obsolescence of microcontrollers before series production often led to last-minute software adjustments under tight time constraints. Integrating such diverse subsystems into a complex, interconnected vehicle network was error-prone and demanded extensive testing.

It may be hard for younger readers to imagine, but this was the situation that gave rise to the concept of AUTOSAR.

so, in early 2002, the concept for an open system architecture emerged in BMW’s electronics division.

Release of Classic AUTOSAR​

The Classic Platform Release 1.0 was published in June 2005 as the first release of the classic platform specifications.

The idea was to get rid of the late and risky adaptations of basic software for ECUs and to reduce the demand of internal and external resources involved in these software adaptations.

It envisioned moving towards open system architectures by creating a hardware abstraction layer (HAL), a standardized basic software stack, and a middleware layer with standardized interfaces to the applications.

It took a minimum of 10 years for some companies to accept, implement and transition AUTOSAR.

Release of Adaptive AUTOSAR​

Vehicles are evolving into cyber-physical systems, connecting to the internet, and becoming part of the Internet of Things (IoT). In addition, the industry moved towards realizing the vision of autonomous driving through advanced driver assistance systems and autonomous parking.

These new functions placed demands on hardware and software infrastructure, including high-end processors, hypervisor technology, communication with backend systems, and a focus on dependability, functional safety, and cybersecurity within the software architecture.

In 2015, AUTOSAR released the Adaptive Platform to address new challenges posed by connected, automated, shared, and electrified driving (CASE).

2020s​

The car industry is changing like never before in its 150-year history. Cars are now filled with digital features and new business models. Car makers are trying new things and facing new competition.

Everyone in the industry now knows that software is crucial for cars, and most car makers are aiming high.

Past 20 years, AUTOSAR has created a comprehensive way to design software deeply embedded in cars. The classic platform still plays a role in driving sensors and actuators, while the Adaptive Platform is used in central ECUs. This means that cars are evolving into IT-edge devices, connecting to the cloud. Combining AUTOSAR with other technologies has the potential to establish a new software platform for vehicles but the drawbacks still exist though.

Twist in the plot​

New players from the tech world have entered the car industry, bringing fast development and collaboration methods.

This helps them deal with the complexity of automotive software, but the industry still needs to consider safety and real-time standards.

The key to future success is fast collaboration and open-source development in addition to existing safety-related methods.

As I mentioned before, main drivers for the increased complexity in our systems are the following four, which today are also often summarized by the acronym CASE:

Connectivity: Standardized communication protocols are needed to enable connectivity between vehicle ECUs and the external world.

Autonomy: The advancement of automated and autonomous driving necessitates high computing performance in today’s and future microprocessors (µPs), leading to new E/E architectures and centralized E/E architectures. This also sets new standards for security updates and promotes the use of non-automotive IT standards available as open-source software solutions.

Safety requirements for autonomous features demand traceable requirement specifications in addition to open-source software approaches.

Sharing: The abundance of software in future automotive systems requires applications from various sources and the reuse of non-differentiating commodity software, making a standardized Vehicle-Operating-System (Vehicle-OS) crucial to meet this demand.

Electrification: The introduction of electric vehicles brings about less complex electrified powertrains, making it easier for new players (OEMs) to enter the market.

This supports the reuse of commodity functions and encourages open-source solutions for Vehicle-OS.

Future​

Many automotive manufacturers are working to build their own vehicle operating systems, and there is a growing need for an ecosystem that simplifies access to both off-board and on-board systems.

Another emerging trend is the shift towards centralized computing platforms, eliminating the necessity for a separate microcontroller for each vehicle function.

There are already open-source standards and solutions for various industry needs, and it may not be necessary to adhere to a single standard like AUTOSAR. It’s possible to have multiple standards tailored to specific needs with/without/around AUTOSAR.

Volvo has developed a concept car using Rust. Zephyr is a scalable real-time operating system supporting various hardware architectures, designed for resource-constrained devices with a focus on security. SAFERTOS® is another option, based on the FreeRTOS kernel model and pre-certified to ISO 26262 ASIL D. Middleware protocols like DDS and API standards for data-centric connectivity are also available.

Combining alternatives along with AUTOSAR in use, vehicle manufacturers are developing their own Vehicle-OS with standards wrapped around open sources.

This could lead to a diverse range of ecosystems and interfaces, reminiscent of the situation 20 years ago but on a larger and more complex scale.

In order to get this under control, industry should focus on providing lighter alternatives to AUTOSAR with approved common services and protocols with a forward-looking approach. Additionally, industry needs a coordinated collaboration across different standardization and Open-Source Software organizations to continuously develop the common infrastructure.

References​

News & Events AUTOSAR

Why Volvo thinks you should have Rust in your car?

What is DDS?

Zephyr Project

• Early frameworks such as MFC(Microsoft Foundation Classes) and AWT(Abstract Window Toolkit in Java) pioneered structured software development.
• The Dot-Com Boom popularized web development technologies like PHP and ASP.NET.
• Mobile app development advanced significantly with frameworks like Swift and Kotlin.
• The advent of Angular, React, and Node.js marked a notable shift towards front-end and full-stack web development. Hadoop and Apache Spark were introduced to tackle big data challenges.
• AUTOSAR, a specialized framework in the automotive sector, was developed to standardize vehicle software systems. It evolved to meet the demands of high-performance computing in cars, shifting its approach with the introduction of the Adaptive Platform.
• The software industry has seen a mix of framework evolution and obsolescence, and recent advancements in AI, ML, and IoT are currently guiding the creation of new frameworks.

Pros of Using Frameworks​

• Increased Efficiency: Frameworks provide pre-built components and standardized code structures, significantly reducing development time.
• Community Support: Popular frameworks boast extensive communities, offering support, documentation, and third-party resources.
• Enforced Best Practices: Many frameworks come with built-in security features and promote coding best practices.

Cons of Over-Reliance on Frameworks​

• Lack of Flexibility: Over-dependence can hinder the implementation of unique features or require convoluted workarounds.
• Performance Overheads: Some frameworks add unnecessary bloat, impacting application performance.
• Steep Learning Curves: Learning and staying updated with a framework can be resource-intensive. Potential Disasters from Framework Dependence.
• Technological Lock-In: Relying solely on one framework can impede the adoption of newer, more efficient technologies.
• Security Risks: Misplaced trust in a framework’s security can lead to overlooked vulnerabilities.
• Maintenance Challenges: Older frameworks can become difficult to maintain, especially as technology evolves.

Mitigating Risks​

• Modular Approach: Integrating frameworks as part of a flexible technology strategy can reduce dependence.
• Continuous Learning: Encouraging developers to stay adept with multiple technologies ensures adaptability.
• Balancing Development: Discerning when to utilize framework features versus custom development is key.

Conclusion​

Frameworks have been the backbone of software development, continuously evolving to meet industry needs. While they are indispensable in modern software development, fostering standardization and rapid development, an over-reliance on them can lead to significant drawbacks, including reduced flexibility and potential long-term maintenance issues.

If you work in the automotive field and use AUTOSAR a lot, you’ve probably noticed how it kind of locks you in. It’s tough to break away from it, so you often end up sticking with it or having a hard time trying to switch to something else.