CANtap Studio tutorials: Projects 🎬

Where do your tests live, and what travels with them? In CANtap Studio a project is one folder: the test suites plus everything they need to run. That means the CAN databases, diagnostic catalogs (DIDs and DTCs), ECU variable files, the seed-to-key providers for UDS security access, and the project's own Python modules. One file, project.json, describes the rig under test: which buses exist and at what bitrate, which ECUs sit on them, and how to reach each one. What is deliberately NOT in a project is your computer. Which CANtap boards are plugged in, which board serves which channel, who you are, and the record of every run all stay on the bench. That split is what lets two people use the same project on two different HIL rigs. The project says "channel 1 is the ECU's bus at 500 kbit/s"; your bench says "on my desk, channel 1 is this board, port 1". In this 8-minute video: ▸ First start: a short checklist that says what each setting adds, and what you already have without it ▸ New Project: a complete project with no server, no address, no password ▸ Filling it: the ECU's database in CANtap Studio's own XML, then plugins for files from other tools. Install the DBC and A2L plugins, load the rig's DBC database, and bind the ECU's A2L variables so tests can read and write its memory by name ▸ The buses and the first test suites ▸ Opening a colleague's project: their buses come with it, and you bind your own boards once, on your bench only ▸ Close, Recent Projects, Repair: the whole life of a project from the File menu ▸ Why run results stay on the bench and never inside the tests: a result is evidence, not part of the testware Plugins, like boards, belong to your computer, not to the project. Version control is optional and gets its own chapter. Everything in this video works without it. Next chapter: Connecting the hardware.