I was asked this question a few years ago: “What’s the point of writing a model using an acausal modelling language if when it is compiled it ends up as procedural code?”. The “point” is exactly what happens when the acausal model is reformulated into procedural code. There-in lies the power of defining systems using an acausal modelling language vs. a programming language.
The main benefits are multiple:
- Redundant equations are removed from the core calculations
- Potential reduction of linear and non-linear systems of equations leading to faster and more robust models
- Model inversion through changing boundary conditions rather than manually rearranging the calculations and their order.
To demonstrate these advantages, I will use an automotive example to highlight how acausal modelling languages can make the system designer’s job more productive. By avoiding tasks such as manual rearranging of equations to suit different deployments of components or system models, meaningful analysis results can be generated quicker and more efficiently.
The example task:
Let’s consider a pertinent problem to today’s automotive engineer; how does one go about:
“Calculating the efficiency benefits of EV powertrain and driveline technologies whilst reducing variability factors from PID based driver models.” ?
In a forward facing model, the driver behaviour in interpreting the targets and applying control inputs to match the targets, introduces variability which can obfuscate the benefits of one technology over another.
So how do we go about reducing the driver variability?
Well, we could tune the PIDs in the driver to get a better match for the drive cycle speed-time target. The issue would be that the related “energy” of the PID output would be unrealistically high, or to put it in simple terms, the control signals would have very large amplitude and frequency. Not exactly a preferable outcome, prone to more problems down the road.
Another option would be to back calculate the motor speed corresponding to the desired vehicle speed and play this back using a speed actuator in place of the electric motor within the vehicle model. The drawback of this approach is that it will not give you the brake demand but only the torque/speed demand of the electric motor; which means we have to do more work, which is inefficient!
Taking a standard EV drivecycle test (such as the VeSyMA library example VeSyMA.Experiments.Examples.DriveCycleElectric), the approach we took was to redeclare one of the driver model longitudinal control modules with one using the Modelica.Blocks.Math.InverseBlockConstraints block. This block, available within the Modelica Standard Library, allows us to specify a target and a variable we want to match to the target through its real input connectors.
In effect, an inverse model is created. Control demand required is calculated by virtue of the control demand being linked internally to the constraint that the target and actual speed must equal. Modelica’s acausal nature makes this possible, as all the required model refactoring is achieved automatically via the compilation process.
The benefits of using the InverseBlockConstraints block are:
- We no longer need to tune driver model PIDs which in any case introduce variability of the control signals.
- We now also have a back-calculated control of the propulsion system and the braking system.
The output connector of the InverseBlockConstraints block is routed to the brake and accelerator pedal control via appropriate gains and limiters (Figure 1). As such, the required demand for the vehicle speed and target speed to be matched can be understood. A negative demand means braking, with the limiters and gains resulting in a brake demand; conversely, a positive demand means more throttle input, with the BrakeLimiter table preventing the brake from being applied.
The experiment and vehicle model are the same as the ones we would use for a forward facing conventional driver model (Figure 2) nulling the requirement of having to develop and maintain bespoke forward and inverse dynamic vehicle models.
Results:
EVs are relatively low in powertrain and driveline complexity in terms of gear shifting, clutches etc. Application of the InverseBlockConstraints block requires a bit more effort for more conventional powertrain vehicles; however, the additional effort by far outweighs the effort involved in developing and maintaining forward and inverse dynamic models of vehicles and the relevant parameterisation.
System models developed using procedural code cannot be easily inverted and therefore require time that could be better spent performing system analysis and design.
So in my experience, having developed and made use of causal and acausal models there is no doubt that for physical systems, my preference is for acausal modelling languages such as Modelica. This allows physical relationships to be established regardless of the application/investigation to be undertaken. That same model can then be used with minimal intervention in a wide range of applications.
We’d be keen to showcase the benefits of acausal modelling languages over causal programming languages for your specific applications. Please get in touch for more information.
Written by: Alessandro Picarelli, Engineering Director & David Briant, Project Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion
