We Are Developers is one of those conferences where the sheer volume of content makes it impossible to catch even 10–15% of what is happening. With 10+ tracks of tech talks, 6+ workshops running 2 hours each, and a packed exhibition floor, the only winning strategy is to be deliberately selective — pick the areas that matter most to your current work and go deep there. Most of the talks end up on YouTube anyway, so the real value of attending in person is the workshops, the hallway conversations, and the booth visits.

I spent most of my time at the conference attending hands-on workshops, talking to people to catch key insights on Edge AI application development, visiting booths to understand what they offer and how their tools could fit into our work, and cherry-picking talks that aligned with these interests.

Company booth visits

The exhibition floor is where you get a concentrated view of where the industry is heading — each booth is a window into a specific bet someone is making. Here are the ones that stood out:

• Antithesis — their approach to test generation from “key property” based testing is compelling. Instead of writing individual test cases, you define the properties your system must satisfy, and their platform generates the tests automatically. Great potential for catching edge cases that manual test writing tends to miss.
• Qualcomm + Arduino + Edge Impulse — a joint showcase around Edge AI. Qualcomm has spun off an edge compute initiative where you can collect and train data using their software stack, paired with Arduino hardware for on-device deployment. The end-to-end flow from data collection to model training to edge deployment was well demonstrated.
• Snowflake — stopped by to understand the breadth of cloud services they now offer beyond the data warehousing core. The platform has expanded significantly into data applications and AI workloads.
• OpenSearch — the open-source search platform continues to mature. Useful to see how it positions against managed alternatives, especially for use cases where data sovereignty matters.
• Neo4j — graph-based search and knowledge representation. With the growing interest in graph-based retrieval for RAG systems, this was a timely visit to understand the current state of their APIs and integrations.
• Vercel — showcased their AI-powered platform capabilities — agents, skills, and the developer experience they are building around server-side AI inference. Interesting to see how they are thinking about the developer workflow for agentic applications.
• LaunchDarkly — beyond feature flags, they are now running tests automatically to find vulnerabilities and can revert deployments automatically when issues are detected. The shift from feature management to automated safety nets is a notable evolution.

Talks

Day 0 — Copilot inside IntelliJ IDEs

Day 0 was overcrowded and I could only attend one talk. The session on Co-Pilot inside IntelliJ IDEs showcased practices that are fairly regular for us now — code completion, context-aware suggestions, and the usual workflow integrations. One new learning stood out: a containerised method to run parallel tasks with a coding agent, enabling multiple agents to work simultaneously. You can also use git worktree to achieve something similar — spinning up isolated working trees so each agent has its own clean context to operate in. Practical and immediately useful.

Day 1

Thomas Dohmke — The Agentic Assembly Line was a highlight. The core idea: store context and memory that can be transferred across sessions. Instead of every coding session starting from scratch, the system retains the chat history and commit context alongside the code changes — so it understands not just what was done, but how the solution space was explored to arrive there. This is a significant step towards making coding agents feel like continuous collaborators rather than stateless tools.

The R in RAG: Why Retrieval is Often the Weakest Link (and How to Fix It) dug into the part of the RAG pipeline that most practitioners struggle with. The talk went beyond the usual “chunk your data better” advice and addressed the structural issues in retrieval that cause downstream generation quality to suffer.

Goodbye Microservices, Hello Self-Contained Systems made a case for a middle ground between monoliths and microservices — systems that are self-contained enough to be independently deployable and understandable, without the operational overhead that microservices architectures tend to accumulate.

Owning the Inference Layer: When and How to Run Your Own Models covered the decision framework for when to self-host inference versus relying on API providers, and the practical considerations around cost, latency, and control that go into that choice.

The Retrieval Layer for Edge AI was a demo session showing what edge AI applications can do in practice — live object detection through smart glasses. Seeing the retrieval and inference pipeline run in real-time on a constrained device made the practical possibilities feel much more tangible.

Inside Mercedes-Benz: 140 Years of Heritage Meet AI explored how a legacy automotive giant is integrating AI into its operations and products — a useful perspective on the challenges of bringing modern AI capabilities into established engineering cultures.

Nemotron: NVIDIA’s Open Model Strategy for Developers covered NVIDIA’s approach to open models aimed at giving developers more flexibility in deploying inference workloads, particularly for specialised domains.

Building the Nervous System of AI framed the infrastructure layer — the connectivity, data pipelines, and orchestration — that ties AI components together into functioning systems, much like a nervous system coordinates a body.

Physical AI for the Next Wave of Industrial Digitalisation was one of the most forward-looking talks. It covered the NVIDIA stack for physical AI: Omniverse for simulation environments, Cosmos for synthetic data generation, and Isaac for physical AI foundational models. All built around open-source models and blueprints designed to run on specific hardware. This is where the digital-physical gap starts closing.

Day 2

Future of Mobile AI: What On-Device Intelligence Means for App Developers was a comprehensive overview of where edge inference is heading. The key points:

• Models are small enough to run on devices — ranging from 300M to 1B to 3B parameters. Models like Gemma, Qwen, and Phi are making on-device inference practical for real applications.
• Runtimes — ONNX Runtime and llama.cpp are the dominant options for running these models efficiently on constrained hardware.
• Frameworks — MediaPipe and Cactus are making it easier to integrate on-device models into mobile applications without deep ML expertise.
• Hardware — NPUs and TPUs are now measured in FLOP/s and TOP/s (tera operations per second), and the available silicon is finally catching up to what these small models need.
• Arbitration approaches — the question of when to run on-device versus when to fall back to the cloud. Patterns discussed included mobile-first, cloud-first, intent classification to route requests, and a cascading approach where you try on-device first and escalate to cloud only when needed.

Workshops

Day 1

Accelerating AI Inference at Scale: A Deep Dive into NVIDIA Dynamo on Kubernetes was a hands-on session with dedicated hardware — 2 H100 GPUs each. The workshop covered:

• Basics of inferencing and the tokenization process inside LLMs — understanding what actually happens when tokens flow through the model.
• Disaggregation optimisation techniques — separating different stages of the inference pipeline (prefill vs decode) to optimise throughput and latency independently.
• Performance benchmarking with AI Perf for LLM inferencing workloads.

Having dedicated H100s for a hands-on notebook session is a rare opportunity — it made the optimisation concepts much more concrete when you could see the performance numbers change in real time.

Edge Impulse — Ducks, Sensors & Agents: Hands-On Edge AI with Arduino UNO Q was a full end-to-end edge AI workshop. Using the Arduino Q with the Qualcomm chip:

• Collected data on the Edge Impulse cloud instance — image data for object recognition and gyroscope data for motion classification.
• Trained models on the collected data directly within the platform.
• Deployed the trained models onto the Arduino hardware and ran inference locally — classifying ducks in real time from camera input.

The workshop was a clean demonstration of the full edge AI loop: collect → train → deploy → infer, all within a constrained hardware setup.

Day 2

Compress, Cut, and Distill: The Latest Gen AI Model Compression Techniques in Practice was directly relevant to anyone working on deploying models on edge devices. The workshop covered the full toolkit:

• Quantisation — reducing the precision of model weights to shrink model size and speed up inference, with practical guidance on when to use INT8, INT4, or mixed precision.
• Depth-wise pruning — removing entire layers from the model to reduce depth, trading some accuracy for significant gains in inference speed.
• Breadth-wise pruning — reducing the width of layers (fewer neurons per layer) while keeping the depth, a finer-grained approach to compression.
• Distillation techniques — training a smaller student model to mimic the behaviour of a larger teacher model, preserving much of the capability at a fraction of the compute cost.

Generate Synthetic Data for Physical AI with NVIDIA Cosmos World Foundation Models covered:

• What Cosmos models are and how they fit into the physical AI pipeline.
• Generating synthetic data with these models for training — particularly useful when real-world data is expensive or dangerous to collect.

Key takeaways

The overarching theme across the conference was clear: AI is moving closer to the edge, and the tooling to make that practical is finally maturing. From the small models (Gemma, Qwen, Phi) that can run on phones, to the runtimes (ONNX Runtime, llama.cpp) that make it efficient, to the hardware (NPUs, TPUs) that provides the compute — the full stack for on-device intelligence is coming together.

The other thread running through many talks and workshops was model optimisation as a first-class concern — quantisation, pruning, distillation, and disaggregated inference are no longer niche techniques but essential tools in any engineer’s toolkit for deploying AI at scale.

And the agentic wave continues to build — from coding agents that retain context across sessions, to the assembly-line patterns for orchestrating multiple agents, to the infrastructure plays from NVIDIA and others making it possible to run these systems efficiently. The shift from stateless tools to continuous collaborators is underway.

The thesis covers techniques for optimizing neural networks to run on edge devices. The central constraint at the edge is power — tokens per watt is the metric that matters, not raw throughput. Dr Trommer’s argument is that models can be optimized through quantization (both during training and post-training at inference time), and that quantization-aware training in particular yields meaningful gains. A key premise throughout is that training and inference should not be designed in isolation — thinking about them jointly produces better outcomes when deploying on embedded hardware.

Key Challenges of Edge AI Focused in this Work

• Energy efficiency: power consumed per inference is the primary performance metric; tokens per watt is what counts
• Memory constraints: RAM is limited, which affects how large a model can be, how fast it runs, and how much context it can hold — target inference speeds for coding models, for example, are around 40–50 tokens per second

Thinking from First Principles

• The bulk of computation during inference is spent on multiplication
• This is the core operation that GPUs and NPUs are built around
• Approximate multiplication exploits the fact that exact precision is not always necessary — tolerating small arithmetic errors in exchange for lower cost
• Model weights tend to be highly sparse: many values are near zero after training. By identifying and encoding only the non-zero parameters, the model can be compacted significantly, reducing both memory footprint and the number of operations needed at runtime — directly addressing the memory and power constraints of edge deployment

Chapter 1: Foundations of Efficient Neural Networks

• Overview of how to make models more efficient for deployment
• Post-training quantization: reducing numerical precision after training is complete
• Quantization-aware training: simulating quantization during training so the model learns to be robust to reduced precision
• Pruning: inducing sparsity by removing less important weights from the model
• Approximate computing: accepting small arithmetic errors to reduce computational cost

TorchApprox: A PyTorch Extension for Approximate Multiplication

• An extension to PyTorch that brings approximate multiplication into standard deep learning workflows
• Includes support for multiple quantization techniques, making it practical to experiment with approximate computing in training

Chapters 3 & 4: Approximate Multiplication in Depth

• Introduces approximate multiplication as a first-class design consideration for efficient models
• Model sensitivity to approximation errors can be predicted — this makes it possible to apply approximate multiplication selectively where it does least harm
• The space of possible approximate multipliers is unbounded, but bounding it to a practical subset enables hardware-efficient implementations

Chapter 5: Memory-Efficient Sparse Parameter Encoding

• Introduces a memory-efficient encoding scheme for sparse parameter matrices
• Addresses unstructured pruning, where individual weights are zeroed out rather than entire structures like filters or layers

Chapter 6: End-to-End Application

• Combines approximate multiplication and unstructured pruning in a practical deployment scenario
• The result: arithmetic resource usage and memory footprint are each reduced by approximately 50%

Dr Trommer is notably clear-eyed about the scope and limitations of the work — he explicitly identifies which perspectives are missing and what the study does not measure, with energy consumption being the primary axis of evaluation throughout. The thesis offers a coherent set of insights into how model training and inference can be co-optimized by targeting the most fundamental operation a processor performs: multiplication. The parallel thread on sparse parameter representation and memory-efficient encoding adds another practical dimension, showing how the structural properties of trained weights can themselves be leveraged to reduce the cost of running models on constrained hardware. Taken together, it is a focused and technically honest contribution to the problem of deploying capable models at the edge.

What is the agentic coding workflow?

The agentic coding workflow is about using LLMs as a thinking partner and a coding assistant — not just a smarter autocomplete. I started skeptical. Chat bots felt like a party trick; agentic workflows felt like hype. That changed when I started seeing real productivity gains on tasks that would have otherwise cost me hours: complex refactors, iterative debugging, developing implementations from high level design. Now I use coding agents across the full spectrum — from quick planning sketches to multi-session tasks that evolve well beyond my initial idea.

Setup of the coding harness

Every week there are new frontier coding models dropping, each claiming to break the previous benchmark. I’ve stopped chasing benchmarks and instead optimised for flexibility.

My daily workflow runs on two harnesses:

• Pi coding agent — fully open source, minimalist by design. You bring your own models, including local ones. That model-agnostic freedom is the main reason I consider it my primary harness. I’ve connected both local and frontier models to it, and the ability to swap without changing my workflow is something Claude Code can’t match.
• Claude Code — excellent capabilities, but strictly tied to Anthropic’s models behind API walls. I use it when I need the full weight of Sonnet/Opus on a hard problem.

How much can a 12B edge model actually do for coding?

Quite a lot, if you prompt it right. A 12B model falls apart on complex tasks when you dump everything at once — but break the task into small, well-scoped steps and prompt iteratively, and it holds up well. It handles code reviews, simple generation, and debugging reliably. My current pattern: use a heavy frontier model to create a clear, well-structured plan, then hand execution to the small model. It follows defined plans well. The cost savings are significant and the quality loss is minimal when the plan is tight.

Using skills effectively

Skills are how I extend what coding agents can do without burning tokens reinventing workflows in every session.

Skills I keep coming back to:

• tutor — when I want to go deep on a concept rather than just get an answer. Install: npx skills add piyja/myAgentsSkills/skills/tutor
• system design — when I’m designing a new system or architecture and want structured thinking from the agent
• grill-with-docs — starts a challenge session against your plan, grounded in your actual domain docs. Excellent for stress-testing a design before committing to it
• superpowers (Anthropic) — a collection of workflow primitives covering code generation, debugging, TDD, and more

Tips for cost-effective and efficient use of coding agents

1. Use plan mode first. High-level design before any code. Review and push back on the plan using your own engineering judgement — the agent is not always right.
2. Compact the context aggressively. When you’re approaching context limits, summarise and reset. Stale context degrades output quality.
3. Match model to task. Thinking and planning → heavy frontier model. Executing a clear plan → smaller, cheaper model.
4. Use skills. Don’t rebuild common workflows from scratch in every session.
5. Delegate plan execution to smaller models. A well-defined plan from a large model runs cleanly on a 12B. The quality gap closes fast when the task is well-specified.
6. Create session summaries. At the end of a long session, generate a structured summary and use it as context seed for the next one. Saves tokens, keeps the important decisions in scope.

Where I spend most of my time as a Software Engineer

The biggest leverage I’ve found with coding agents is in abstract thinking and solution design — not code generation. The agent becomes a sparring partner for exploring the problem space: brainstorming approaches, debating trade-offs, thinking through edge cases. It’s a good rubber duck, but one that pushes back.

The other place I invest heavily is test-driven development. Writing tests first forces you to think clearly about the problem before touching implementation. I use the agent to help write the tests, then write code to pass them. The loop is tighter and the designs come out cleaner.

Nvidia’s DRIVE team recently published a blog post on developing in-vehicle edge AI agents. I wanted to share my notes on it here and add further thoughts about the critical focus areas from the lens of product strategy and user requirements. Since I am working in the automotive domain, I find it important to keep an eye on the developments in the industry and also to understand how the big players are thinking about the future of in-vehicle AI agents. We can hinge our product development on these key evaluation parameters and critical focus areas and develop a reliable and robust agentic AI systems.

Arguments made in the article - a quick analysis

1. As building AI models powered applications is becoming common we are shifting away from hard Rule-based programming and entering new phase in which we make use of the AI powered Agents, the so called agentic AI shift. As fixed command-response doesn’t scale well; LLMs/VLMs enable conversational AI with memory, reasoning, and proactive assistance.
2. Although to get reliable output AI model requires a good amount of hardware acceleration. Real-time AI at the edge can be hard — if you have need to run 7B+ param models locally, preferably for multimodal use case. Importantly it also requires rethinking of the memory budget and not just the compute budget. The in cabin edge computation would require tight SLO/SLA of 400-500ms response time, >30 tokens/sec, multimodal inputs (camera + audio + telemetry), all while preserving privacy of the users.
3. The user experience for invehicle can be greatly enhanced by leveraging edge models with input from the cloud in form of compute, tools or peer agents. This blog talked about the hybrid cloud-edge architecture — Local agents for in-car tasks, cloud agents for use case like web/trip planning; key challenges would be here to correctly route intent, context sharing, and graceful degradation when the vehicle is offline.

4. The pipeline for agentic voice based assistants briefly contains this chain

   wake word -> ASR -> Orchestrator -> LLM inference -> Tools -> TTS -> audio output

   The orchestrator is the key component that routes user input to the right LLM, manages context, and handles fallback when the vehicle is offline. Nvidia’s NeMo Agent Toolkit serves as the glue for building, orchestrating and evaulating these agents.

5. For the OEMs, Nvidia comes with a hardware solution in 3 levels each with more commitment for AI ready hardware stack:
   • AI Box build with DRIVE AGX as a modular add-on to the existing IVI system providing a plug and play solution for AI agents without full E/E redesign. But the downside would be increased inter processor communication latency and potential bottlenecks.
   • DRIVE AGX Thor taking the above solution further by utlizing blackwell GPUs serving a platform for AI workload for the whole vehicle
   • A single central car computer fused with DRIVE AGX fused with the MediaTek Dimensity AX SoC - a fully integrated solution for infotainment and AI workloads, but would require more commitment to the new hardware architecture. Will have a great upside that latency for data communication will be the lowest but then again it would require a full redesign of the E/E architecture and software stack.

Critical focus areas for building in-vehicle AI agents

1. Specialised models for the voice pipeline — The 500ms-700ms end-to-end SLA is a budget distributed across every stage of the pipeline. Each arrow in Wake Word → ASR → Orchestrator → LLM → TTS → Audio Output carries a latency cost, leaving roughly 150ms per stage — which immediately constrains model size and quantization decisions at every step.

   Starting upstream: always-on wake word detection is a distinct engineering problem that precedes the ASR stage. It must run continuously on a low-power audio DSP with a near-zero false-positive rate — misfires while driving are both annoying and a safety distraction.

   For ASR, Mixture-of-Experts (MoE) architectures are well suited to automotive conditions because the acoustic environment is finite set of profiles (highway noise, HVAC, music, quiet cabin). MoE routing can specialise experts per acoustic profile, and the router can be conditioned on vehicle telemetry (speed as a proxy for road noise, HVAC state) before audio even arrives — proactive expert selection rather than reactive. The tradeoff: MoE models have a higher total parameter count even when only a fraction activates, so they require careful VRAM budgeting on edge hardware.

   For TTS, streaming token-by-token output directly to the audio renderer is the single highest-leverage latency optimisation available. The first audio chunk can begin playing while subsequent tokens are still being generated, cutting perceived response time significantly even if wall-clock total is unchanged.

   The orchestrator LLM also deserves specific attention: for a voice assistant context, its fine-tuning objective is fundamentally different from a general-purpose LLM. Inputs are short, intent-dense, and often acoustically degraded. The model needs to be optimised for rapid intent classification and slot filling. The reasoning part can be tricky and optional as we could have complex queries coming from user which would require reasoning over multiple tools. Alas we have to find a balance here.

   Finally, user feedback comes in three distinct forms with different pipeline implications: explicit (thumbs up/down), implicit (user rephrasing the same request after a failure), and behavioural (abandoning the interaction entirely). Treating all three as a single “feedback loop” leads to muddled improvement signals — each requires a different data pipeline and triggers different retraining decisions.

2. Platform scalability and the standardisation gap — We need automotive software standards that address agentic AI orchestration. AUTOSAR Adaptive has introduced ML model management interfaces, but we also need agent-to-agent communication contracts, tool calling interfaces, memory management for multi-turn context, or evaluation criteria for agentic behaviour. OEM-specific frameworks share the same gap and in my opinion this is a significant structural requirement for long-term scalability of in-vehicle AI agents.

   The cloud/edge routing question also carries a hard constraint that “location-agnostic” framing obscures: some tasks cannot be cloud-routed regardless of latency or connectivity, not for performance reasons but for safety and regulatory ones. An agent recognising a medical emergency must complete that interaction fully on-edge. Safety-critical voice paths and comfort/infotainment paths have fundamentally different routing requirements, fallback policies, and hardware resource allocations — treating them as a single routable workload is architecturally incorrect.

   Testing and evaluation for automotive voice agents cannot rely on general-purpose LLM benchmarks. What is needed — and does not yet exist as a public standard — is domain-specific evaluation covering: navigation command accuracy across real address formats, HVAC and media control intent parsing, multi-turn context retention under acoustic degradation, and regional language and accent coverage. Building such an evaluation framework is a prerequisite for any serious agent improvement programme.

3. Agents deep in the automotive software stack

   Automotive software enforces hard partitioning between safety domains through a hypervisor managing multiple OSes simultaneously: typically a real-time OS for safety-critical functions, QNX or equivalent for high-availability services, and Linux for infotainment and AI workloads. An AI agent running in the Linux partition has no direct path to safety-critical vehicle functions — all communication must cross hypervisor guest boundaries via IPC or RPC, adding latency and introducing a new class of failure modes that must be explicitly designed against.

   The core tension is that LLM-powered flexibility is inherently non-deterministic, while Classic AUTOSAR at ASIL-D requires hard real-time determinism. These properties cannot be reconciled by pushing the LLM deeper into the stack. The practical architectural answer is that the LLM remains at the application layer and communicates intent downward through well-defined, auditable tool-calling interfaces — constrained API boundaries that enforce certifiable behaviour at the safety layer while allowing flexible reasoning above it.

4. Personalised and context-aware setup — Agentic setup offers means to highly personalise the setup as per the user and continuously improve the agents - dedicated pipelines can be designed to receive and store feedback from the user, handle errors, and continuous improvement of the agent’s performance in real-world conditions.

Closing points

Navigating this moving landscape of AI engineering and taking steps to create platform for building and iterating on AI agents in the future can be tough. But with wholistic design thinking and a user-product centric approach we can build system ready for the future. Finally the onus is on the decision making step - on deciding what to build!

In the last weeks and months I have been reflecting on my journey as software engineer, how my formal studies of Engineering Design played a role into shaping my perspective as a engineer. I have been keeping this perspective in mind while working on various projects but recently thought of adding it here to keep it as live journal. On the high level these I have captured my reflections in the following sections. I started to work as product development engineer for embedded systems and transitioned into software engineering developing full software systems but still focusing on resource constraints embedded devices. I want to jot down some thoughts on how the background of design engineering helps me to think at layers of abstraction.

What is design engineering?

Design engineering involves amalgamating principles of different engineerings disciplines, understanding the user needs, the problem space and the solution space, and designing solutions that are not only technically sound but also user-friendly, scalable, and maintainable. It requires a deep understanding of the problem domain, abstract thinking in designing solutions, systems thinking and most importantly the ability to think holistically about the system being designed.

Provides a framework to think about problems and solutions at different layers of abstraction

• Finding which problems to solve first, understanding the user needs and the business opportunity, etc. This helps in prioritizing the work and focusing on the most impactful problems to solve.
• Solutions thinking - from problem break down, targetted solutions and how to form strategies to tackle them. Holistically thinking about the system, the users, the problem space, the solution space, helps to understand the problems and solution space. Designing solutions weighing different trade-offs and considering different constraints.
• From the high level of abstraction - understanding the user needs, the problem space and the solution space, etc. This helps in not getting bogged down by the details and focusing on the bigger picture, understanding the dependencies between different components of the system.
• From the low level of abstraction - understanding the technical details, the constraints and trade-offs involved in building solutions, etc.

What is abstract thinking - how does it help in problem solving and solution design?

• Abstract thinking involves looking at the problem from a high level of abstraction, understanding the problem space and the solution space, etc.
• This helps in not getting bogged down by the details and focusing on the bigger picture, understanding the dependencies between different components of the system, etc.
• Breaking down the problem into smaller subproblems, understanding the dependencies between them, etc.

What ticks me and using this Design Engineering background as an asset

The framework discuss above helps lock the perspective towards owning the outcome (impact) of the work vs from the output perspective (know how and why from engineering).

My journey into product development, embedded systems, and now in SWE. What is Software engineering to me?

• In the early years of product development - exploring building blocks of engineering, understanding how things work, how they are built, etc. To dive deeper into the working of each I decided to understand the embedded systems - from PCB designs, hardware selection, firmware and driver development. This helped me to understand the working of the system at a deeper level and also understand the constraints and trade-offs involved in building solutions for embedded systems.
• Scaling those embedded systems both horizontally (across different product lines) and vertically (adding more features and capabilities) led me to software engineering. I started to work on building software solutions providing targeted solutions in form of platforms and modular designs to increase reusability and bring scale inherently into the design. This helped me to draw the design thinking into the software products and bring the abstract thinking into the software design and development process.
• To me software engineering is about building software products that are technically sound, user-friendly, scalable, and maintainable as it also involves understanding the problem space and the solution space. It is a building block of a system which works together with other building blocks to create a complete system.

Thinking as a PM first and then SWE

• Traits of a good PM - vision on what to build, understanding of the users and their needs, business value it generates, understanding of the problem space and the solution space, ability to drive the product development process.
• One crucial aspect which design engineering did not explicitly teach but I have learned over the years is the importance of business value and how it is crucial to understand the business value of the solutions we build. This is important to ensure that we are building solutions that aligns and generate value for the business and the users.
• Thinking as a PM first helps to understand who our customers are really, what are their problems and needs and then focus on solution development around them.
• How I fit this perspective into my work as a SWE - as every role has their customers - for a SWE the customers are the users of the software, the stakeholders who are impacted by the software and the business sense it drives
• Thinking from the design frameworks point of view - understanding the user needs, the problem space and the solution space, etc. helps to understand the problems and solution space. Designing solutions weighing different trade-offs and considering different constraints.
• There is a great overlap of this thought process with Software Architect roles who are usually responsible for designing the overall structure of the software system and greatly benefiting from the abstract thinking perspective and using the above framework.

What I am excited about in the future?

• Future of software engineering and how it is coming towards product thinking
• Working as a SWE during the GenAI and agentic transformation
  • Helps one to think on higher level of abstraction
• Building products that are powered by GenAI and agentic capabilities

Agentic applications are softwares which builds around AI models to utilize it as a decision making and reasoning engine along with the tools and external systems it interacts with. AI models are used as the controller to this systems that can also trigger the actions based on the data and context it receives. This enables the applications to shift away from hard coded rules and logic increasingly making them more flexible, adaptable and intelligent.

Before the agentic term was coined by Andrew Ng, Lilian Weng described such application in her blog “LLM Powered Autonomous Agents” in 2023. In her blog, she describes how LLMs can be used to build autonomous agents that can perform complex tasks by breaking them down into smaller sub-tasks and delegating them to different agents or tools. Here in this blog we are building on the ideas which Lilian pitched had already picthed and have become standard to develop agentic applications today but also going to add more structure, design principles and learning from the community over this time.

Benefits of agentic applications

Agentic applications utilises the power of AI models more effectively. By building around the AI models, agentic applications can leverage the models’ ability to learn from data and adapt to new situations, making them more flexible and adaptable than traditional applications. This allows for more complex and sophisticated applications that can handle a wider range of tasks and scenarios. It also allows the applications to be not hard coded and rule based anymore.

Core components of an agentic application

Agentic applications typically consist of several core components that work together to enable the application to function autonomously. These components include:

1. AI models and inference server layer - the core reasoning engine which comprehends and derives meaning from the application
   • This is the core component of the agentic application which is responsible for understanding the context, making decisions and generating responses based on the data it receives. The AI model can be a large language model (LLM) or any other type of AI model that is suitable for the task at hand. The inference server layer is responsible for managing the communication between the AI model and the other components of the application, as well as handling the inference requests and responses.
2. Reasoning and task planning module
   • Reasoning step is the most crucial step where the AI model thinks about the task at hand and generates a plan of action to achieve the desired outcome. This can be steps like breaking down the task into smaller sub-tasks, identifying the tools and resources needed to complete the task, and determining the best course of action to take.
   • Task decomposition step - methods which breaks down complex tasks into smaller sub-tasks to be delegated to different agents or tools in the system. This can involve techniques such as hierarchical task decomposition, where tasks are broken down into a hierarchy of sub-tasks, or flat task decomposition, where tasks are broken down into a flat list of sub-tasks.
3. Orchestrator layer and agent loop architecture - the system that manages the flow of information and tasks between the AI model, task decomposer, tools, other agents and evaluate results.
   • The react loop of observe → think → act → observe again. This sits at the heart of the application and is responsible for ensuring that the different components cordinates and communicates seamlessly to achieve the desired outcomes.
   • Together with the reasoning step this forms the basis for ReAct (Reasoning and Acting) pattern which is widely used in agentic applications
4. Taking actions via tools - the external systems and APIs that the AI model can interact with the external world by performing actions and gather information
   • Tool usage can be triggered by the reasoning module or can be hard coded for specific tasks. For example, if the task is to book a flight, the reasoning module can trigger the use of a flight booking tool to complete the task.
   • Standards used for tool usage and integration - A2A protocol, MCP servers, etc. which allows to scale and develop such tools independently and also share them across different agents in the system
   • Each agent can use multiple tools at a time and also share tools with other agents in the system
5. Context management - system which decides how to prune vs summarize the stored cache used for the session data
   • Context is basically what the AI model can see right now, as inherently models are stateless and every call must contains all the details required by it to generate the output.
   • What does the current context contain?
     • system prompt
     • retrived data
     • recent messages
     • tools and it’s output
   • As the context can grow linearly over time, we need strategies to trim or summarize it. Common techniques include sliding window, summarize-and-compress, hierarchical isolation, etc.
6. Memory - unlike context here the context data is stored for future use by the models as well as read for current inference cycle
   • Short term memory - the system that stores the information and context for the AI model to use in its decision making process over a short period of time
   • Long term memory - the system that stores the information and context for the AI model to use in its decision making process over a long period of time
   • External memory and knowledge base stored as vector embeddings or more recently graph database are gaining popularity as the long term memory for the AI models
7. Data and evaluation metrics pipeline - the system that collects, processes and feeds data to the AI model
   • This can include data from user interactions, tool usage, and other sources that can be used to train and improve the AI model over time. It also includes the evaluation metrics that are used to measure the performance of the AI model and the overall system. This can include metrics such as accuracy, precision, recall, F1 score, etc. which are used to evaluate how well the AI model is performing on the tasks it is designed to handle.
   • Heuristic-based agents - Heuristics means the rules of thumb, the mental shortcut a pragmatic engineer would take while designing a product. These are agents that are designed to follow a set of predefined rules or heuristics to make decisions and take actions. These agents can be useful in situations where the task is well-defined and can be easily codified into a set of rules. However, they may not be as flexible or adaptable as AI model-based agents, which can learn from data and adapt to new situations.
     • rule-based systems
     • expert systems
     • decision trees
     • finite state machines
   • Chain of hindsight - the system that collects feedback from users and other sources to improve the performance of the AI model over time. This can include techniques such as reinforcement learning, where the AI model learns from the feedback it receives to improve its performance on the tasks it is designed to handle. Chain of hindsight is a technique where the AI model can learn from its past mistakes and successes by analyzing the outcomes of its actions and using that information to improve its future decision making process.
8. Trust & safety boundaries — one of the most critical design concerns in agentic systems. How do you constrain what an agent can do? Sandboxing, permission scopes, human-in-the-loop checkpoints. irreversible action guards.
   • This is a crucial aspect of designing agentic applications, as it is important to ensure that the AI model does not take actions that could be harmful or unethical. This can be achieved through techniques such as sandboxing, where the AI model is isolated from the rest of the system and can only interact with it through a controlled interface, or through permission scopes, where the AI model is only allowed to access certain resources or perform certain actions based on predefined rules. Additionally, human-in-the-loop checkpoints can be used to allow for human oversight and intervention in critical decision-making processes.

Developing application with Multi-agent

Why do we need multiple agents in an application?

Inorder to maintain separation of concerns and make expert modules for different tasks, it is advices to have multiple agents in an application. This allows for better modularity, scalability and maintainability of the application. Each agent can be designed to specialize in a specific task or domain, allowing for more efficient and effective performance. Although it add challenges on the communication and task orchestration between the agents, it is a trade off worth making for the benefits it provides.

Design principles for multi-agent systems

• Modularity - each agent should be designed to specialize in a specific task or domain, allowing for better modularity and separation of concerns
• Communication - communicate and share information effectively to achieve the desired outcomes
• Coordination - coordinate their actions and tasks to achieve the desired outcomes
• Scalability - scale as the number of agents and tasks increases
• Robustness - handle failures and errors gracefully by retry/fallback/partial-pass/escalate mechanisms

Orchestration patterns for multi-agent systems

Decision Control Patterns

• Centralized orchestration - a single orchestrator agent manages the flow of information and tasks between the different agents in the system. This can be simpler to implement but may become a bottleneck as the number of agents increases.
• Decentralized orchestration - each agent is responsible for managing its own tasks and communication with other agents. This can be more complex to implement but can provide better scalability and robustness.
• Hybrid orchestration - a combination of centralized and decentralized orchestration, where some agents are responsible for managing their own tasks and communication, while others are managed by a central orchestrator. This can provide a balance between simplicity and scalability.

Flow Control Patterns

• hierarchical orchestration - agents are organized in a hierarchical structure, where higher-level agents manage the flow of information and tasks between lower-level agents. This can provide better modularity and separation of concerns but may require more complex communication and coordination between agents.
• peer-to-peer orchestration - agents communicate and coordinate directly with each other without a central orchestr ator. This can provide better scalability and robustness but may require more complex communication and coordination between agents.
• event-driven orchestration - agents communicate and coordinate based on events and triggers, allowing for more flexible and dynamic interactions between agents. This can provide better adaptability and responsiveness but may require more complex event management and coordination between agents.
• pipeline orchestration - agents are organized in a pipeline structure, where the output of one agent serves as the input for the next agent in the pipeline. This can provide better modularity and separation of concerns but may require more complex communication and coordination between agents.

I hope this gives a good overview of the moving parts and design principles for building agentic applications. As the state of the art of this field is evolving rapidly, I will keep updating this post with new learnings and insights from the community. If you have any suggestions or feedback, please feel free to reach out!

On the quest of learning the horizontals topics in automotive software, I found myself willing to know more about the security features and measures used in automotive software development. As developer within the infotainment business of the automotive I find security as growing requirement as the capabilities of it are ever-growing. Infotainment Electronic Control Units (ECUs) have emerged as potent components within vehicles, often handling critical functionalities. My expectation from the book was to gain insights into how security is intricately woven into the software development lifecycle. I anticipated learning about various security features implemented in automotive systems, as well as the diverse types of security testing conducted. This knowledge would not only enrich my understanding of current practices but also equip me with the necessary tools to navigate and contribute effectively within the humungous landscape of automotive software development.

What did I learn from the book

The author effectively underscores the critical importance of security and adeptly caters to newcomers by providing detailed explanations. While seasoned professionals may find some concepts verbose, this approach ultimately deepens understanding. Key concepts that stood out and are worthy of highlighting are mentioned in the below part of the blog:

Importance of security in automotive

Given the rapid evolution and increasing complexity of modern vehicles following are points which state why software security is crucial:

1. Growing Capabilities and Dependency on Software: Modern vehicles are becoming increasingly sophisticated, relying heavily on software to manage everything from basic functions to advanced features like autonomous driving. This growing dependency means that the integrity and security of the software are paramount.
2. Increased Code Complexity and Potential Vulnerabilities: As the amount of code within a vehicle’s systems increases, so does the potential for vulnerabilities. More lines of code create more opportunities for bugs and security flaws, making robust security measures essential.
3. Elevated Risk Factors: With the introduction of more capabilities, the risk associated with potential vulnerabilities also rises. Security breaches can have severe consequences, affecting not only the vehicle’s functionality but also the safety of passengers and pedestrians.
4. Necessity for Updated Security Features and Testing: The dynamic nature of automotive technology demands the most current security features to protect against emerging threats. Regular and thorough security testing is crucial to identify and address vulnerabilities early in the development process, ensuring that vehicles remain secure against potential attacks.

How can we make automotive more secure - Static approaches

Secure hardware solutions

Hardware solutions play a crucial role in enhancing the security of automotive software by enabling privileged access to applications and ensuring the integrity of the system. Key hardware-based security features include secure boot, secure flash, secure log, and secure debug. These mechanisms ensure that only authorized software can run on the vehicle’s systems, protecting against unauthorized access and tampering.

Additionally, trust-based systems can be implemented to physically isolate sensitive data and manage secure connections. This can be achieved through secure trust zones, which create a dedicated and protected environment within the hardware. These secure zones store sensitive information and control access using robust security protocols, thereby enhancing the overall security posture of the automotive system. By leveraging these hardware security measures, automotive manufacturers can provide a more secure and resilient platform for their vehicles, safeguarding against a wide range of potential threats.

Software composition analysis of open source components

Software composition analysis involves understanding the various components that make up an application and the dependencies it relies on. By thoroughly analyzing the composition of your software, you can identify all the open-source components integrated into your application. It helps in recognizing known vulnerabilities and flaws associated with these open-source components. Many open-source libraries and modules have publicly documented security issues, and being aware of these can prevent the introduction of potential security risks into your software. It enables proactive management of software updates and patches, ensuring that any vulnerabilities discovered in the open-source components are promptly addressed. It also supports compliance with industry standards and regulations, thereby contributing to the creation of a secure and reliable automotive software environment.

Static code analysis (SCA)

Static code analysis (or linters) are means of checking software code for abiding to the coding standards by parsing the source code. These checks are run without executing the code on the software code base. The checks are not just on a particular statement or definition but can also detect issues in a block of related source code. It can find both syntactic and semantic code violations within the code base. Specific to automotive industry some consortiums have developed coding standards to be followed in automotive software, like MISRA and AUTOSAR. There are many open sources projects which offers many of these standards included in the SCA tooling software. As well there few proprietary software like, Coverity covers about the majority of the coding standards into their linter and has about 400 coding guidelines which it covers. These standards are split in categories of severeness - mandatory, required and advised. For safety related code within automotive there are stricter guidelines which are covered in ASIL-D <(ISO, SIL B-C??)> coding standards. Not all software component would need to abide by all coding standards and can be configured according to the functional severity. Albeit, one thing is worth mentioning some violations could be false positive and there are provisions to bypass this and allow deviations case by case, although this requires human code review.

For the legacy code where we would get unmanageable amount of code violations at first, one has to set up a framework to be able to introduce this gradually into the full working. This could mean segregation of the software components based on the functional severity and enabling the coding guidelines as per this severity. Then case by case going through the violations to identify which ones should be resolved at a priority hierarchy.

How can we make automotive more secure

By Shifting left

By introducing security testing approaches in the (software development V cycle)[] we can bring more robustness into the software. These testing can be performed in the cycle to expose vulnerability earlier and to avoid making security being an afterthought at the verifications step.

Theoretical Approach

Theoretical approaches like Threat Analysis and Risk Assessment (TARA) can prove to be a beneficial starting step to analyze the software. It involves identifying the assets and threat scenarios and creating risk assessment of the identifies threats. It proves to be greatly beneficial if carried out multiple times in the development cycle. The final output of this analysis is list of identifies threats and associated risks with it which can be sorted by their priorities. There are good open source tools like (pyTM)[https://github.com/izar/pytm] which can be used create a graphical output of the analysis using graphviz. Albeit, TARA would also be classified as a static approach in identifying threats.

To make automotive more secure, more than static approaches are essential, by dynamic I mean in which we emulate close to actual use case of the automotive systems. From testing point of view this involves controlling the external environment for the system under test (SUT) and monitoring its behavior. In the following section we will see more about them.

Practical testing approaches

Practical testing approaches can be divided into following sections:

Functional security testing

Akin to system function testing, the focus is on validating the effectiveness of essential security functionalities. This encompasses rigorous testing of critical security features integrated into the communication stack, such as SecOC (Secure Onboard Communication), and evaluating standard encryption mechanisms applied to cryptographic algorithms for handling sensitive data. Additionally, assessing the reliability and performance of components like the true random generator is vital.

Vulnerability testing

In vulnerability testing, the initial phase involves comprehensive information gathering focused on understanding the system’s core components. This process employs various scanning techniques from multiple perspectives to thoroughly examine the software. Communication ports are scanned to identify potential vulnerabilities, while configurations used within the software are meticulously scrutinized. Additionally, critical details such as the communication protocols utilized by the target system are analyzed to gain deeper insights into its operational structure. Once these key components are identified, the next step involves gathering and analyzing potential threats. This proactive approach ensures that developers can anticipate security risks early in the development process, thereby integrating robust defensive measures into the automotive software.

Fuzz testing

Fuzz testing is a method used to evaluate the behavior and robustness of an application by providing randomly generated data as input and observing how the system responds. It is highly adaptable, with no single fixed approach and also incorporate model-based input generation, which systematically produces random data inputs to enhance the testing process. This technique is instrumental in identifying vulnerabilities and weaknesses within the software.

A typical fuzz testing setup involves three main components:

• Engine: Responsible for generating randomized inputs.
• Injector: Introduces these inputs into the application under test.
• Monitor: Observes and checks the application’s behavior for any anomalies or crashes.

There are three main types of fuzz testing:

• Black Box Testing: Testers have no knowledge of the internal workings of the application. Inputs are generated and injected without any insight into the system’s internals.
• Grey Box Testing: Involves partial knowledge of the system, allowing testers to create more informed and targeted inputs while still retaining some randomness.
• White Box Testing: Testers have full knowledge of the system, enabling them to create highly specific and strategic inputs to probe for vulnerabilities. The author covers fuzz testing in great detail across many chapters of the book. This comprehensive exploration provides a deeper understanding of how fuzz testing can be effectively employed to enhance the security and reliability of automotive software. We will cover key information here in the blog but for more detailed explanations and advanced topics on fuzz testing, refer to the later sections of the book.

Testing classical AUTOSAR components

“Shifting-left” approach in the software development V model pushes us to integrate testing earlier in the development process to identify and resolve issues sooner. Owning to the vast security knowledge coming from IT industry, testing automotive specific CAN protocol based Classic AUTOSAR components can be particularly challenging, necessitating the use of Hardware-in-the-Loop (HIL) testing to ensure thorough and accurate validation. HIL testing involves two primary types of result monitoring:

• White Box Testing: This approach involves monitoring the internal states of the System Under Test (SUT). It provides detailed insights into the internal workings and allows for the identification of specific issues within the system’s components.
• Black Box Testing: In this method, the overall behavior of the system is monitored without focusing on its internal states. Usually in the case system’s performance is compared against an identical reference behavior to ensure it operates as expected.

The integration of HIL in fuzz testing offers significant benefits, particularly in terms of quality of the feedback. By simulating real-world conditions we can get the closer to real life feedback from the hardware interactions, which helps in identifying and catching exceptions that might not be evident through software-only testing. This approach leads to the development of more robust and reliable automotive software, ensuring the system meets the stringent requirements of modern automotive applications.

Testing Services Within Operating Systems (OS)

As automotive software becomes increasingly complex with the integration of custom OS, it is essential to adapt our testing strategies accordingly. One effective approach is white box fuzz testing, which employs agents to monitor and capture detailed information about various processes composed in the automotive OS. These agents track critical OS details such as memory corruptions (e.g., use-after-free errors), heap and stack checks, initialization order problems, memory leaks, core dumps, process monitoring, system logs etc.

External agents play a significant role in monitoring the communication layer, including protocols like Bluetooth, WiFi, MQTT, and file formats. This comprehensive monitoring helps in identifying vulnerabilities and ensuring the robustness of the automotive software.

There are two primary types of monitoring methodologies:

• Asynchronous Monitoring: random inputs are provided without waiting for corresponding results. The advantage of asynchronous monitoring is the speed at which results are delivered. However, the downside is that there are fewer options for tracking and tracing the outcomes, which can make it harder to diagnose issues.
• Synchronous Monitoring: This method involves waiting for the results of each input action before proceeding to the next which cause delays. The main advantage of synchronous monitoring is that it allows for easy tracking and tracing of results, making it simpler to identify and resolve issues.

Penetration testing

Penetration testing is a crucial security evaluation performed in the final stages of product development. Its primary objective is to identify and exploit potential vulnerabilities within the system to understand how it might fail under various attack scenarios. This type of testing requires detailed understanding of the system to create situations that could lead to application failures.

• Black Box Testing: In this approach, the tester has an understanding of the system behavior but no insider knowledge of its internal workings. The tester uses this information to attempt to exploit the system, identifying vulnerabilities that an external attacker might find.

• White Box Testing: This method involves the tester having comprehensive insider knowledge of the system. While it can be debated how realistic such attack scenarios might be, this approach is invaluable for understanding the risks associated with internal threats. By leveraging detailed system information, testers can perform more targeted and thorough security assessments.

Penetration testing provides a holistic view of the system’s security posture, helping developers identify and mitigate potential risks before the product is released. This ensures that the releases are more robust and resilient against potential attacks.

Robust frameworks are required

While various tests are crucial for proving the robustness of a system, merely having test suites is insufficient. To ensure comprehensive security testing throughout the product development and maintenance lifecycle, a robust framework is essential. Such a framework provides a systematic approach to security testing, ensuring that all aspects of the system are thoroughly evaluated, and any potential vulnerabilities are addressed promptly. A robust framework must contain following steps: Analyse the problems, set the goals, Identify the current state, define strategy to archive goals and execution.

Continuous monitoring

Performing security tests once is not sufficient to ensure the ongoing robustness and security of automotive software systems. Continuous monitoring is essential to maintain a high level of security and quickly identify and address new vulnerabilities as they arise. Such a system continuously monitors the application and its environment for potential security threats and anomalies. This approach ensures that any new vulnerabilities or changes in the system’s behavior are detected promptly, allowing for immediate corrective actions.

Hope you enjoyed reading the blog and learned new concepts about security testing. If this blog intrigued I would recommend diving further into the book.

Before delving more into AA, let’s understand more about AUTOSAR and its developments before AA.

What is the AUTOSAR Consortium?

The AUTOSAR Consortium is a joint effort from leading automotive industry companies to create and define open system architecture standards for automotive. This includes not only providing a standardized software architecture and framework, but also the base standards for E/E architecture. It’s fascinating to see how competitive automobile companies have come together to create unified standards and pave the road for future developments.

So, what software standards are they?

• Foundation standards - created to ensure a high degree of interoperability between components of AUTOSAR platforms, i.e., Adaptive and Classic, as well as within AUTOSAR to non-AUTOSAR platforms.
• Platform standards - like Classic and Adaptive AUTOSAR standards. More on this in the following sections of the article.
• Application interfaces - introduced various standardization processes for the communication protocols, syntax, and semantics for all applications to communicate in commonly understood terms.
• Acceptance test packages - various standards are set for system tests to ensure the developed applications comply with the set standards.

More about Classic AUTOSAR

The main purpose of Classic AUTOSAR is to achieve hardware and platform independence for AUTOSAR applications. The underlying layers of software are more dedicated to the type of hardware and platform. AUTOSAR provides a runtime environment (RTE), which is a software abstraction layer that the application software uses to work with hardware-oriented basic software (BSW). AUTOSAR also provides standardization guidelines for this BSW layer. Along with this, it has introduced common methodologies for configuring the AUTOSAR stacks.

Classic AUTOSAR provides the base format for integrating a new ECU into the vehicle network. It mainly addresses the signal-based approach of communication, i.e., CAN bus, LIN bus, etc. With this approach, endpoints can be easily configured with config files without changing the application software. However, for an update in the software component, an update of the entire ECU firmware is essential, which is a major drawback. Another disadvantage is that adding a new ECU usually requires a major change in the schema.

However, in the following sections, we will see how Adaptive AUTOSAR overcomes these challenges and at what cost.

Understanding Adaptive AUTOSAR

Why are automotive software components moving towards Adaptive AUTOSAR?

As more compute-demanding features like ADAS and V2X are being integrated, the number of ECUs and the computational capacity of the ECUs in automotive have been continually growing. This poses a challenge for designing the communication between these endpoints. Adaptive AUTOSAR (AA) proposes to integrate domain-specific high-performance ECUs in the vehicle to serve as a gateway for communication into each domain. Smaller footprint embedded ECUs directly connect to their respective domain’s high-performance ECU in order to communicate with the entire vehicle network. Another advantage of an AA application is that it can be configured and integrated into the system at runtime. This allows a number of independent services to be developed, tested, and deployed as applications independently.

Embracing the change in the way of communication between the software components

As we have seen, there is increased usage of gateway ECUs to enhance the efficiency of the vehicle network. These domain ECUs manage the communication with smaller ECUs using a signal-based protocol and communicate with other domain ECUs using IP-based protocols to form a domain controller architecture. This allows more sophisticated frameworks like service-oriented communication to be possible in automotive software. These services can be either servers (data providers or provider ports) or clients (data consumers or required ports) and communicate in the following ways for any data transfer:

• Direct method calls
• Event-based communication
• Topic or Data field subscription

The system design manifest files define how these servers and clients are laid out in the E/E architecture. An application developer can use both IPC or RPC method calls to a known service in the same manner without knowing the underlying modes of communication. AA also uses what is commonly known as the “Service Discovery” mechanism to keep track of up and running services offered on the vehicle network.

Adaptive AUTOSAR Architecture

The Adaptive AUTOSAR (AA) software middleware stack can be thought of as a broader and wider design than Classic AUTOSAR, also known as AUTOSAR Runtime for Adaptive Applications (ARA). The modules within the ARA can be accessed through the ara:: namespace within C++ applications and are platform-agnostic. The AA application uses ARA modules and sits at the top of the software architecture block designs, while the hardware drivers, hypervisors, and container modules sit at the bottom of the ARA components. The following is a non-exhaustive list of modules that ARA offers:

• Core platform services
  • Network
  • State management, etc.
• Platform foundation
  • Communications stack
  • Persistency
  • Logging and trace
  • Platform health, etc.
  • Includes all PSE51 POSIX APIs provided by the OS

Process Workflow and Modelling for AA Applications

The process workflow for developing AA applications consists of modelling, auto-generating source code, and then developing the application software. The modelling steps involve filling in the details of the manifest files, which are then used to develop the auto-generated source code. Manifest files are divided into the following three parts:

• System design
• Machine and execution level
• Deployment level

So, what is adaptive about Adaptive AUTOSAR?

While learning about AA topics, many of us have queries centered around this question. I will attempt to explain this in my own words.

Adaptive AUTOSAR (AA) provides a platform for applications to become platform-agnostic. This means that the applications developed are not constrained to a particular platform or hardware type, as it separates configurations from the application software. It uses manifest files in the form of JSON extensions, which are configured alongside the application being developed. The final binary flashed onto the ECUs contains the application binaries and deployment configuration manifest files. These manifest files also define the service and client endpoint definitions, allowing for dynamic runtime linking between them for communication.

As we also saw earlier in this article how independent features can be divided into AA applications or services. These applications can be also tested and deployed into the ECUs making it a very easy process to roll out any AA updates into the vehicle as opposed to completely re-flashing the ECU software. This adds a lot of agility into the AA applications.

Do you have safety-critical or hard real-time requirements for your applications?

As AA applications run on the ARA platform, which is capable of keeping the soft real-time requirements, it is not completely reliable for the hard real-time requirements. For example, engine control and brake systems. If the application’s requirement is to provide safety-critical features such as air-bag ECUs, it is recommended to use classic AUTOSAR applications. However, for safety features which are not specified as hard-real time, AA applications can achieve up to ASIL-B (these days also ASIL-D) using the safety libraries provided by different vendors. As Classic AUTOSAR application does not need an OS to run, its bootup time is also quite less compared to AA applications.

Technical criticisms on AUTOSAR

Every design decision has a trade-off associated with it. AUTOSAR standards have used an approach of “one solution fits all”, making it form a heavy footprint software stack. This causes application sizes to bloat up. In very resource-constrained embedded environments, this application may not be the right choice and more targeted applications could do a better job. There are many criticisms on AUTOSAR and a lot of development entities are looking for alternative approaches.

Further Words

For full disclosure, I have been learning about AA from detailed training courses from Vector in the last few days, where we delved into the implementation details of Vector’s AUTOSAR products.

I hope you now have a high-level understanding of AUTOSAR, what AA is, its motivation for existence, and how AA applications are used in automotive.

Coming from a product design background and writing software in embedded products, curiosity drives me to go beyond software design and development layers. Just like any hardware-based product, software products are an amalgamation of different software principles. This natural curve opened an opportunity for me to take on architectural tasks within the scope of my development activities. Offlate I have been getting involved at the system level components and piecing out the different information points into the system architecture. To take this further into streamlined learning, it is impossible not to stumble upon the famous book - Fundamentals of Software Architecture by Mark Richards and Neal Ford.

In the following part of this article, I have tried to give you a brief introduction to the book and give you my personal learnings from it. This article is purely for academic purposes and is part of my contribution to the software community world. If this interests you, I would highly recommend reading the book further.

Structure of the book

This book is written in three independent sections to cover the holistic view of software architecture.
Part I: Covers the foundation of the software architecture, defining it and breaking it down into its core blocks. It also covers means of identifying, measuring, and governing architectural characteristics.
Part II: Here it covers different architectural designs and assessment of the characteristics of it in star rating format.
Part III: Then it talks techniques and the soft skills to be an effective architect. Author talks about recording architectural decisions - on useful methods and tools to do it.

Following are the key highlights I have noted and written in my words.

What software architecture is about?

Defining the architecture

On the same lines of Martin Fowler’s definition in his famous article “Who needs an architect” quoted “Software Architecture is about the important stuff, whatever that is”, the authors re-enforces this and has made an excellent attempt to explains us to why that is true. In the age of the programming world, software architecture has a constantly evolving role and hence its definition. In the most general terms, it can be equivalent to understanding the system which is divided into its components and connected with interfaces. As the authors quoted

It is the highest level concept of the expert developers and their shared understanding The focus of software architecture should be more on the WHY than the HOW part.

Software architecture’s 4 sides

The designing process of an effective piece of software can be further split into following steps:

• Structure - The base technology stack which forms the structural part of your software
• Characteristics - The technological properties which want your software to bring across
• Decisions - The decision tree which led to final software product
• Design principles - The principles which were closely followed while development

The authors have provided easy to understand pictorial depictions for the above point which is helpfully embossing.

Architectural thinking - broadening the breadth

A developer’s mindset is to dig deeper into few chosen / relevant topics, while an architect needs to have an overview on a range of different technologies. Surely an architect needs to know a few topics well in depth but the part where they start making the difference is having an overview of the technologies used in the product.

Defining architectural characteristics

There are two types of architecture characteristics - explicit and implicit. Explicit characteristics are the ones which directly surface based on the solution provided and are non-domain specific design considerations. On the other hand implicit characteristics are the ones which are influenced from the structural aspects of the designs and are generally related to the domain specific knowledge. Let us take an example of designing a website for an online ticket booking system - here the characteristics such as reliability, availability, performance, scalability, etc. are explicitly covered while aspects such extensibility, upgradability, privacy, security etc. could be classified as implicit. I agree it is not 100% clear on how to label the characteristics, but the important point is to think from the perspective of the difference in domains and non-domain related characteristics.

Identifying architectural characteristics in a given use case

One of the initial steps while architecting is to identify the characteristics. They can be extracted from the domain knowledge and the requirement documents. There is no specific set of rules to follow while identifying them, but one can practice through architectural Kata exercises. Please refer below what architectural Katas are.

Measuring and Governing these characteristics

Authors show us the importance of measuring the measurable characteristics as a means of justifying your decisions. Authors introduced techniques to measure characteristics of modularity via cohesion, coupling and connascence properties. This would help quantify the characteristics which sets a good platform for comparing decisions. For effective decision-making it is important to analyse the detailed output and form fitness functions. From these reports an architect gets the opportunity to govern the decision-making process.

Component based thinking - Conways Law

Conways Law suggests that the organisation’s communication structure heavily influences the design structure of the product it is developing. The flow of information in an organisation is affected by how the teams are structured which then affects the decision-making process. Based on the decision the ownership of the different building blocks aka components are influenced and hence the overall design structure gets altered. As Martin Fowler mentioned there are three ways to deal with this law:

1. Ignore - it is proven to be ineffective to fight against it
2. Accept - make sure your architecture incorporates the designers communications pattern
3. Inverse Conway Maneuver - make changes in the communication patterns to achieve design architecture

The identification of the software components of a product can be done either based on technical or domain related. It is important to understand both divisions inorder to make knowledgeable trade off decision.

Brief introductions into the architectural patterns

The author covered detailed definitions, descriptions and purpose of the various architectural designs. The designs covered are the following -

• Big ball of mud
• Monolithic architecture
• Component based design
• Service oriented architecture
• Service defined architecture
• Microservices
• Space based architecture

I will not go further into the design patterns in this article as it will not do the justice to all of them in a short article. But if you are interested to know further I encourage reading up further in the book and other online resources. The interesting part in this book is about the comparison which was made on all the designs. The following mentioned architectural characteristics are used as the comparison - Deployability, Elasticity, Evolutionary, Fault tolerance, Modularity, Cost, Performance, Reliability, Scalability, Simplicity and Testability.

Techniques for practicing architecture

Practicing with Architectural Katas

To become a good architect one needs to practice making architects designs. In the beginning of my journey into this I struggled to find platforms to exercise architecture and the decision-making process. This book introduces the concept of architectural katas, a concept originally formed by Ted Neward. It is an exercise where a bunch of enthusiasts come together to design a different system and a moderator who not only assigns the tasks but also keeps track of the time. I plan to organise such events in the near future, so if you are interested do drop a message below.

Architectural Decisions Records

Logging architectural decisions enables people from an organisation to take further design decisions abiding to the agreed ones. It allows to have a place where one can fall back for referring to the previous decisions taken and get away from email driven architectural decisions. To create a high level understanding, it is mandatory to refer to the older superseded decisions while creating new decisions. Having a standard template for such decisions helps to create standardised records. There are various open source tools as such adr-tools to help align the ADRs process and become coherent with the software development process. Records could also include various types of pictorial diagrams, class diagram, state machines diagram, flow diagram etc, created with UMLs to convey the idea effectively.

Developing your unique Architectural path

Becoming an effective architect is a time consuming process and requires detailed path planning. In the final concluding chapter the authors gave us useful tips on laying down the path to become an architect. Everybody’s path to become an architect is a unique one and hence there are no specific rules for it. Author suggested creating a personalised radar for the technologies we are interested in and to pay close attention to the developments in it. They have given a example of such radars which they create within their organisation called Technology Radar.

Hope this article gave you a good insight into the field of software architecture and what this book has to offer. Do drop me a connect on linkedin to get to know further updates from me such topics.

Have a happy learning!

Recently I got an opportunity to read C++ Software Design by Dr Klaus Iglberger. I find the concepts presented in the book if not to cover basics but quite intriguing to further the thought process. As a software developer, I do regularly of think of design patterns and use them aiming to make the codebase more modular, scalable, reusable, less coupled. Albeit I found a holistic view of the design patterns from this book and would recommend it to a seasoned software developer. In this post, I am aiming to give a summary of the book but it is not a promotional blog by any means. You can treat it as a nonexhaustive abstract of what the book covers but if you are intrigued more please dive into the book.

The book is about 400 pages and is divided into 39 digestible guidelines. In my opinion, the best part about this book is the footnotes and further reading material the author provides us. If you have attended/heard Dr Klaus’s talks you can imagine his voice while reading the book. The author writes a lot about readers’ reactive comments while introducing the concepts, which might annoy few but also helps in covering all-around discussions on it. After going through some pages you can even anticipate when these takes are coming ;-)

Alright, let’s dive in. Following are the sections giving the summary of the book.

[1/3] Basic Software Development principles and what they mean from architectural pov

In this first part of the book, the author introduces both what software design is and why it is important in any software project. If we go to the first principle it is nothing but the “Art of managing dependencies and abstraction”. The author represents software development in three levels of

1. Software architecture
2. Software design
3. Implementation details

and explains the differences in the architecture and design of the software. The author gives us a helpful perspective to look at any software designs, ie from high level (fairly stable) and low level (prone to change).

The author emphasizes how change is constant and design for extension and we developers should persistently keep this in the back of our minds. The author covers the most famous software principles like SOLID, DRY, ISP (and many more) but more importantly there are discusssions on how to interpret these principles while creating the low-level designs of the software. Most of his takes boils down to a single aspect while creating the designs to think about the “separation of concerns”. Separation of concerns sits at the base for most of the design patterns, if I were to zoom into it further, separations of concerns can be thought of from these two lenses -

1. Decreasing coupling (be it artificial coupling)
2. Increasing cohesion

The section Design for testability resurfaces the problems we often face while unit testing badly designed classes. The mitigation approach is to have white-boxed tested classes, which could be enough but is not the best approach for testing. Again the solution to this appeared to be in thinking of separating concerns at the early development stage.

In the next section, the author takes us into the Art of building abstraction to effectively place the requirements and expectations into the code. In OOP-based languages, abstractions are usually built using base classes and also can be built using concepts (or equivalent). Many times these introduce more problems where we can use abstractions using free functions. This aspect is touched on in many ways later to show how we can achieve decoupling and separate concerns. Nevertheless, in all these forms of abstraction building it is important to adhere to LSP to forward the expectations correctly and DIP to think in terms of ownership of the introduced abstractions. Next the author talks about what purpose the design patterns serve - to provide a blueprint for the organizational software to be built upon. Naming design patterns with commonly known patterns helps to pass on intent and information to developers. The author again emphasizes that design patterns are not only limited to OOP or dynamic polymorphism, they can be very well extended to functional or generic programming.

The open-for-extension guideline in OCP can be interpreted in two ways: open for extending types or open for extending operations. Procedural programming gives us ease of adding new code for extending the operations but gets tougher to add new polymorphic types. On the other hand with OOP, we get the ease of adding new polymorphic types but it is tougher or impossible for adding new operations without recompiling the base classes. In the early stage of the project, one must make a conscious decision about which path of extension he/she wants to follow. It is important to understand that no design fits all-purpose and has its advantages and disadvantages.

[2/3] Strategy pattern, Observer and CRTP

Slowly the the design topics starts getting a bit complex.

From the second tierce of the book, we start to get into various design patterns of both structural and behavioral patterns. First, we cover the visitor pattern and embrace it to solve our problems with the extension of operation in the inheritance hierarchy using double dispatch. Although naturally with this approach it gets tougher to add new types. We also learn that since we have double indirections used this design becomes quite inefficient by design. Next author introduces the std::variant style of visitor pattern, with which creating abstraction becomes quite easy. With std::variant we can group any unrelated types and based on the the type present at the call we can perform operations accordingly with the help of std::visit(). The new operations logic can be added on top without going back and changing any of these classes. While looking at the benchmarked result, it is worth mentioning that there are further nuances of these of writing your own get_if() functions to call particular operations based on the type provided. Refer the book to see various interesting benchmarks reported by the author.

Then we move to cover the strategy pattern and command pattern. The strategy pattern intends to extend the polymorphic types of a class without much fuss. Strategy class can be thought of as serving complimentary aspect of open for extension as of visitor and also can be thought of as extracting the complex algorithms into separate entities being it a class or free function. Strategy entity can be injected as a dependency into the subject class. One of the downside in this pattern (also to be able to follow SRP) is that for each operation we need to add one strategy. One can use a Policy-based strategy design pattern by passing a policy in the form of a function object or lambda. We investigate the command design pattern next, which looks very similar and has the same implementation as that of the strategy design pattern. The only difference comes from the architectural point of view. For that matter even from the type of structural pattern, the adaptor design patterns strike as similar to strategy but the intent it serves is different. It becomes easy to think about the design when you think from the perspective of what intent they serve. We also cover differences in reference semantics (used often by OOP-based) and value-based designs. In this case, our policy-based designs emphasize the point of value-based semantics.

Next, we go through the Adaptor pattern, the Observer pattern, and the CRTP pattern. Adaptor patterns are used to standardize the interfaces or to introduce a shim layer between the client and implementation details. Adaptors can be formed through creating an intermediate class or even by functions. Observer pattern is used where we require a notification system for a state change of the data, we are interested in. It creates a one-to-many relation between the subject (data we are interested in) and the observers. It is good to be aware of the further niche of this design: push observer and pull observer. It is also important to highlight that the observer pattern can be attained via value semantics as well. The CRTP pattern creates a compile-time abstraction for a family of related types. This is attained by using templates of the derived type, where we static cast this pointer to the derived class and access the methods we want to call. Note here since we use a template for the base class, we do not have the same base class for all derived types. C++20 concepts help us to implement this pattern.

[3/3] Bridge, prototype and type erasure pattern

The final third part of the book contains few of the most complex design patterns. If I were to go back referring to this book it would be mostly for this part of the book. The bridge pattern (belongs to the structural pattern domain ) can be used to isolate different concerns and bridge them. We can remove direct physical dependency between modules so that either end can evolve without affecting others (like retriggering recompilation etc.). The Pimpl Idiom is a more famous part of the bridge pattern. We can achieve ABI stability with this pattern. If we introduce more abstraction layers (and more indirections) it may appear that the efficiency could take a toll, which is true in most of the cases, but refer to the book to see where it can be even better than the unaltered design.

The prototype pattern is used to self-clone concrete types from its base class object pointer. It is equivalent to having a virtual copy constructor. External polymorphism is a non-intrusive method to lets the user use the non-related (no-inheritance) classes to be treated polymorphically. There are new terms like concepts class (base) and model classes (derived from concept class) used. The important thing to know is that for different types of classes, there are different base classes (which could be templatized). This pattern takes advantage of it being non-polymorphic (fewer indirections), can be easily extendable according to OCP, and follows DRY and DIP. However, this pattern does not follow value semantics.

The intent of the type erasure design pattern is to provide value-based non-intrusive abstraction for unrelated types but with the same semantic behavior. The type erasure design pattern contains a combination of external polymorphism, bridge pattern, and potentially prototype design pattern. It got its name because of the fact that the abstract class does not store the information about the concrete type of the object hence the type is erased. The author also adds optimization techniques like using SBO instead of dynamic memory to allocate and deallocate memory or manual dispatch instead of virtual table indirections.

Decorator pattern allows dynamically attaching new functionality to the existing types without changing the types. In other words, it is a flexible alternative to subclassing for extending functionality. The author tells the reference from the GoF book about how the analogy of strategy being the gut of the object and decorator being the skin. The author also gave a quick tour of the Singleton pattern. Singleton pattern is infamous for the issues with SIOF, hindrance to testability, etc. The author shows us how strategy patterns could be used to invert dependency of the singleton pattern easily for testability.

I hope you enjoyed reading this summarisation and find it helpful. If you decide to read the book do enjoy it! If you have already read the book, let me know if you have something more to add.

Abbreviations

• OOP: Object Oriented Programming
• DRY: Do Not Repeat yourself
• SOLID: 5 most famous software programming principle next in line -
• SRP: Sinogle Responsibility Principle
• OCP : Open Close Principle
• LSP: Liskov’s Substitution Principle
• ISP: Interface Segregation Principle
• DIP: Dependency Inversion Principle
• CRTP: Curiously Recurring Template Pattern
• SBO: Small buffer optimization
• SIOF: Static initialization order fiasco
• GoF: Gang of four book - Design Patterns: Elements of Reusable Object-oriented software