System Description¶
Purpose¶
This document describes the MOTSEN Tool from a system point of view. It defines the system boundary, the external entities the system interacts with, the internal subsystems, and the operating modes. It is derived from the project definition (see Project Definition) and forms the basis from which the system requirements in System Requirements are written.
The document is intentionally descriptive, not prescriptive. Statements here describe what the system is; testable “shall” statements belong in System Requirements.
Items that are not yet decided are kept as explicit placeholders and link to the corresponding open decisions in Project Plan.
System Overview¶
The MOTSEN Tool is a bench instrument for commissioning, characterizing, and diagnosing permanent-magnet synchronous and brushless DC motors (PMSM / IPMSM / BLDC). It combines the functions traditionally provided by a separate inverter, oscilloscope, LCR meter, power analyzer, and vendor tuning software into a single connected device driven from a host PC. The tool consists of:
The initial target motor class is PMSM/BLDC at low voltage (12–24 V) and below 100 W. Other motor types and higher power ranges are explicit non-goals for the current phases. |
System Context¶
The MOTSEN Tool operates as a bench instrument. Its external context consists of:
The tool does not connect to any cloud service, network infrastructure, or shared database. All interaction with the user is mediated by the host PC. |
Inside the system boundary:
Outside the system boundary:
|
Subsystem Decomposition¶
The MOTSEN Tool is decomposed into the following subsystems. Each subsystem is described individually in the sections below.
|
| digraph motsen_blocks { rankdir=LR; node [shape=box, style="rounded,filled", fillcolor="#F4F6F7"]; subgraph cluster_tool { label="MOTSEN Tool"; style=dashed; Ctrl [label="Embedded\nController\n(MCU + FW)"]; Power [label="Power Stage\n(3-phase inverter)"]; Sense [label="Current &\nVoltage Sensing"]; Pos [label="Position Sensor\nInterface"]; Safe [label="Safety &\nProtection"]; Link [label="Host Comms\nLink"]; } subgraph cluster_host { label="Host PC"; style=dashed; Server [label="Local Web\nServer"]; UI [label="Browser UI"]; } DC [label="DC Supply", shape=ellipse, fillcolor="#FFF2CC"]; Motor [label="Motor Under\nTest (+ sensors)", shape=ellipse, fillcolor="#FFF2CC"]; User [label="User", shape=ellipse, fillcolor="#FFF2CC"]; DC -> Power; Power -> Motor [label="3-phase"]; Motor -> Pos [label="Hall / Enc / Resolver"]; Power -> Sense [label="I, V"]; Sense -> Ctrl; Pos -> Ctrl; Ctrl -> Power [label="PWM"]; Ctrl -> Safe; Safe -> Power [label="latch trip"]; Ctrl -> Link; Link -> Server; Server -> UI; UI -> User; User -> UI; } |
Subsystem Descriptions¶
Power Stage¶
A three-phase inverter that drives the motor under test from the DC bus. In Phase 1 the power stage is provided by an off-the-shelf evaluation board; the specific board is an open decision (see DEC_001). It is replaced by a custom PCB in Phase 3 (MIL_070). Key properties:
Open items:
|
Current and Voltage Sensing¶
Measurement chain that converts power-stage analog signals into digital samples used by the controller.
The sensing chain is the dominant source of measurement uncertainty for the characterization features and must be characterized before any parameter estimation result is reported. |
Position Sensor Interface¶
Reads the motor position sensors and provides position, direction, and (later) speed to the controller. Phase scope:
The interface is also the input to sensor-health checks (phase sequence, Hall alignment, encoder direction). |
Embedded Controller¶
The MCU and its firmware. The MVP target MCU is the NXP S32K322. The controller hosts:
Portability is a stated goal: a second MCU platform must be supportable by Phase 2 exit (MIL_048). The strategy for the HAL — wrapping the NXP RTD/SDK versus a thin register- level layer — is an open decision (DEC_005). The HAL is intentionally designed to the minimum needed for Phase 1 (see RISK_002). |
Safety and Protection¶
The MOTSEN Tool operates on real motors under power; protection is layered and applies independently of the control loop.
|
Host Communication Link¶
The link between firmware and the host PC. It carries parameter read/write commands, a streaming log/telemetry channel, and command/response traffic for measurement procedures. Phase scope:
|
Host Application¶
The host-side software runs locally on the user’s PC. It is a single-user, local-only tool — no authentication, no remote hosting, no cloud (RISK_004). Components:
|
Measurement and Characterization Engine¶
The set of procedures that perform sensor checks and motor parameter estimation. Most of the procedure runs on the firmware (real-time signal injection and acquisition); the host receives results and may post-process and present them. Two functional domains, as defined in the project definition:
Algorithm complexity is a known risk (RISK_005). The procedures are staged: Rs first, then Ld/Lq, then Kt. Each result is validated against a reference motor before being considered usable. |
Operating Modes¶
The MOTSEN Tool operates in a small number of distinct modes. The modes are exposed at the system level — the user sees them in the UI, and the firmware enforces transitions.
The detailed transition diagram is deferred to the system requirements document, which will refine these into testable behavior. |
Phase Scope Summary¶
Not every subsystem is present in every phase. The table below summarizes the scope of each subsystem per phase, mirroring the milestones in Project Plan.
|
Open Items and Placeholders¶
The descriptions above include items that depend on decisions that have not yet been made. Each placeholder below is intentionally kept here, in the system description, so that the gap is visible to anyone reading top-down from the project definition. They close through the corresponding decisions in Project Plan.
Final voltage range, continuous and peak current, switching frequency, gate-driver topology, and current-sense topology are pending DEC_001. The 12–24 V / <100 W envelope from the project definition is the working assumption. |
UART vs USB-CDC and the on-wire frame format are pending DEC_003. The description currently assumes a single point-to-point bi-directional link with framed packets and a streaming telemetry channel. |
Backend language and framework for the local server (Python/FastAPI, Node.js, Go, …) is pending DEC_002. The description assumes a local-only server that serves static assets and a real-time channel. |
Whether the HAL wraps NXP RTD/SDK or is a thin register-level layer is pending DEC_005. The choice affects portability cost when the second MCU is added in Phase 2. |
Whether CAN is pulled into Phase 1 or kept strictly Phase 2 is pending DEC_004. Default working assumption: Phase 2. |
Whether observer-based sensorless control is in scope, and for which phase, is pending DEC_006. Not described as a present subsystem until the decision closes. |
License and public-release policy is pending DEC_007. Affects host-app packaging and firmware distribution; does not affect technical architecture. |
Traceability¶
This document derives from the project definition (PRJ_001) and feeds the system
requirements (System Requirements). Each desc node above is intended to be
referenced by one or more sysreq nodes when the requirements document is populated.
Forward links to milestones and decisions in the project plan are kept on the description
nodes themselves so that:
A placeholder makes its open decision visible at the description level.
Each subsystem can be traced forward into the milestones that build it and the hardware/software requirements that detail it.