A public repository for designing, verifying, and reviewing a driving-alert system in CANoe SIL.
Hyundai Mobis Bootcamp · Vector Korea
Final Deliverables · Overview · Highlights · System Overview · Quick Start · Repository Map
Project background
This project was developed as part of the Hyundai Mobis Bootcamp in collaboration with Vector Korea. It is structured as a public engineering repository that connects communication design, CANoe runtime assets, traceable workproducts, and verification tooling in one place.
Major references
- Vector CANoe documentation and sample configurations
- Automotive SPICE PAM 3.1
- ISO 26262
- AUTOSAR Classic Platform SWC Modeling Guide
- project-result review samples used to shape workproduct structure and reviewer-facing format
The repository closeout surface is fixed to the six submission assets below.
|
1. Final Report Open PDF review-ready |
2. Presentation Open PDF review-ready |
3. Short Paper Open PDF review-ready |
|
4. ECU Book Open PDF review-ready |
5. Project Result Excel Open XLSX 2-2 submission workbook |
6. Appendix Open PDF review-ready |
For source mapping and replacement policy, see final-deliverables/README.md.
Most CAN communication repositories expose only one layer of the work: runtime assets, code, or test outputs.
This repository is built to show the full engineering path:
- communication design
- CANoe runtime implementation
- V-cycle workproducts
- verification execution and review tooling
- CAN + Ethernet communication modeling in CANoe SIL
- end-to-end traceability from requirement to verification
- operator-facing product surface for review workflows
- shared automation for gates, quality checks, and release support
The overview below uses the project-authored closeout figure rather than a generic placeholder diagram.
python scripts/run.py
python scripts/run.py gate all
python scripts/run.py scenario run --id 4
python scripts/run.py verify quick --run-id 20260308_0900 --owner DEV2| Path | Purpose |
|---|---|
canoe/ |
CANoe runtime project, configuration, CAPL source, contracts, and verification docs |
driving-alert-workproducts/ |
canonical workproducts and traceable engineering documents |
product/ |
operator-facing product surface and review assets |
scripts/ |
shared launchers, gates, quality tooling, and release helpers |
See CONTRIBUTING.md for contribution guidance.
If you want to understand why the architecture, ECU split, runtime ownership, and verification path are structured the way they are, start here: