Control/Command Domain Model
It contains “High Policy classes” that are part of the “abstract domain model”, and default implementations:
- StateMachine : The state machine used by the controller.
- EventsHandler : The controller events handler.
- Equipments : All the configured equipments.
- FunctionalControllers : All the configured functional controllers.
- CommandController : Class that manage the commands in collaboration with Mnemonic class.
- IpcControllers : Class that manage the IPC connections, protocol, and their associated features.
- RemoteControllers : Class that manage the remote connections, protocol, and their associated features.
- MonitoringController : Class in charge of managing the mnemonics monitoring.
- RulesController : Class in charge to manage triggering of actions depending on rules.
These rules are described by parsable mathematical formulas using mnemonics. - Mnemonics : All the configured INPUTS/OUTPUTS mapped to a Mnemonic.
- Plugins : All the libraries loaded at runtime, before loading the controller main configuration.
Noun/Verb Analysis
The Controller is the software part that manages hardware and peripherals.
It’s responsible for:
- Driving actuators dependending of the feedback of sensors (Setting **INPUT/OUTPUT values**)
- Managing external Services that provide access to “CPU peripherals” such as network and sound interfaces.
- Manage the main StateMachine.
- Manage the Controller configuration and the plugins.
- The actuators’s driving and sensor’s reading in done through a **Board** with which we communicate ( read/write ) using a AbstractDriver.
A AbstractBoard is an AbstractEquipment that contains Channels (TOR/ANA), that reflects the inputs/outputs accessible via the board.
An AbstractEquipment is a ControllerComponent that is composed by a Driver. An Equipment is connectable using its Driver.
A Driver is a ControllerComponent that wrap the communication aspect and is responsible to connect to something (Any communication wrapping: TCP/UDP, Serial, USB Device….whatever…).
A ControllerComponent is somehow the base object of the domain, that can be enabled/disabled:
- An AbstractEquipment is a ControllerComponent, so it can be enabled/disabled.
- The CommandController cannot be enabled/disabled, so it’s not a ControllerComponent (it’s just an Entity).
Some functionnality can involve several components, or several inputs/outputs from a “Board” (e.g: The “Heating Feature” needs to know about pressure). These components/inputs/outputs are gathered together in a AbstractFunctionalController.
Some functionnalities must be accessible through an IPC communication (e.g: Between HMI and Controller), this access is managed by an IpcController.
Some functionnalities must be accessible through a Remote communication (e.g: Remote CLI), this access is managed by a RemoteController.
The abstraction layer that transparently give access to functionnalities is provided by the concept of Mnemonic. These mnemonics are not supposed to be used everywhere in the software:
- The execution of mnemonics is managed by the CommandController.
- The monitoring of mnemonics is manage by the MonitoringController.
- The rules using formulas composed by mnemonics is manage by the RulesController.
- Can be accessed by **Remote/IPC/Script Controllers** (using mnemonics sub-list and/or accessibility mask).
- The mnemonic configuration can be send to **IPC/Remote Clients** to check consistency at both side, or to configure the client.
- This is not a glue ! No mnemonics at all anywhere else !