Layered Software Architecture

Layered Software Architecture is a software architectural pattern that divides a

software system into a set of hierarchical layers, where each layer provides services
to the layer above it and uses services from the layer below it.

Layered architecture is one of the most common software architectural patterns.

This architecture is aimed at separating different concerns or functional components
of a software system into distinct layers. Each layer provides specific functionality
and services to the layers above and below it and communicates only with the
adjacent layers. So, it creates a clear separation between the business logic and
technical implementation, making it easier to manage the complexity of the system.

The primary principle for layering is to divide layers for different calling purposes
based on concerns and organized them based on the level of abstraction. The
cognitive rule of “machine at the bottom, the user at the top” underlies the layered
architecture pattern. As such, the higher the level in the layered architecture, the
more business-oriented and user-oriented the abstraction level becomes. On the
other hand, the lower the level, the more general and device-oriented the
abstraction level becomes.
The four standard layers are described as follows.

1. Presentation Layer
This layer contains all user interfaces exposed to a user. It may provide different types of user
interfaces, namely web, desktop and native mobile applications.

2. Business Logic Layer

This layer handles all business logic, validations and business processes.

3. Data Access Layer

This layer is responsible for interacting with a database. It is also known as the persistence
layer.

4. Data Store Layer

This layer is the actual data store for the application.

By introducing different layers for the software components, separation of concerns (SoC) is
increased drastically, thus improving simplicity, maintainability and test-ability of the
components.
The tiers are described as follows.

Tier 1: The Presentation Tier

This tier hosts the front-end code base, that is, the presentation
layer. This is the topmost level of the application and it is essentially
a layer users can access directly.

Tier 2: The Application Tier

This tier hosts the back-end code base, that is, the business logic
layer and data access layer. It is also known as the middle tier.

Tier 3: The Data Tier

This tier hosts the data store, that is, the data store layer.
Databases, file system, blob storage, document database, etc are
examples of resources found in a data store.
Presentation layer: This layer consists all the classes responsible for
presenting the user interface to the end user or sending the response
back to the client.
Application layer: This layer consists all the logic that an application
requires to meet its functional requirements while not being a part of the
domain rules. In most systems, the application layer also contains services
orchestrating the domain objects to fulfill a particular use case scenario.
Domain layer: This layer represents the underlying domain that mostly
contains domain entities and in some specific cases, services. Business
rules such as algorithms and invariants should all be a part of the domain
layer.
Infrastructure layer: Also known as a persistence layer, the infrastructure
layer includes all the classes responsible for performing the technical
actions such as persisting data in the database, like repositories, DAOs
(data access objects), etc.
 Advantages of Layered Software Architecture
1. Modularity: A layered architecture promotes modularity, as each layer is designed to perform a
specific set of functions. This makes it easier to modify or replace one layer without affecting
other layers.

2. Separation of concerns: Layers in a software architecture are typically designed to handle specific
concerns, such as presentation, business logic, and data access. This separation of concerns
makes the software easier to understand, test, and maintain.

3. Encapsulation: Each layer in a software architecture encapsulates its implementation details from
the other layers, providing a clean interface for communication between layers. This reduces the
risk of bugs and improves the overall stability of the system.

4. Scalability: A layered software architecture can be scaled horizontally or vertically by adding more
instances of a layer or by adding more layers to the architecture.

5. Reusability: Layers can be reused across different projects or applications, providing a consistent
design pattern that can be easily adapted to new requirements.

6. Flexibility: A layered software architecture allows for greater flexibility in the choice of
technologies used at each layer, making it easier to adopt new technologies or replace outdated
ones.
 Things to avoid in C Langauge for reliablity and
robutness
1. Buffer overflows: This occurs when a program writes data beyond the boundaries of an allocated buffer. It can result in
memory corruption and other serious security vulnerabilities.

2. Uninitialized variables: Using uninitialized variables can result in undefined behavior, causing the program to behave
unpredictably and potentially introducing bugs.

3. Memory leaks: This happens when a program fails to release dynamically allocated memory after it is no longer needed.
Over time, memory leaks can lead to performance degradation and system crashes.

4. Null pointer dereferences: This occurs when a program attempts to dereference a null pointer, causing a segmentation fault
or other unexpected behavior.

5. Integer overflows: This occurs when an integer value exceeds its maximum value, resulting in undefined behavior and
potentially introducing security vulnerabilities.

6. Lack of error checking: Failing to check for errors in system calls and library functions can result in unexpected behavior or
system crashes.

7. Poor error handling: Failing to handle errors gracefully can result in confusing error messages or unexpected program
termination.

8. Lack of comments: Failing to include comments in the code can make it difficult for others to understand the program's
behavior, leading to bugs and maintenance issues.

9. Poor naming conventions: Using unclear or inconsistent naming conventions can make the code difficult to understand and
maintain.
 Guidelines for writing Device drivers for MCUs
1. Reading the datasheet, reference manuals, release notes, etc.: Before you start writing a driver, it's
essential to read the datasheet and other documentation for the microcontroller and the peripheral
device. This will help understand how to configure and operate the device correctly.
2. Following coding standards: It's important to follow established coding standards and conventions to
ensure that the driver is consistent and easy to maintain. This includes naming conventions,
indentation, commenting, and error handling.
3. Minimizing memory usage: Embedded systems typically have limited memory, so it's crucial to
minimize the memory used by the driver code. This can be achieved by using efficient data structures
and algorithms.
4. Using interrupt-driven programming: Interrupt-driven programming is a common technique used in
embedded systems development to handle events quickly and efficiently. When writing a driver, we
should consider using interrupt-driven programming to handle device events such as data transfers
and errors.
5. Optimizing code execution time: In embedded systems, code execution time is critical, and inefficient
code can cause delays and system failures. Therefore, it's essential to optimize the code execution
time by using efficient algorithms and minimizing unnecessary operations.
6. Testing thoroughly: After writing the driver, it's essential to test it thoroughly to ensure that it works
correctly in all conditions. This includes testing for boundary conditions, error conditions, and stress
testing.
7. Documenting the driver: Proper documentation is essential for maintaining and debugging the driver
code. It should include information about the driver's purpose, how it works, and how to use it.
 Data Inconsistency
Data inconsistency in Microcontroller programming refers to a situation where the data stored in
memory is different from what is expected or required by the program. This can occur due to a variety
of reasons, including hardware issues, software bugs, and incorrect programming practices. Data
inconsistency can lead to a range of problems, including incorrect program behavior, crashes, and other
system malfunctions. For example, if a variable that stores a critical system parameter is inconsistent
with the expected value, it could cause the system to behave unpredictably or fail altogether.
Some common causes of data inconsistency in Microcontroller programming include:

1. Race conditions: A race condition can occur when multiple tasks or threads try to access the same
data simultaneously, leading to inconsistent results.
2. Interrupts: Interrupts can interrupt the normal flow of program execution, causing unexpected
data changes or inconsistencies.
3. Timing issues: Timing issues, such as delays or timeouts, can cause data inconsistencies if they are
not accounted for in the program's design.
4. Incorrect memory usage: Improper use of memory, such as writing to unallocated memory or
exceeding the bounds of an allocated buffer, can cause data inconsistencies.

To avoid data inconsistency in MCU programming, it's important to follow established programming
practices, including proper memory allocation, synchronization techniques, and error checking.
Additionally, thorough testing and debugging can help identify and resolve data inconsistency issues
before they cause problems in the system.
 Race Condition
A race condition in MCU programming occurs when two or more tasks or threads access a shared
resource or variable simultaneously, resulting in unpredictable behavior or incorrect results. This can
happen when multiple tasks or interrupts try to modify a shared variable at the same time, leading to
inconsistencies and data corruption.

For example, consider a program where two tasks are trying to increment a shared variable at the same
time. If both tasks try to access the variable at the same time, they may end up overwriting each other's
changes, leading to unpredictable behavior and incorrect results.

Race conditions can be difficult to detect and diagnose, as they may occur only under specific
conditions, such as when the system is under heavy load or during high-frequency interrupts. Moreover,
race conditions are often timing-dependent, making them difficult to reproduce and debug.

To avoid race conditions in MCU programming, developers must ensure that critical sections of code that
modify shared variables or resources are protected by appropriate synchronization mechanisms, such as
semaphores or mutexes. Additionally, it's essential to ensure that interrupts are properly handled, and
that interrupt service routines (ISRs) are kept short and do not modify shared resources directly.

Overall, preventing race conditions is critical to ensuring the correctness and reliability of MCU
programs, and it requires careful attention to detail and best practices in software design and
implementation.