An Embedded Software Architecture

本文作者：[wangwenhai] # 概要：’An Embedded Application Layer Software Architecture Design’

Title: An Embedded Application Layer Software Architecture Design

Keywords: Embedded Software, IoT, Data Processing

Abstract

This paper introduces a novel embedded software architecture designed to abstract hardware and system interactions within the application layer. By using a “Resource” abstraction to represent hardware components and a “Device” abstraction to represent logical devices, the architecture facilitates easier application development by decoupling the business logic from low-level hardware details. The architecture’s flexibility makes it suitable for various IoT applications, such as edge gateways, smart metering systems, and HMI control interfaces. This paper outlines the detailed design, architecture, and key innovations behind this approach.

1. Introduction

In embedded systems, the traditional software architecture is often divided into three primary layers: hardware, system, and application. The hardware layer represents the physical devices, the system layer deals with resource management and task scheduling, and the application layer focuses on business logic and user interaction. However, embedded software development can become cumbersome due to the tight coupling between the application layer and hardware-specific implementations.

To address this issue, this paper proposes an architecture where the application layer is abstracted from hardware-specific details. The key abstraction used in this design is the “Resource,” which logically represents hardware components, and the “Device,” which abstracts the logical devices used in the application. This abstraction not only enhances modularity but also allows for easier scalability and portability across different hardware platforms.

2. Detailed Design

2.1 Architecture Overview

The proposed architecture consists of three primary layers:

Hardware Layer: This layer contains physical devices such as sensors, actuators, and communication interfaces (e.g., UART, I2C, SPI).
System Layer: This layer manages task scheduling, resource allocation, and communication with hardware components. It contains the operating system kernel and device drivers.
Application Layer: This layer contains the business logic and interacts with logical devices via the Resource abstraction.

In this architecture, the application layer does not interact directly with physical hardware. Instead, it communicates with logical devices through an intermediate layer (Resource) that abstracts hardware-specific details.

2.2 Resource Layer

The Resource layer represents hardware components as logical entities. A Resource encapsulates the physical interaction with hardware (e.g., a serial port or I2C bus), providing a standardized interface to the application layer. The Resource layer abstracts the low-level details, such as communication protocols, allowing the application to focus on high-level functionality.

For example, a SerialPortResource abstracts the communication with a physical UART port, while a SPIResource abstracts the interaction with an SPI bus.

Resource Class Example:

class Resource {
public:
    virtual void init() = 0;            // Initialize resource
    virtual void readData() = 0;        // Read data from resource
    virtual void writeData() = 0;       // Write data to resource
};

2.3 Device Layer

The Device layer represents logical devices that interact with hardware through resources. A Device uses resources (such as SerialPortResource or SPIResource) to interact with the underlying hardware but is independent of the hardware implementation. The application layer interacts with these devices, focusing solely on the business logic, such as data collection and control operations.

Device Class Example:

class TemperatureSensorDevice {
public:
    TemperatureSensorDevice(Resource* resource) : resource_(resource) {}

    float getTemperature() {
        resource_->readData();
        return temperatureData;  // Assuming the data has been processed
    }

private:
    Resource* resource_;
    float temperatureData;
};

2.4 Data Point Table

A Data Point Table organizes data points for each device. These data points may represent measurements (e.g., temperature, humidity) or attributes (e.g., configuration settings). The table distinguishes between measurement and attribute points using a clear type system.

This abstraction allows the application layer to retrieve and interpret data from devices in a structured manner.

Data Point Class Example:

class DataPoint {
public:
    enum Type { MEASUREMENT, ATTRIBUTE };

    DataPoint(std::string name, Type type) : name_(name), type_(type) {}

    std::string getName() const { return name_; }
    Type getType() const { return type_; }

private:
    std::string name_;
    Type type_;
};

2.5 Application Layer

The Application Layer interacts with devices and their data points. It contains the core business logic, such as reading sensor data, aggregating information, and issuing control commands. By abstracting the hardware interaction, the application layer remains hardware-independent and can easily adapt to new hardware configurations.

Application Logic Example:

class EdgeGatewayApp {
public:
    void collectData(TemperatureSensorDevice& tempDevice) {
        float temperature = tempDevice.getTemperature();
        // Process and send data to the cloud
    }
};

3. UML Architecture Diagrams

3.1 Component Diagram

This diagram illustrates the primary components of the architecture and their relationships:

+---------------------+     +------------------+     +------------------+
|    Application      | <-- |    Resource      | <-- |    Hardware      |
| (Business Logic)    |     | (Abstraction)    |     |  (Physical HW)   |
+---------------------+     +------------------+     +------------------+
        |                          |                         |
        V                          V                         V
+-------------------+        +-------------------+    +-------------------+
| TemperatureSensor |        | SerialPortResource|    | UART Driver       |
|   Device          |        |                   |    |                   |
+-------------------+        +-------------------+    +-------------------+

Application Layer: Contains business logic interacting with logical devices (e.g., TemperatureSensorDevice).
Resource Layer: Abstracts hardware communication (e.g., SerialPortResource).
Hardware Layer: Represents the physical hardware, such as UART, SPI, or I2C.

3.2 Class Diagram

This diagram represents the relationships between key classes in the system:

+---------------------+   1     +-------------------+    1     +-------------------+
|  TemperatureSensor  | ------> |    Resource       | ------> |  SerialPort       |
|    Device           |         |   (Abstract Class)|         |  Resource         |
+---------------------+         +-------------------+         +-------------------+
        |                          /   |  ^                        |
        V                        +-----+  +-----------------------+
+--------------------+
| DataPointTable     |
+--------------------+

TemperatureSensorDevice: Represents a logical device interacting with hardware resources.
Resource: An abstract class representing hardware resources.
DataPointTable: Contains all data points related to a device (e.g., temperature, configuration).

3.3 Sequence Diagram

This diagram illustrates how the application retrieves data from a device:

+---------------------+        +------------------+         +------------------+
|   Application       |        |    Resource      |         |     Hardware     |
+---------------------+        +------------------+         +------------------+
         |                           |                           |
         |  getTemperature()          |                           |
         |-------------------------->|                           |
         |                           |  resource.readData()      |
         |                           |-------------------------->|
         |                           |                           |
         |                           |  return temperatureData   |
         |                           |<--------------------------|
         |  return temperature       |                           |
         |<--------------------------|                           |

4. Innovations

Resource Abstraction: By introducing the Resource abstraction, the application layer is freed from direct interaction with hardware details, enhancing modularity and portability across different hardware platforms.
Device Abstraction: The Device layer abstracts logical devices, making it easier for the application to interact with devices without being concerned with the underlying hardware.
Data Point Table: The Data Point Table categorizes measurement and attribute points in a structured manner, simplifying data processing and enhancing scalability.
Separation of Concerns: This design maintains a clear separation between hardware, system, and application layers, making the system more modular and easier to maintain, test, and extend.
Scalability and Flexibility: The architecture allows for easy addition of new devices or resources without requiring significant changes to the application logic, promoting scalability and flexibility.

5. Conclusion

This paper presents a software architecture for embedded systems that abstracts hardware interaction, facilitating easier application development and enhancing system scalability. By introducing the Resource and Device layers, this architecture decouples the application layer from low-level hardware details, improving code reuse and simplifying maintenance. This approach is particularly well-suited for IoT applications, such as edge gateways and smart metering systems, and can be adapted to a wide range of embedded use cases.