What Is DEP
DEP (DEVlink Engineering Platform) is one desktop application for model-based and software-based testing. You build a System from components such as plant models, controller models, compiled ECU software and virtual buses. You run it in simulated time, check its outputs automatically, and keep the results as evidence. All of this is stored in a single project file.
Who DEP is for
- Control and systems engineers who want to connect plant and controller models, run closed-loop tests and compare a model with its compiled software.
- Integration and test engineers who receive FMUs, SSP packages or customer ECU software (vECUs) and need to run them against a reference plant with saved test cases.
- Network engineers who need a virtual CAN, CAN FD, LIN or ARINC bus generated from a DBC or similar database.
- Charging engineers who simulate a DC charging session with editable battery, charger and interlock models, and optionally with the separately licensed ChargeLink protocol stack.
- Operators who only open saved projects, run scenarios and watch operator screens. The DEP Operator edition covers this.
Key concepts
Project
A project is one file with the extension .rbsproj. It contains the System, your models, HMI pages, scenarios, saved runs and evidence. DEP saves a recovery copy next to it automatically. See Projects, Files and Recovery.
System
The System is the test setup inside a project: a set of components joined by connections. You edit it on the Model Flow canvas in System Engineering. A project has one System. Other workspaces, such as Scenarios and Operator HMI, always use the saved System.
Component and port
A component is one block on the canvas: a model, an ECU, a vECU, a sensor, a network and so on. Each component has input ports (left) and output ports (right). You connect an output to an input. An input that is not connected keeps the value you type in Component Properties.
Implementation
A component describes what something is. Its implementation is how it runs: a native DEP model, an FMU, a physical model, a state machine or compiled software. One component can have a MIL implementation and a separate SIL implementation, and DEP selects the one that matches the active profile.
Profile: MIL, SIL and HIL
- MIL Model in the loop. Every component runs as a model. This is the default for new Systems.
- SIL Software in the loop. Selected components run compiled software in separate processes, against the same plant. You use it to show that the software behaves like the model.
- HIL Hardware in the loop. HIL runs on an NI VeriStand bench, which owns real-time execution and all I/O. From DEP you can discover a VeriStand Gateway, deploy a reviewed system and observe its channels. DEP itself does not connect to or drive hardware.
Some projects name their profiles, for example Charging MIL - fmi2-cs. The name tells you which implementation set is active.
Logical time and ticks
DEP runs in logical time. Each tick advances the simulation by a fixed step, for example 10 ms. A run executes a batch of ticks (1–1000) as fast as your PC allows, then pauses. Logical time is therefore not wall-clock time. A 15-second logical scenario may take more or less than 15 seconds to compute. The results are deterministic: the same inputs give the same outputs.
Execution session and execution owner
When you press Run, DEP creates an execution session. It stays open (paused) between batches so that Continue and Step carry on from the same state. Only one part of DEP may own execution at a time: the System run, a restbus acquisition, a scenario campaign or a HIL deployment. If another owner is active, DEP refuses the new request and tells you where to stop it. See Running MIL and SIL.
Check
Check validates the saved System for the active profile before anything runs. It confirms that every component has an executable implementation, that connections are valid and that units and rates fit. Run performs the check again automatically. A passed check means "ready to run locally". It does not certify hardware or physical outputs.
Signals and mappings
DEP gives every value that crosses a component boundary a canonical signal. Signal mappings tie those signals to bus frames (CAN, LIN, ARINC, EtherCAT and others), so the same System can talk over a virtual bus without changing the models.
Scenario and campaign
A scenario is a saved test case. It sets inputs, runs a number of ticks and checks outputs against expected values with a tolerance. A campaign is a saved selection of scenarios. Each case runs on an isolated copy of the saved project, so tests never change your work. See Scenarios, Campaigns and Evidence.
Evidence
DEP records what actually ran: the project revision, implementation hashes, samples, frames and verdicts. You can export evidence as JSON, JUnit XML or reports. DEP never shows a success it did not observe. Empty results are shown as empty, and stale values are marked as stale.
Workspaces at a glance
| Sidebar | Sub-items | What you do there |
|---|---|---|
| Overview | Current project, Projects | Open or create projects, see readiness and recent sessions. |
| System | System Engineering, Signal mappings, Requirements to model, Model Designer, Physical Model Designer, State Logic, Networks & restbus, HMI Designer | Build and edit everything that makes up the System. |
| Scenarios | Scenarios & validation | Write, run and compare test cases. |
| Runs | Execution & HIL, HIL runtime, Operator HMI, Measurement & calibration, Results & recordings | Execute, operate, observe and analyse. |
| Library | Library Center, Software integration, Software / FMI / SSP, SSP import & composition | Reusable definitions, imported FMUs, SSP packages and customer software. |
What DEP does not do
To avoid surprises, read Capability Boundaries before planning a project. In short, DEP:
- does not connect to or drive hardware (buses, analog or power I/O) and runs in logical time, not real time;
- does not certify models, software or protocols, so a passed scenario is engineering evidence, not a certificate;
- runs on Windows x64 only.