MCU/VCU Integration¶
Source note: notes/MCU-VCU-Control-Specs.md
This page captures the Phase-1 OEM to MCU integration requirements for connected electric motorcycles using PMDC motor systems.
Executive Summary¶
The Phase-1 target is a practical integration boundary between the OEM Vehicle Control Unit (VCU) and the Motor Control Unit (MCU). The OEM VCU retains supervisory control over rider experience, vehicle behavior, fleet management, diagnostics, OTA orchestration, parameter governance, and connected vehicle services. The MCU remains responsible for motor commutation, current control, hardware protection, and real-time motor-control loops.
The scope is not a deep MCU redesign. The goal is a scalable control boundary with:
- standardized CAN command and telemetry surfaces
- transparent vehicle behavior tuning
- configurable ride profiles
- non-volatile parameter governance
- firmware and parameter OTA support
- fleet and IoT observability
- identity and anti-tamper support
System Architecture¶
Rider / Dashboard / Rider-App -> VCU (OEM Supervisory Control) -> CAN -> MCU (Motor Control Supplier) -> PMDC Motor
Responsibility Split¶
MCU-owned functions
- motor commutation
- current control
- hardware protection
- real-time motor-control loops
VCU-owned functions
- vehicle behavior management
- ride modes
- speed, torque, and current governance
- fleet policies
- OTA orchestration
- IoT and cloud integration
Input-Output Control Matrix¶
| Input Source | Input Parameter | MCU / Vehicle Function Affected | Observable Vehicle Behavior |
|---|---|---|---|
| Rider throttle | Throttle position | Torque request | Acceleration response |
| Rider brake | Brake input | Regen torque | Braking feel / energy recovery |
| Dashboard | Ride mode | Torque, speed, and current maps | Eco, Normal, Sport behavior |
| Rider-App | Speed limit request | Speed limit | Maximum vehicle speed |
| Fleet platform | Fleet profile | Torque, current, and speed caps | Commercial fleet behavior |
| VCU | Torque limit | Torque control | Launch feel / hill climb |
| VCU | Current limit | Battery draw limitation | Efficiency / battery protection |
| VCU | Regen enable | Regen activation | Regenerative braking |
| VCU | Regen torque request | Regen control | Braking intensity |
| VCU | Direction command | F/N/R state | Vehicle direction |
| VCU | Drive enable | Traction enable | Vehicle operational state |
| BMS/VCU | Thermal or power limit | Derating | Reduced performance protection |
| Cloud/IoT | Immobilization command | Drive disable | Anti-theft / PAYG |
| MCU internal | Protection logic | Safety limitation | Limp mode / shutdown |
| MCU temperature sensors | Thermal state | Torque or power derate | Thermal protection behavior |
Minimum Command And Telemetry Surface¶
VCU To MCU Commands¶
Minimum Phase-1 CAN commands:
- drive enable
- direction command
- torque request
- torque limit
- speed limit
- current limit
- regen enable
- regen torque request
- ride profile ID
MCU To VCU Telemetry¶
Minimum telemetry feedback:
- MCU state
- actual torque
- motor RPM
- vehicle speed
- battery current
- DC bus voltage
- controller temperature
- motor temperature
- fault code
- warning code
- regen status
- energy consumption
Vehicle Behavior Control Requirements¶
The MCU shall support configurable and documented control of:
- maximum speed
- acceleration response
- maximum torque
- regenerative braking
- efficiency and range optimization
- thermal derating
- reverse mode behavior
- limp mode behavior
The note defines the main control levers as:
- speed limits
- RPM limits
- torque maps
- current limits
- ramp-rate control
- regen maps
- thermal protection thresholds
The OEM requires visibility into the chain from rider input to VCU command to observable vehicle behavior so that ride feel, speed behavior, torque delivery, regen behavior, thermal derating behavior, and fleet operation modes can be calibrated deliberately.
Ride Profiles¶
The MCU shall support multiple configurable ride profiles:
- Eco
- Normal
- Sport
- Fleet
- Limp
The VCU shall be able to switch ride profiles dynamically over CAN bus. Each profile may contain different speed limits, torque maps, acceleration ramp rates, regen behavior, and current limits.
| Profile | Intent |
|---|---|
| Eco | Prioritize efficiency and range |
| Normal | Balanced operation |
| Sport | Maximum performance |
| Fleet | Controlled commercial operation |
| Limp | Reduced safe operation under fault or protection conditions |
Parameter Management¶
The MCU shall support non-volatile parameter storage that persists across power cycles.
Minimum parameter groups:
- OEM parameters
- fleet parameters
- user preferences
- service parameters
Required behaviors:
- checksum and versioning support
- authorized write access
- recovery from interrupted updates
- parameter updates without full MCU firmware replacement
Typical parameter-only updates include:
- speed limit adjustments
- torque map tuning
- fleet ride mode changes
- regen tuning
- efficiency optimization
MCU Identity And Anti-Tamper Requirements¶
Minimum identity and governance requirements:
- unique MCU identifier
- firmware version reporting
- calibration version reporting
- protected parameter access
- locked critical safety limits
Critical operational parameters that must resist unauthorized modification include:
- speed limits
- torque limits
- protection thresholds
- safety behavior
- calibration maps
Preferred future support:
- signed firmware
- secure identity and authentication
- cryptographic anti-tamper protection
OTA Update Support¶
Phase-1 OTA architecture:
Cloud -> IoT/VCU -> CAN -> MCU
Minimum Phase-1 OTA requirements:
- CAN bootloader support
- firmware version reporting
- parameter update capability
- interrupted update recovery
- rollback capability
Preferred future support:
- signed firmware validation
- dual-bank firmware
- differential OTA updates
Diagnostics And Telemetry¶
Required diagnostic functions:
- read fault codes
- clear fault codes
- access live telemetry
- read and write parameters
- support firmware update flows
Preferred communication standards:
- UDS over CAN
- ISO-TP
- or a fully documented CAN protocol
The MCU supplier shall provide documented fault and warning codes for:
- dashboard integration
- rider-app diagnostics
- fleet monitoring systems
- service tools
Fleet Management Observables¶
The MCU/VCU system shall expose telemetry useful for fleet and connected vehicle services, including:
- overspeed events
- harsh acceleration events
- energy consumption
- range or kWh metrics
- thermal events
- fault history
- derating events
- immobilization state
These observables support fleet optimization, rider behavior analysis, preventive maintenance, battery protection, and PAYG operation.
Supplier Deliverables¶
The note requires the MCU supplier to provide:
- CAN protocol documentation
- DBC files
- fault-code lists
- parameter lists
- firmware update procedures
- bootloader documentation
- thermal and protection limit documentation
- calibration procedures
- diagnostic tool documentation
Future Upgrade Path¶
Future generations may extend the Phase-1 boundary with:
- secure signed firmware
- advanced OTA frameworks
- cloud-native diagnostics
- predictive maintenance
- dynamic fleet policy enforcement
- OEM-owned calibration toolchains
- advanced fleet analytics
- secure MCU identity architecture