Multi-Master Operation
IGNIS supports a multi-master configuration of two controllers — a high-availability architecture for systems where two motors act as starter-generators on the same engine shaft and the power supply must survive a controller failure (for example aircraft applications).
Every controller is an equal master:
- Each controller runs its own complete starting sequence and generation control.
- Each controller listens to the same external CAN control message directly.
- Each controller broadcasts its peer status on the CAN bus and monitors the other controller (the peer) through these broadcasts.
The design goal is high availability: there is no single point of failure in the control — if one controller fails, the other one continues generating on its own and signals the reduced system state.
The pairing parameters are located in the /can directory. The CAN message layouts are described in CAN Messages.
Normal operation
In normal operation the pair behaves as one generator:
- The controller with the lower address leads: it times the starting sequence and commands both motors in lockstep, so the two motors on the common shaft are always in phase — one can never pull back while the other pushes forward.
- The other controller follows: it keeps its own logic running in parallel (contactor, statistics, monitoring), mirrors the sequence phase, and stands ready to take over. Its own motor commands are superseded by the leader's — this is the normal condition, not an override.
- The leader also transmits the system status — the host always reads one message from one ID, no matter which controller currently leads.
High availability — failure behavior
| Event | Behavior |
|---|---|
| Leader powered off / CAN disconnected | The follower's motor coasts within 0.2 s, its own control takes over seamlessly from the last known phase, and it leads itself within 1 s — the system keeps generating on one motor |
| One controller reports a fault | The healthy controller keeps running alone; a faulted controller cannot disturb the healthy one — its stale commands are ignored |
| Faulted controller recovers | Automatic: the pair re-synchronizes and leadership returns to the lower address |
| CAN control message lost | Default: the start flag clears and the engine stops (/can/can_ctrl_stop = 1); optionally the system keeps running with the last command (= 0). Signalized in the flags either way |
| Any single-controller operation | Signalized as Reduced in the status word of both status messages — the flag covers everything that keeps the system from sinking the full torque, including a derated controller |
During a failover the system status can pause for up to ~1 s before the surviving controller takes the reporting over — see the staleness note there.
Both controllers of a pair must run the same firmware version — the pair synchronizes through versioned CAN messages.
Configuration
Node addressing
Each controller has a system address (MY_ADDR, the platform addr setting). The two controllers must have different addresses, and each one must be told the address of its peer using multi_addr. The controller with the lower address leads in normal operation.
Example for a two-controller system:
| Controller | MY_ADDR | multi_addr |
|---|---|---|
| Generator 1 | 3 | 4 |
| Generator 2 | 4 | 3 |
multi_addr
Multi-master peer address. -1 = standalone controller (peer monitoring disabled), 0–6 = the address of the peer controller to monitor.
can_ctrl_tim [ms]
Timeout of the CAN control message. Reloaded by every received command; 0 disables the timeout.
can_ctrl_stop
Behavior when the CAN control message times out. 1 — clear the start flag (the engine stops when CAN is a start source). 0 — continue with the last received command (high availability); the timeout is only signalized.
States (/can)
| State | Unit | Description |
|---|---|---|
can_flags | - | Last received control flags (bit 0 = start request) |
can_cmd | - | Last received charging limitation, 0–1 |
can_tmo | ms | Remaining control message timeout, 0 = timed out |
peer_tmo | ms | Remaining peer presence timeout, 0 = peer lost |
peer_error | - | Driver error reported by the peer, 0 = OK |
peer_ib | A | Battery current reported by the peer, negative = charging |
peer_stat | - | Driver protection flags reported by the peer |
peer_limit | - | Total driver limit reported by the peer, 1 = no derating |