Simulation-Based Controller Development


Since Weatherford´s most recent SimulationX project was finished ahead of time, we used the chance and organized a meeting in Langenhagen. One of the topics we discussed in detail is how to use system simulation to speed up and improve controller development. In traditional machine design, the controller developers are left waiting for a prototype to be finished so that they can test their controller code. Then the pressure starts: management sees what seems to be a finished machine on the workshop floor and starts wondering why it hasn’t been sold yet. That it doesn't have a brain yet doesn't seem to play a role, and so the controller developers are rushed to complete their implementation and testing.

The advantage of using simulation-based controller design is that the real machine is not needed to begin controller testing. By running the controller using a virtual plant, that is, a physics-based simulation model of the machine, it's possible to begin controller testing as soon as the design parameters are known. Other advantages include that you are able to automate the test procedures, and that test sequences leading to errors are reproducible. Furthermore, in case of a serious error, damages to the real machine are avoided.

So how does it work? Essentially there are three technologies that are used for simulation-based controller development. The exact definitions of these terms differ slightly from industry to industry, but generally they can be defined as follows.

Model in the Loop: A model of the controller runs inside the simulation software and is connected to the plant model.

Software in the Loop: The real controller software is connected with the plant model, but it is not running on its target platform.

Hardware in the Loop: The controller software is running on its target hardware and communicates with the simulation model via physical signals.
Software in the Loop using OPC; Simple Model of a Hydraulic Drive. Source: ESI ITI GmbH

Each of these technologies is used at a different stage of the controller development process.
Model in the loop (MiL) is used in the early stages of controller design to develop and test algorithms, and to determine the stability of control loops. The plant model is developed in a simulation software. Using a system simulation software such as SimulationX has the advantage of being able to model multiple subsystems in a single environment. Mechanical, electrical, fluid and thermal systems can all be considered in the same model. The controller can also be developed directly within SimulationX using state machines, signal blocks, or Modelica code. If the controller is available in a different environment such as Simulink, it's also possible to interface the controller model with the SimulationX plant model. The controller senses the condition of the plant model, e.g. displacement, pressure, temperature, etc. and stimulates the plant model based on the control algorithms. Operator input can be preset using input curves, or the model can be run in a real-time synchronized or accelerated mode and receive input from the user via sliders, dials, buttons, etc.
Software in the loop (SiL) is the next step in the development process. The controller code is finished, but it is not running on its target platform. The controller can run on an emulator, such as Siemens PLCSim, in a development environment such as B&R Automation Studio, on a SoftSPS or as a Windows DLL. In each of these cases the connection technology is somewhat different. Emulators use tool-specific interface blocks. Various development environments are supported by system simulation tools, for instance, the plant model can be integrated into B&R Automation Studio via SimulationX Code Export. Controller code running on a SoftSPS can be connected to via OPC or a specific API, and controller code running as a Windows DLL can be integrated into SimulationX, and thus connected to the plant model, as an external object. One limitation about software in the loop is that if the execution platform does not support virtual time, the simulation model must be able to run in real time. In some cases, this may require model reduction. In order to ensure a deterministic behavior regarding to time it's also recommended to use a fixed step solver. Since the number of iterations used to solve algebraic loops and differential equations in a fixed step solver is set, the calculation time is deterministic, as compared to tolerance-based DAE solvers, with non-fixed numbers of iterations per time step.

In hardware in the loop (HiL), both the real controller hardware and real controller software are used. The plant model no longer runs in the simulation environment, instead it is exported to the HiL platform and runs in real time. Interface signals (electrical signals, bus systems) are generated by the HiL platform. There are many HiL platforms available. It is important that the simulation software for the plant model supports the chosen HiL platform, that means, that the simulation software can export the model in the format required by the HiL platform. The HiL platforms supported by SimulationX are NI Veristand, NI Labview, dSpace Scalexio and ETAS Labcar (and other systems which can be addressed via Functional Mock-up Interface (FMI) or Simulink) .
An example of using hardware in the loop technology is shown in the diagram below. 
Excavator HiL Automated Testing Workflow. Source: HyDrive Engineering

The mechanical, electrical and hydraulic systems of an electro-hydraulic excavator were modeled in SimulationX. The model was exported to NI VeriStand where it was connected to the electronic control unit (ECU) via a signal conditioning unit and a failure insertion unit. The ECU receives sensor signals from NI VeriStand and returns the corresponding valve currents. A list of test cases was generated manually. Using the NI VeriStand API it was possible to automate the testing process. The system runs through the list of test cases and produces a set of test reports. In this way, changes to the controller software can be quickly and automatically tested using a virtual excavator.
Excavator HiL Hardware Setup. Source: HyDrive Engineering

Weatherford Oil Tool is one of the largest international oil and natural gas service companies, providing products and services for drilling, evaluation, completion, production and intervention of oil and natural gas wells, along with pipeline construction and commissioning. Relying on SimulationX´s hydraulic and MBS libraries as well as the OPC-interface, Weatherford´s time-to-market is minimized by using 1D multi-domain simulation software in the development and virtual commissioning of their products. Using system simulation is one of the main reasons for Weatherford still being competitive even in times of low oil prices.

Comments