Embedded Controller Architecture
The construction of a typical component under the control of a service subsystem looks as follows:
flowchart LR
A[Some Service<br><i>Service initiates query</i>]
B[Subsystem Controller<br><i>Orchestrates component behavior</i>]
C[Component Trait Interface<br><i>Defines the functional contract</i>]
D[HAL Implementation<br><i>Implements trait using hardware-specific logic</i>]
E[EC / Hardware Access<br><i>Performs actual I/O operations</i>]
A --> B
B --> C
C --> D
D --> E
subgraph Service Layer
A
end
subgraph Subsystem Layer
B
end
subgraph Component Layer
C
D
end
subgraph Hardware Layer
E
end
When in operation, it conducts its operations in response to message events
sequenceDiagram
participant Service as Some Service
participant Controller as Subsystem Controller
participant Component as Component (Trait)
participant HAL as HAL (Hardware or Mock)
Service->>Controller: query_state()
Note right of Controller: Subsystem logic directs call via trait
Controller->>Component: get_state()
Note right of Component: Trait implementation calls into HAL
Component->>HAL: read_some_level()
HAL-->>Component: Ok(0)
Component-->>Controller: Ok(State { value: 0 })
Controller-->>Service: Ok(State)
alt HAL returns error
HAL-->>Component: Err(ReadError)
Component-->>Controller: Err(SomeError)
Controller-->>Service: Err(SomeUnavailable)
end
A core pattern of the ODP architecture is one of Dependency Injection. The service and subsystem Traits define the functional contract of the component, while the HAL implementation provides the hardware-specific logic. This allows for a clear separation of concerns and enables the component to be easily tested and reused across different platforms. Components are eligible to be registered for their subservice if they match the required traits.
flowchart TD
subgraph Component
A[Needs Logger and Config]
end
subgraph Framework
B[Provides ConsoleLogger]
C[Provides NameConfig]
D[Injects Dependencies]
end
B --> D
C --> D
D --> A