VCU Application Development
Vehicle Control Unit (VCU)
Application Development
Production-oriented VCU application-layer software, vehicle-control logic, network integration, diagnostics, calibration, and validation for electric buses, trucks, agricultural vehicles, and specialty EV platforms.
CONTROL ORCHESTRATION MAP
What does the VCU do in the vehicle?
The VCU does not replace domain ECUs. It makes vehicle-level mode, power, and fault decisions so every subsystem follows one coherent state and safety model.
DECISION CORE
VCU Application Layer
Vehicle-level decision and coordination
Control and coordination
CAPABILITY MAP
Service Scope
We treat the Vehicle Control Unit as the vehicle-level control center, connecting requirements, signals, state machines, diagnostics, calibration, and validation into maintainable engineering deliverables.
01 Vehicle State and Control Logic
Vehicle State and Control Logic
Design Ready, Drive, Reverse, Charge, Fault, Service, and Limp-home state machines while coordinating driver input, torque requests, interlocks, and fallback strategies.
02 Energy Management and Charging Integration
Energy Management and Charging Integration
Integrate BMS, MCU, EVCC, OBC, DCDC, and thermal systems for charging interlocks, battery protection, power limiting, and fleet operation logic.
03 Vehicle Network and Signal Integration
Vehicle Network and Signal Integration
Integrate CAN, CAN FD, LIN, Ethernet, DBC, ARXML, and cross-ECU signal matrices into testable application-layer behavior.
04 Diagnostics, Calibration, and Production Support
Diagnostics, Calibration, and Production Support
Support UDS, DTC, XCP, parameter calibration, EOL testing, version management, and field issue analysis so VCU software can move from prototype to production.
STATE MACHINE AT A GLANCE
Understand the vehicle state flow at a glance
Normal operation follows the main path. A critical fault from any state can enter Fault / Limp-home, keeping protection behavior out of scattered module logic.
Power On
Wake / self-test
Ready
Interlocks passed
Drive
Torque control
Charge
Charge coordination
Fault
ANY STATE → Fallback / limp-home
FROM REQUIREMENTS TO VEHICLE
Engineering Workflow
Four milestones connect requirements, architecture, implementation, and validation in a reviewable, traceable production flow.
Requirements and Vehicle Architecture Review
Review vehicle type, ECU topology, signals, I/O, safety interlocks, charging flow, and service requirements.
Application Architecture and State Machine Design
Define ASW modules, vehicle state machines, protection logic, signal mapping, and parameter management.
Implementation, Integration, and Diagnostics
Implement C or model-based logic, then integrate CAN FD, Ethernet, UDS, XCP, and controller platform behavior.
SIL / HIL / Vehicle Validation
Validate state machines, fault behavior, charging sequences, and fleet operation logic through SIL, HIL, bench, and vehicle testing.
VEHICLE NETWORK
Common Integration Targets
Integration targets are selected for each vehicle program; not every platform needs every system listed here.
ENGINEERING PACKAGE
Project Deliverables
At project completion you receive a full, production-ready, long-term maintainable engineering package — source code, design documents, and validation reports all delivered with the vehicle program.
Application Source Code (ASW)
Application Source Code (ASW)
C and model-based module source, version tags, git history, and build scripts.
Communication Design Files
Communication Design Files
CAN, CAN FD, and Ethernet DBC / ARXML, SWC/RTE designs, and signal matrices.
State Machine and Design Documents
State Machine and Design Documents
Specifications for driving, charging, protection, limp-home, and diagnostic state machines.
Calibration Parameter Sets
Calibration Parameter Sets
a2l, dcm, and baseline parameters loadable by INCA, CANape, and KopherConfig.
Diagnostic Database
Diagnostic Database
UDS service tables, DTC lists, and ODX files for production and aftermarket diagnostic tools.
Test and Validation Reports
Test and Validation Reports
SIL, HIL, bench, and vehicle test cases with results and coverage analysis.
Production Support Documents
Production Support Documents
EOL scripts, version logs, field issue response procedures, and OTA update workflow.
SAFETY BY DESIGN
Functional Safety Engineering and Standards Support
A VCU is a safety-related control unit in a commercial EV. We provide ISO 26262-oriented engineering and document-traceability support under the project contract and safety plan; this service does not certify the controller or customer system to ISO 26262.
ISO 26262 Functional Safety
ISO 26262 Functional Safety
We support ASIL analysis based on the project's Item Definition, HARA, and Safety Goals, then provide Safety Concept and safety-mechanism design.
ISO 21434 Automotive Cybersecurity
ISO 21434 Automotive Cybersecurity
Security risk assessment, secure communication design, vulnerability response, and UN R155 / R156 alignment guidance.
AUTOSAR Classic Architecture
AUTOSAR Classic Architecture
Modular BSW, RTE, and SWC design with ARXML-driven engineering flow and production integration.
ASPICE Aligned Process
ASPICE Aligned Process
Bidirectional traceability across requirements, design, implementation, and testing aligned with ASPICE Level 2 / 3.
Safety and Quality Documentation
Safety and Quality Documentation
HARA, Safety Concept, Safety Case, traceability matrix, change management, and review records.
Frequently Asked Questions
How are VCU, BMS, and MCU responsibilities divided?
The VCU is the vehicle-level control center, handling state machines, torque distribution, mode transitions, and protection strategies. The BMS manages battery protection and SOC / SOH estimation, while the MCU controls the motor. The VCU sends commands and monitors health via CAN / CAN FD.
Does your VCU application development support ISO 26262 functional safety?
Yes. Based on the customer's Item Definition, HARA, and Safety Goals, we support ASIL analysis and plan the Safety Concept, safety mechanisms, test coverage, and bidirectional traceability under the project safety plan. Actual work products follow the contract scope; engineering support is not product certification.
How long does a typical VCU application development project take?
A standard cycle from requirements review to SIL / HIL validation runs 6–12 months, depending on vehicle complexity, diagnostic coverage, and production requirements. Vehicle validation and calibration typically add 2–4 months.
Do you provide source code and design documents?
Yes. All application-layer source code, ARXML, state machine documents, calibration data, and diagnostic service lists are delivered with the project, with version tags for long-term maintenance.
Can development run on existing ECUs, or must we adopt the KCU platform?
Both are supported. We have experience with mainstream automotive MCUs including Infineon AURIX, NXP S32, and Renesas RH850. Choosing the KCU platform shortens hardware selection, BSP integration, and production validation.
Can the VCU integrate OTA, telematics, or remote diagnostics?
Yes. Combined with TBOX, an OTA Client, version management, and UDS diagnostics, the VCU supports OTA updates, remote DTC retrieval, and fleet operation data upload.