STEP 01 / 06
Build the system context
Bring together representative battery, power-system and controller models. Define the signals and assumptions that matter to the application.
Products / DEVlink Engineering PlatformModel the system.
DEVLINK ENGINEERING PLATFORM · DEP
Model the system.
Run the software.
Verify what matters.
Connect models, virtual ECUs and test scenarios in one MIL and SIL engineering platform. Built around e-mobility across automotive, aerospace and industry.
Discuss a DEP evaluation ↗Explore the workflow ↓THE ENGINEERING STORY / 48 SECONDS
From model behaviour to software confidence.
Explore a battery-limit scenario through MIL and SIL, with a clear view of the model, controller and engineering evidence.
DEP / MIL → SIL · 01
Compose the system.
BATTERY · POWER SYSTEM · CONTROLLER
DEP / MIL → SIL · 02
Define the limit.
Available battery power
A lower limit. A clear test question.
DEP / MIL → SIL · 03
Watch the model respond.
Plant modelsBattery + power system
Feedback loop
Controller modelControl response
DEP / MIL → SIL · 04
Introduce real software.
Controller model→Controller software / vECU
DEP / MIL → SIL · 05
Run the same question in SIL.
Expected responseObserved signal
Illustrative signals · time →
DEP / MIL → SIL · 06
Compare the evidence.
MIL referenceSIL response
Illustrative signals · time →
00:00 / 00:48
STEP 02 / 06
Set a battery-limit scenario
Specify a change in available battery power and the expected controller response. The same engineering question guides the following MIL and SIL stages.
STEP 03 / 06
Explore the model response
Run the model-based controller with the plant models. Review whether the requested power follows the available battery limit.
STEP 04 / 06
Bring controller software into the loop
Introduce the controller as a virtual ECU, with interfaces appropriate to the selected integration. Keep the scenario intent consistent.
STEP 05 / 06
Observe the software response
Run the controller software against the modelled system. Investigate the response to the battery-limit scenario and inspect relevant signals.
STEP 06 / 06
Compare behaviour. Investigate differences.
Review MIL and SIL evidence against the expected response. Investigate differences before extending the scenario set. Integration details are scoped during evaluation.
1 / 6
Illustrative engineering workflow, not a live DEP simulation or product screenshot. Models, virtual ECU interfaces and result handling are scoped for each evaluation. E-mobility applications span automotive, aerospace and industry.
Discuss your MIL and SIL workflow ↗ONE ENGINEERING PLATFORM
MIL · Model-in-the-Loop
+SIL · Software-in-the-Loop
+E-mobility verification
THE ENGINEERING CHALLENGE
Components are only
part of the story.
A battery model can behave as expected on its own. A controller can pass its isolated tests. The next question is how they behave together—across operating modes, limits and software changes.
DEP brings model engineering and virtual software verification into a shared workflow. Connect the plant, controller software and scenario so that the team can investigate the system interaction.
It is the next home for DEVlink’s model-engineering capabilities, expanded around connected MIL and SIL work.
FROM MODEL TO SOFTWARE
Build understanding.
Keep it connected.
Represent the system.
Create native and physical models or bring in suitable FMUs. Define the behaviour, parameters and interfaces needed for the question you want to answer.
MIL: explore model behaviourIntroduce the software.
Bring controller software into the virtual system as a vECU. Connect its signals to the surrounding models and define the execution assumptions.
SIL: investigate real softwareRun a shared scenario.
Apply operating conditions, inspect results and compare the response against expected behaviour. Keep the model, configuration and evidence associated with the run.
Evidence: explain the resultA CONNECTED E-MOBILITY SYSTEM
Give the software
a system to work with.
An illustrative DEP workflow brings the physical-system models, controller software and verification scenario together. The exact model set and runtime configuration are defined for your application.
MODELSBattery · Power electronics
Battery · Power electronics
Thermal behaviour · Loads
The operating environment and physical behaviour.
SOFTWAREBMS · Energy management
BMS · Energy management
Charging or drive control
Controller applications represented as suitable vECUs.
SHARED SCENARIO & SIGNALS
Operating modes · Limits · Transitions · Expected results
MIL and SIL investigation with associated results and traces.
THREE SECTORS. ONE E-MOBILITY FOCUS.
Electrification changes
the whole system.
From battery to vehicle control.
Explore battery and BMS behaviour, charging interactions, power electronics and energy-management software in representative vehicle scenarios.
Automotive applications ↗Understand electric aviation.
Investigate battery systems, electrical power distribution and supervisory control across flight-related operating modes and ground-energy scenarios.
Aerospace applications ↗Develop electric equipment.
Explore battery-powered machinery, mobile equipment, charging interfaces and energy use across representative industrial work cycles.
Industrial applications ↗ILLUSTRATIVE DEP EVALUATION
How does the controller respond
when the battery reaches its limit?
Build the operating case.
Choose a representative battery model, an energy or charging controller and the limit condition to investigate. Define the expected response.
Connect the virtual system.
Explore the model behaviour in MIL, then include the controller software as a vECU for the SIL scenario.
Compare the responses.
Inspect the relevant signals and transition behaviour. Use the results to identify the next model or software investigation.
This is an example application for scoping an evaluation, not a published customer result.
DEP + CHARGELINK
System behaviour.
Charging communication.
DEP focuses on the connected model and software environment. ChargeLink focuses on EVSE and EVCC charging communication and protocol investigation.
For workflows that need both, define how ChargeLink’s CLI or API interfaces fit your virtual environment. The selected roles, models, interfaces and execution conditions are reviewed as part of the integration scope.
A real automotive Tier 1 has already used ChargeLink through CLI in its SIL environment to verify EVCC software as a vECU and deliver and test on time. That customer case demonstrates ChargeLink’s SIL integration; the customer’s platform was not identified as DEP.
Read the ChargeLink customer case ↗BEFORE YOU DECIDE
Start with the
engineering fit.
What is the difference between MIL and SIL?+
MIL investigates modelled system and control behaviour. SIL introduces executable controller software into a virtual environment to investigate its behaviour alongside the models.
Can we bring existing models and software?+
DEP’s scope includes native model engineering, FMI/FMUs and vECU workflows. The exact model format, software build, dependencies and runtime requirements need to be checked for your evaluation.
Can we connect multiple components?+
The platform’s focus is system composition: models, virtual controllers, signals and scenarios. Bring your intended component set so that interface compatibility and execution assumptions can be reviewed together.
What happened to MIL Studio?+
DEVlink’s MIL Studio capabilities have moved into DEVlink Engineering Platform. DEP is the product to explore for model engineering and connected MIL/SIL verification.
What should we bring to an evaluation?+
A representative model or vECU, the software and tool versions, required interfaces, one operating scenario and the expected result. The evaluation scope, licensing and supported configuration are agreed directly with DEVlink.
YOUR NEXT ENGINEERING QUESTION
Bring the model.
Bring the software.
Let’s define a MIL or SIL evaluation around your e-mobility system and the behaviour you need to understand.