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.

C / Model-Based CAN FD / Ethernet SIL / HIL / Vehicle

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.

Vehicle inputs

Pedal / Gear
Driver intent
BMS
SOC · power limit
EVCC / OBC
Charging state
Domain ECUs
Status · faults

DECISION CORE

VCU Application Layer

Vehicle-level decision and coordination

01State machine
02Torque arbitration
03Energy management
04Fault fallback
CAN FD Ethernet UDS / XCP

Control and coordination

MCU
Torque request
BMS
Power / protection
EVCC
Charge interlock
BCM / TBOX
Body / cloud

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

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

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

Integrate CAN, CAN FD, LIN, Ethernet, DBC, ARXML, and cross-ECU signal matrices into testable application-layer behavior.

04

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.

01

Power On

Wake / self-test

02

Ready

Interlocks passed

03

Drive

Torque control

04

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.

01

Requirements and Vehicle Architecture Review

Review vehicle type, ECU topology, signals, I/O, safety interlocks, charging flow, and service requirements.

02

Application Architecture and State Machine Design

Define ASW modules, vehicle state machines, protection logic, signal mapping, and parameter management.

03

Implementation, Integration, and Diagnostics

Implement C or model-based logic, then integrate CAN FD, Ethernet, UDS, XCP, and controller platform behavior.

04

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.

BMSMCUEVCCOBCDCDCBCMTBOXADAS ECUThermal SystemCAN FDEthernetUDS

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)

C and model-based module source, version tags, git history, and build scripts.

Communication Design Files

CAN, CAN FD, and Ethernet DBC / ARXML, SWC/RTE designs, and signal matrices.

State Machine and Design Documents

Specifications for driving, charging, protection, limp-home, and diagnostic state machines.

Calibration Parameter Sets

a2l, dcm, and baseline parameters loadable by INCA, CANape, and KopherConfig.

Diagnostic Database

UDS service tables, DTC lists, and ODX files for production and aftermarket diagnostic tools.

Test and Validation Reports

SIL, HIL, bench, and vehicle test cases with results and coverage analysis.

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

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

Security risk assessment, secure communication design, vulnerability response, and UN R155 / R156 alignment guidance.

AUTOSAR Classic Architecture

Modular BSW, RTE, and SWC design with ARXML-driven engineering flow and production integration.

ASPICE Aligned Process

Bidirectional traceability across requirements, design, implementation, and testing aligned with ASPICE Level 2 / 3.

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.