How do you design a robust and scalable embedded software architecture?

First, I will consider below requirements: 1. Functional requirements Example: How a system work? 2. Non-functional requirements Example: performance, security, reliability, and scalability requirements 3. Constraints: Consider hardware limitations, power consumption, and real-time requirements It is highly recommended to clearly ducumenting our requirements in digital/physical format Your co-workers should have dia-grams and flow charts for batter tracking of systems

One thing I feel is helpful is that it is important to also understand and document the system limitations. Be it hardware limitations or overall system design / sys arch limitation. The clarity of the boundary/limitations can be really helpful in defining your SW design and also it's scope. It can help in visualising and selecting the simplest, efficient and feasible design option.

First, define system requirements, including functional requirements, non-functional needs like performance and hardware limitations and power consumption. Employ a layered architecture with a Hardware Abstraction Layer (HAL) to isolate hardware-specific code. One can also utilise a Real-Time Operating System (RTOS) for efficient task management and inter-task communication through message queues, semaphores, and other IPC mechanisms, watchdog timers can be used for system recovery and conduct extensive testing including unit, integration, and system tests. Optimise performance by writing efficient, low-latency code tailored to the hardware, using profiling tools and manage CPU, memory, and I/O resources efficiently.

In my experience I would recommend to follow these principles Define system requirements including functional and non-functional requirement and divide the software into independent modules with well-defined interfaces to minimize dependencies and enable easier maintenance and updates. Implement a layered structure with clear separation of concerns such as drivers, middleware, and application layers to improve reusability and maintainability. Use HAL to isolate hardware-specific details from the higher-level software components, allowing for easier adaptability across different hardware platforms.

Prioritize real-time requirements by implementing deterministic behaviors and optimizing for critical tasks to ensure timely response and performance. Design the architecture to accommodate future expansions and enhancements by adopting flexible and extensible design patterns such as plug-ins or modules that can be added or removed without affecting the core system. Implement efficient power management strategies to optimize energy consumption and prolong battery life, especially in resource-constrained embedded systems. Integrate security measures such as data encryption, authentication, and secure communication protocols to protect the embedded system from vulnerabilities and cyber threats.

I think design patterns are all over any well written piece of software. Real life firmware will never implement just one design pattern. At this stage it is probably more suitable to make the most basic decisions about your firmware. E.g. RTOS based vs. bare metal etc. These should follow quite straight-forwardly form the requirements collected in step 1. In our example of RTOS vs bare-metal, this would likely be the requirement for real-time capability.

In the early 2000s I was working on a wireless dial-up data modem. So, we needed UART functionality to connect to RS232C interface. The DSP in our design didn't have built-in UART, it only had Synchronous Serial port (SPORT). My boss asked me to work on a low level software UART driver implementation on the DSP using the SPORT peripheral. I argued with him that a UART/USART IC would barely cost $1 to the BOM but he didn't relent and I implemented the software UART driver. Within next 3-4 years, the modem sold over 500K units & it effectively saved over 500K USD in foreign exchange. This was my first lesson on hardware-software partition. So, make your design choices & think about BOM cost vs dev cost "carefully".

Applying hardware-software interface best practices is essential for creating reliable and efficient embedded systems. Abstraction layers and HALs not only simplify development but also enhance portability across different hardware platforms. Using interrupts for asynchronous events and synchronization mechanisms like semaphores and mutexes ensures smooth and safe communication between software components and hardware, minimizing the risk of data corruption and deadlock.

It's very easy to forget this key component of embedded software development lifecycle. In the hurry to create MVP and take it to the market, too many times code is written in non-modular style which makes it difficult for the next generation of products (of same type) to be able to reuse them. Think of Linux system calls and build similar APIs for your embedded software architecture whenever possible. APIs should be designed like wrapper functions that can be mapped to specific SOC/MCU functionalities (like Linux device drivers) and it may link to different end implementations for different SOCs. In other words, create your software architecture mimicking RTOS/OS structure to avoid re-writing code for each change in hardware elements.

Start by really understanding the requirements, including any timing, performance needs, and the hardware you'll be working with, knowing your hardware inside out is key to avoid suprises. Then, define a clear architecture that breaks the software into manageable pieces with well-defined roles. Invest in good testing and CI/CD from the beginning to catch problems early and ensure the system can grow smoothly. And don’t forget to consider timing right from the start, especially for real-time performance, so you avoid rework down the road.

Make use of EVERY kind of static code checking tool you can get your hands on. Crank up the warnings of your compiler to the max, make all warnings errors. Get a good static code analyzer, better yet, get a couple. If you are writing C++ this will be clang-tidy, cppcheck and maybe SonarLint. Listen to their advice. This might seem cumbersome, but in reality every bug that you don't have to hunt down with runtime debugging will save you a lot of time.

Tools like Git have been indispensable in my workflow. They help track changes and manage different versions of the software. Having a solid version control strategy has saved me multiple times when bugs pop up in a previous release or I need to compare versions. Personal experience is that I felt as a kind of backup in case of emergency or catastrophic damage to our development system

1. Code Documentation: Maintain clear and up-to-date documentation for all modules. 2. Breiaf comments on code can help new developers understand code better.

It is necessary to clearly define both functional and non-functional requirements in addition to hardware constraints in order to design a reliable and scalable embedded software architecture. The architecture should be modular, and guarantee that each module has a distinct task and few interdependencies. To simplify portability and separate hardware-specific information, use abstraction layers. If necessary, put in place a scheduler or real-time operating system (RTOS) to manage tasks, and make sure that modules communicate effectively with one another—ideally using standardized interfaces. To improve scalability and simplicity of maintenance, place a strong emphasis on code reuse, testing, and documentation.

Don't lose the sight of the testing phase. For the alpha/MVP iteration, implement code that will allow to test modules of the product instead of just testing it as a black box. By this I don't refer to JTAG/ICE based testing but using diagnostics that are built into the code and can be accessed via the standard interfaces like Ethernet, Bluetooth, serial port etc. In my first organization, the stress on built-in diagnostics was significant and there was a whole stack of diagnostics functionalities built into every sub-system that allowed host to sub-system as well as inter sub-system communication. It was quite helpful to debug and fix issues that would be otherwise require a hardware debugger.