Academia.eduAcademia.edu
All Topics
Computer Science
Modeling and Simulation
Software In the Loop

Software In the Loop

description14 papers
group0 followers
lightbulbAbout this topic
Software In the Loop (SIL) is a simulation technique used in systems engineering and software development, where software components are tested in a virtual environment that mimics the hardware and system interactions. This approach allows for early detection of software issues and validation of algorithms before deployment in real hardware.
lightbulbAbout this topic
Software In the Loop (SIL) is a simulation technique used in systems engineering and software development, where software components are tested in a virtual environment that mimics the hardware and system interactions. This approach allows for early detection of software issues and validation of algorithms before deployment in real hardware.

Key research themes

1. How can Software-in-the-Loop (SIL) and Hardware-in-the-Loop (HIL) simulations improve software system development and validation?

This research theme investigates the use of SIL and HIL simulation techniques to enhance the development, testing, and validation of complex software systems, particularly embedded and cyber-physical systems. It aims to address challenges such as system safety, real-time performance, and realistic environment emulation before deployment, which are critical in high-stakes domains like aerospace and autonomous vehicles.

Real Cockpit Proposal for Flight Simulation with Airbus A32x Models: An Overview Description
by Thadeu Brito

2023

Key finding: This paper implements a cyber-physical system (CPS) flight simulator cockpit based on Mechatronic principles combined with agile software development, validated through SIL and HIL simulations. It shows that integrating a... Read more
articleView PaperdownloadDownload
Guidance for Autonomous Underwater Vehicles in Confined Semistructured Environments †
by Zorana Milosevic

2024, Sensors (Basel, Switzerland)

Key finding: The study designs and validates a guidance system for the UX-1 autonomous underwater vehicle using software-in-the-loop and hardware-in-the-loop testing paradigms. It evidences that applying these simulation environments... Read more
articleView PaperdownloadDownload

2. What are the practical tools and methodologies to support incremental software change and program comprehension in software-in-the-loop environments?

This theme focuses on tools and interaction models that facilitate managing and understanding software changes incrementally under ongoing development and runtime environments like SIL. It encompasses methodologies for impact analysis, change propagation, and developer-oriented explanations that aid maintaining software accuracy and efficiency across evolving software lifecycles.

JRipples: A Tool for Program Comprehension during Incremental Change
by Maksym Petrenko

2024, 13th International Workshop on Program Comprehension (IWPC'05)

Key finding: JRipples supports incremental software change in Eclipse by managing impact analysis and change propagation through class dependency tracking and user-driven decision making. It offers a structured, semi-automated process to... Read more
articleView PaperdownloadDownload
Cognitive tools for locating and comprehending software objects for reuse
by Gerhard Fischer

2024, [1991 Proceedings] 13th International Conference on Software Engineering

Key finding: The paper presents CODEFINDER and EXPLAINER systems to aid developers in locating reusable software components and understanding them in terms aligned with their problem-solving frameworks. This research advances program... Read more
articleView PaperdownloadDownload

3. How does dynamic analysis and real-time program behavior visualization support understanding and troubleshooting in running software systems (software-in-the-loop)?

This theme covers the study and development of dynamic analysis tools and techniques that allow developers to observe, interpret, and interact with the running state and behavior of programs. Such tools enhance understanding of complex and long-running software systems by mapping runtime events into programmer-intuitive models, facilitating debugging, performance tuning, and system trustworthiness during software-in-the-loop operation.

What Is My Program Doing? Program Dynamics in Programmer’s Terms
by Steven Reiss

2016, Lecture Notes in Computer Science

Key finding: The paper articulates the need for tools enabling programmers to understand system dynamics in familiar, high-level abstractions while running applications live, particularly for large-scale and asynchronous systems. It... Read more
articleView PaperdownloadDownload
Approximator: Predicting Interruptibility in Software Development with Commodity Computers
by shahram jalaliniya

2022

Key finding: Approximator provides an interruptibility prediction system that uses only commodity laptop sensors (keyboard, mouse, face detection) combined with machine learning to estimate developer availability for interruptions with... Read more
articleView PaperdownloadDownload
A cross-tool communication study on program analysis tool notifications
by Rahul Pandita

2023, Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering

Key finding: The study identifies 10 categories of challenges causing miscommunication in program analysis tool notifications across diverse tools. It finds that modeling developer experience can enhance notification clarity and... Read more
articleView PaperdownloadDownload
keyboard_arrow_downShow more

All papers in Software In the Loop

Guidance for Autonomous Underwater Vehicles in Confined Semistructured Environments †
by Zorana Milosevic

2024, Sensors (Basel, Switzerland)

In this work, we present the design, implementation, and testing of a guidance system for the UX-1 robot, a novel spherical underwater vehicle designed to explore and map flooded underground mines. For this purpose, it needs to navigate... more
descriptionView Paperarrow_downwardDownload
A Smart Meter Infrastructure for Smart Grid IoT Applications
by Stefano Quer

2024, IEEE Internet of Things Journal

Electric infrastructures have been pushed forward to handle tasks they were not originally designed to perform. To improve reliability and efficiency, state-of-the-art power grids include improved security, reduced peak loads, increased... more
descriptionView Paperarrow_downwardDownload
Real Cockpit Proposal for Flight Simulation with Airbus A32x Models: An Overview Description
by Thadeu Brito

2023

This paper describes the several steps to build an elaborate flight simulator cockpit, where the hardware is designed based on Mechatronic principles and the proposed software was developed using agile methodologies to create a... more
descriptionView Paperarrow_downwardDownload
A scalable hardware-in-the-Loop simulation for satellite constellations and other multi-agent networks
by Christopher DeGraw

2023

Figure D.43: 1-hour maximum temperature by agent
Figure D.44: 1-hour minimum temperature by agent
Figure D.45: 1-hour average temperature by agent
Figure D.46: 1-hour temperature standard deviation by agent
Figure D.47: 1-hour measured CPU usage agents 1-5
Figure D.48: 1-hour measured CPU usage agents 6-10
Figure D.49: 1-hour recorded HWIL gyro, accelerometer, and magnetometer
Figure D.30: Classical orbital elements from agent 1&
Figure D.31: Angular momentum agent 18
Figure D.33: Orbit plot from agent 20
Figure 2.1: Current COSMoS System. HWIL simulation quality is the guiding design principle behind COSMoS. There-
Figure 2.2: Control scheme with strict noumenonological and phenomenonological separation.
2.3. Real-Time Operation We are assuming that flight software and hardware operate at 1 Hz for general oper-
Figure 2.6: Asynchronous host to agent to software state data diagram before simu- lation start.
Figure D.37: Orbit plot from agent 33
Figure D.21: Orbit plot from agent 15
Figure D.25: Orbit plot from agent 17
Figure 2.7: Asynchronous host to agent to software state data diagram after first transmission.
Figure 2.8: Agent plans a maneuver.
Figure 2.9: Host receives maneuver plan and re-propagates states.
‘igure 2.10: Agent receives new states and host resumes asynchronous propagation.
Figure 3.4: 8-hour test mean packet round-trip time
Figure 3.5: 8-hour test packet-round trip time standard deviation
Figure 4.1: Conceptual design of the COSMoS system. while the planned functions will be discussed in Chapter &
Figure 4.2: COSMoS Simulation Data Flow benchmark test. Here, the simulation data flow is largely asynchronous with the hos
Figure 5.1: Sense HAT[34] provide proof of concept for integrating hardware devices into the MADNS framework
In a case where the hardware driver had to be built for the simulation, this would nec-
and generated the data presented below.
The round-trip packet time nearly perfectly matches the desired 20 Hz operation
Figure 6.2: Packet-round trip time standard deviation Figure 6.1: Mean packet round-trip time
Figure 6.3: 6-minute test mean packet round-trip time set at 20 Hz. The results are seen below: Another test was performed for 6-minutes with the simulation processing rate still
Figure 6.4: 6-minute test packet-round trip time standard deviation
Figure 6.5: 1-hour test mean packet round-trip time
Figure 6.6: 1-hour test packet-round trip time standard deviation
Figure 6.7: 8-hour test mean packet round-trip time
Figure 6.8: 8-hour test packet-round trip time standard deviation
Figure 6.9: 8-hour test maximum temperature by agent
Figure 6.10: 8-hour test mean temperature by agent to process HWIL interface data while simultaneously propagating orbits. The HWIL results are discussed further in Chapter 7.
Figure 6.11: IRIDUM-8 4-hour orbit plot
“igure 6.12: IRIDIUM-8 4-hour angular momentum
Figure 6.13: COSMoS 4-hour simulation all orbits
Orbit plot from IRIDIUM-8 Figure 6.14: IRIDUM-8 1-hour orbit plot with guidance command
Figure 6.15: IRIDIUM-8 1-hour angular momentum with guidance command
Figure 6.16: IRIDUM-16 1-hour orbit plot without guidance command Orbit plot from IRIDIUM-16
Figure 6.17: IRIDIUM-16 1-hour angular momentum without guidance command
Figure 6.18: 1-hour COSMoS test maximum temperature by agent
Figure 6.19: 1-hour COSMoS test mean temperature by agent
Figure 7.1: 3-minute gyro, accel, and magnetometer measurements
Figure 7.2: 3-minute temp, pressure, and dt measurements
Figure 7.3: 6-minute gyro, accel, and magnetometer measurements
Figure 7.4: 6-minute temp, pressure, and dt measurements
Figure 7.5: 1-hour gyro, accel, and magnetometer measurements
Figure 7.6: 1-hour temp, pressure, and dt measurements
Figure 7.7: 8-hour gyro, accel, and magnetometer measurements
Figure 7.8: 8-hour temp, pressure, and dt measurements
Figure 7.9: 1-hour gyro, accel, and magnetometer measurements
Figure 7.10: 1-hour temp, pressure, and dt measurements
Figure 7.11: 1-hour gyro, accel, and magnetometer measurements
Figure 7.12: 1-hour temp, pressure, and dt measurements
Figure 7.13: 1-hour COSMoS test maximum temperature by agent
Figure 7.14: 1-hour COSMoS test mean temperature by agent
The most important thing here is that host_simulation_function return any mes- sages needed by the system for logging, exiting, or any other purpose not directly related to the simulation. def start_agent_simulation(simConfigData, initialStateData, HWILinterface,
Figure D.27: Angular momentum agent 17 Figure D.26: Classical orbital elements from agent 17
Figure B.1: Long delays found while using Multiprocessing. Process The Multiprocessing.Queue structures do not fail gracefully. During the November-January rewrite of the MADNS system, multiple tasks were launched as separate processes. Experiments with the Multiprocessing.Pool and Multipro- cessing.Process libraries showed that processing functions created using Pool were significantly slower than those made with Process, so the MADNS code base used Process. The reason for the slow performance of Pool became apparent during heavy testing of the MADNS system. Early benchmark tests came back with the terrible results seen in Fig. B.1.
Figure B.2: Speedup caused by serial processing The system was set to run at 20 Hz on both the host and agents, but each message had a round-trip time of 1.1 seconds. The problem was tracked to the host computer, where approximately 1.0 of the 1.1 second delay occurred. This was due to the system simply freezing when the Multiprocessing. Queue library failed. In low-usage cases, this problem could be rectified by setting a lower timeout on the Queue. get() commands, but that caused serious problems with heavy usage. In two cases, during particularly heavy usage, the host computer hung completely and required manual rebooting by disconnecting the power. Once the host was set to process all counter packets in serial, Fig. B.1 shows that the time delay was reduced to 50ms on each round trip as would be expected with the 20 Hz processing rate. The delay seen
minutes with an OS.Pipe error as seen in Fig. B.2. When propagating 10 satellites, the system would fail within 45 seconds.
Figure C.1: 8-hour packet round-trip time for agents 1-5 Fig. C.1 demonstrates that no counter packets were lost during the benchmark af
Figure C.3: 8-hour test packet round-trip time agents 11-15
Figure C.4: 8-hour test packet round-trip time agents 16-2(
Figure C.6: 8-hour test packet maximum round trip time
Figure C.7: 8-hour test packet minimum round trip time
‘igure C.8: 8-hour test packet round trip time range
Figure C.9: 8-hour test packet average round trip time
Figure C.10: 8-hour test packet round trip time standard deviation
Figure C.13: 8-hour measured temperature agents 6-10 Figure C.14: 8-hour measured temperature agents 11-15
Figure C.15: 8-hour measured temperature agents 16-20
Figure C.16: 8-hour measured temperature agents 21-22
Figure C.17: 8-hour maximum temperature by agent
Figure C.18: 8-hour minimum temperature by agent
Figure C.19: 8-hour average temperature by agent
Figure C.20: 8-hour temperature standard deviation by agent
Figure C.21: 8-hour measured CPU usage agents 1-5
Figure C.22: 8-hour measured CPU usage agents 6-10
Figure C.23: 8-hour measured CPU usage agents 11-15
Figure C.24: 8-hour measured CPU usage agents 16-20
Figure C.26: 8-hour recorded HWIL gyro, accelerometer, and magnetometer
Figure C.27: 8-hour recorded temperature, pressure, and calculated packet At
Figure D.6: Classical orbital elements from agent 11
Figure D.7: Angular momentum agent 11
Figure D.10: Classical orbital elements from agent 12
Figure D.11: Angular momentum agent 12
Figure D.14: Classical orbital elements from agent 13
Figure D.15: Angular momentum agent 13
Figure D.17: Orbit plot from agent 14
Figure D.18: Classical orbital elements from agent 14
Figure D.19: Angular momentum agent 14
Figure D.29: Orbit plot from agent 18
Figure D.38: Classical orbital elements from agent 33
Figure D.39: Angular momentum agent 33
Figure D.50: 1-hour recorded temperature, pressure, and calculated packet At
Figure D.55: Orbit plot from agent 33
Figure D.56: Classical orbital elements from agent 33
Figure D.57: Angular momentum agent 33
Figure D.61: 1-hour maximum temperature by agent
Figure D.62: 1-hour minimum temperature by agent
Figure D.63: 1-hour average temperature by agent
Figure D.64: 1-hour temperature standard deviation by agent
Figure D.65: 1-hour recorded HWIL gyro, accelerometer, and magnetometer
run in proximity to the phenomenon, but it still maintains the distinction between factor: The two processes on the agent represent a quasi-noumenonological process data provided to an agent executable, such as flight software, and data available to
‘*The system was unable to parallelize due to issues discussed in Chapter & relative to these equations: Looking at the asynchronous communication inequality
the network in a COSMOS simulation: Assuming a worst case scenario where over 1 second, all 10 agents require state updates, send system status updates, and require Looking at bandwidth inequality requires examining all expected data packets on
The Sense HAT comes equipped with the following sensors[35]: For the purpose: of testing MADNS and COSMoS, the accelerometer, magnetometer, gyroscope, pres-
descriptionView Paperarrow_downwardDownload
Guidance for Autonomous Underwater Vehicles in Confined Semistructured Environments †
by Sergio Dominguez

2023, Sensors (Basel, Switzerland)

In this work, we present the design, implementation, and testing of a guidance system for the UX-1 robot, a novel spherical underwater vehicle designed to explore and map flooded underground mines. For this purpose, it needs to navigate... more
descriptionView Paperarrow_downwardDownload
Novel tools for model-based control system design based on FMI/FMU standard with application in energetics
by Janina Koenig

2023, 2017 21st International Conference on Process Control (PC)

The paper presents novel tools for model-based control system design based on FMI/FMU standard (Functional Mock-up Interface / Unit). It is focused on application of FMI standard for easy integration of control system development cycle... more
descriptionView Paperarrow_downwardDownload
Real Cockpit Proposal for Flight Simulation with Airbus A32x Models: An Overview Description
by José Lima

2023, Proceedings of the 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

This paper describes the several steps to build an elaborate flight simulator cockpit, where the hardware is designed based on Mechatronic principles and the proposed software was developed using agile methodologies to create a... more
Figure 1: V-model approach used in structured systems de- sign (Fodor et al., 2019), (Bruyninckx, 2008). The V-Model allows the design and development of complex mechatronic systems with an interdisci- plinary method, where the VDI guideline 2206 can be applied to obtain systems that are more flexible and adaptable to the needs of users. The overall devel- opment process follows the V-Model that is shown in Figure | (Shuping and Ling, 2008; Fodor et al., 2019).
Figure 2: System Architecture. which classifications he/she wishes to acquire, and which flights he/she intends to train.
Figure 3: Main system architecture.
For “that purpose, it was “developed a plugin (IPB XCockpit, detailed on Figure 4) that sends and receives TCP packets from/to the Gateway. This gate- way allows to connect the CANO and CANI buses where all the modules are connected. Figure 4: IPB XCockpit plugin detailed. Figure 6: Under development of pedestal panel cockpit at IPB. Figure 5: Under development of frontal cockpit at IPB.
and communicates with a intelligent sensors network using a gateway (Ethernet and CAN bused converter). The intelligent sensor network is spread by all over the cockpit as a modular ap proach. Some modules of hardware and mechanical components are presented in Figures 5 and 6. The first one shows the flight screen on a wall television, by the FCU (Flight Contro lot controls are placed. T installed on the Electronic the front panel composed Unit) where the Autopi- he Barometer system are Flight Instrument System where warnings and master caution indicators are pre- sented also. On the other hand, the radio controls and communication system are presented on Figure 6.
Figure 7: BARO and Autopilot control panel assuming the programmed values at the developed cockpit validating the communication between modules.
Figure 8: Monitors of the front cockpit panel. Monitors can be selected by the Electronic Centralized Aircraft Mon- itor (ECAM) Control Panel a) Door information (DOOR), b) Engine/Warning Display (E/WD), c) Engines (ENG), d) Primary Flight Display (PFD) where horizon, speed and al- titude information is presented, e) Navigation Display (ND) with waypoints, navaids and airports localization. the EFIS (Electronic Flight Instrument System), and the ECAM (Electronic Centralized Aircraft Monitor) control panel to select system pages on System Dis- play. This modular approach had supported more than fifty students working on this project. As it can be noted, this paper presented a continuous working-in- progress development of a real cockpit to be used in simulation and there are several modules that can be included. As future work direction, it can be pointed out a projection based on three projectors using an im- mersive methodology and other instruments that will fit on the designed and planned, such as the develop- ment of the Throttle control system with motorized trim wheel, as well as the implementation of all over- head panels such as Ligh, Elec, HYD/Fuel, Fire, FLT CTL, ADIRS, Office and GPWS among the others.
Table 1: Main panel Monitors description. These monitors can be configured to show differ- ent information and can be selected by the Electronic Centralized Aircraft Monitor (ECAM) Control Panel. It will be possible to use the wall television to show the landscape and environment as the windows on the real cockpit. As result, it was proposed a cock- pit owning several instruments, monitors and controls to make the flight simulation more realistic. All the instruments were communicating with the simulator allowing the pilot to have a flight experience more re- lated with a real components instead of a television emulated instruments. ously addressed, the monitors presented on the frontal panel, will display information as the real cockpit. Each monitor uses a Raspberry pi 4 and some exam- ples are presented on Figure 8. Table 1 details each screen information.
descriptionView Paperarrow_downwardDownload
Integration of complex Modelica-based physics models and discrete-time control systems: Approaches and observations of numerical performance
by aldi efendi

2022, international modelica conference

A Modelica-based air conditioning (A/C) system model has been integrated, closed-loop, with related Sfunction-based controls in the Simulink environment. The integration was performed with two different approaches, with a... more
Figure | (a) Hierarchy structure of the A/C model (b) Modelon A/C model layout AVIOGCION AAU TMOG! layOUr For this study, only models of the complete refrigerant system and the vehicle interior (cabin) were required to simulate the physics of interest. The plant models are Modelica-based and developed in Dymola 2015FDO01, utilizing component and refrigerant models from Modelon-supplied libraries. The structure and ayout of the A/C model package are shown in Figure 1. The Dymola package browser in the upper-left of Figure l(a) displays the package hierarchy and is shown with the A/C model selected. There are three sub-packages under the A/C model, namely, parameterized components, test benches, and A/C system model package. The parametrized components are specific, populated component models which are
The compressor control modulates the compressor speed based discharge determines temperature compressor using a PI pressure. The c speed to achieve discharge compressor speed is reduced and pressure exceeds on temperature request and refrigerant imate an appropriate target evaporator outlet profile and the compressor control sets the he target temperature control algorithm. control head If the compressor a specified limit, modulated using a PI controller to maintain a maximum allowed discharge pressure. Figure 3 Automotive air conditioning control systems
Figure 4 Integrated A/C model as a DymolaBlock S- function in Simulink The first integration approach is using the DymolaBlock S-function interface. This Dymo option allows models developed in Dymola to b compiled as S-functions incorporated directly in Simulink, enabling the powerful physical modelin capabilities of the Modelica language to be combine with the controls orientated approach of Simulin Figure 4 depicts the A/C model integrated in Simulink as a DymolaBlock S-function. Oo 2 ag 0° on
Figure 5 Integrated A/C model FMU in Simulink In this application, we only consider the FMI for Co-Simulation option for two reasons. First, FMI for Model Exchange is very similar to utilizing an S- function function approach, like the DymolaBlock, as they both use the Simulink solver, and_ the DymolaBlock process is already incorporated into our modeling process. Second, due to the nature of the continuum behavior of the A/C system physics, and the need for a variable time step solver for the plant model, FMI for Co-Simulation allows the use of Dymola’s solver for the physics in conjunction with Simulink’s solver for the controls. Figure 5 shows an A/C model FMU in Simulink, with open loop inputs.
The baseline performance for the A/C system model is defined as the physics-only Modelica model running the SC03 cycle open-loop in the Dymola environment, utilizing the DASSL variable time step with a solver tolerance of le-05. Baseline simulation run time was 185 seconds, about one third of the real cycle time of 600 seconds. Next, the S-functions version of the Dymola model was run open-loop in the Simulink environment. Due to the numerical stiffness of the mathematics, only the Simulink odel5s variable time solver was capable of reliable solutions, and we used a solver tolerance of le-05 to provide sufficient solution accuracy. The S-function simulation time averaged 183 seconds, essentially identical to the native-mode Dymola model. These results are shown as the first two bars in Figure 6. The actual SCO3 cycle time comparator of 600 seconds is the right-most bar in the figure. Figure 6. Comparison of the A/C system model computational performance
descriptionView Paperarrow_downwardDownload
Smart Energy Systems Laboratory - A Real-Time Control, ICT and Power HIL platform
by Florin Iov

2022

descriptionView Paperarrow_downwardDownload
Stochastic Optimization of Group-based Signal Control and Coordination Using Traffic Simulation
by Iisakki Kosonen

2022

Among advanced signal controllers being deployed in urban areas, group-based signal control has become increasingly prevalent due to its ability to display flexible phases according to real-time traffic conditions. On the other hand,... more
descriptionView Paperarrow_downwardDownload
Scheduled smooth MIMO robust control of aircraft verified through blade element SIL testing
by Coşku Kasnakoğlu

2022, Transactions of the Institute of Measurement and Control

This paper demonstrates a multi-input multi-output (MIMO) robust control approach where multiple scheduled designs are merged to produce a smooth control law. The design is verified using software-in-the-loop (SIL) testing based on blade... more
descriptionView Paperarrow_downwardDownload
Development of an Experimental Setup for the Altitude Control of a Ball in a Pipe
by Coşku Kasnakoğlu

2022, Applied Mechanics and Materials

In this paper we consider the development of a ball-and-pipe system controlled by an Arduino-based PID controller designed and tuned numerically in MATLAB/Simulink environment. The controller achieves small overshoot and fast settling... more
In this section the software used in the design is explained. The distance of the ball is measured by the ultrasonic range sensor HCSR-04. Athree-point median filter is used to eliminate spikes in the measurements. A set point altitude is input to the software and the difference between the set point and current altitude is the error, which is the input of the PID controller. The output of the PID controller is the current command, which is sent to the blower driver so as to control the air flow speed and hence adjust the ball’s altitude. The current control driving the blower is shown in Figure 3.The reason for the current control circuit design is to be able to achieve a quick response and to operate in the narrow range required for the setup at hand. The current control circuit utilizes a TIP 120 Darlington transistor since the Arduino itself cannot provide the high current required by the blower motor.
Fig. 3. Arduino circuit connections
Controller Design
Fig. 6.Tuned PID parameters in MATLAB/Simulink Fig. 5. PID controller system in MATLAB/Simulink
Conclusions and Future Works In this paper an experimental setup was developed to keep a ball in a pipe at a desired altitude. A PID controller was designed and tuned using MATLAB/Simulink with small overshoot and fast settling time. The controller was implemented using an Arduino Uno board to control the air flow
descriptionView Paperarrow_downwardDownload
Ricardo Campos, El Caso Morillo: Crimen, locura y subjetividad en la España de la Restauración , Frenia-CSIC, 2012, 270 páginas. [ISBN: 978-84-00-09593-2]
by Olga Villasante

2022, Asclepio-revista De Historia De La Medicina Y De La Ciencia

A Modelica-based air conditioning (A/C) system model has been integrated, closed-loop, with related Sfunction-based controls in the Simulink environment. The integration was performed with two different approaches, with a... more
descriptionView Paperarrow_downwardDownload
Standardized Integration of Real-Time and Non-Real-Time Systems: The Distributed Co-Simulation Protocol
by Klaus Schuch

2022, Proceedings of the 13th International Modelica Conference, Regensburg, Germany, March 4–6, 2019

Co-simulation techniques have evolved significantly over the last 10 years. System simulation and hardware-in-the-loop testing are used to develop complex products in many industrial sectors. The Functional Mock-Up Interface (FMI)... more
descriptionView Paperarrow_downwardDownload
The Functional Mock-up Interface 3.0 - New Features Enabling New Applications
by Christian Bertsch and 
1 more
Klaus Schuch

2022, Proceedings of 14th Modelica Conference 2021, Linköping, Sweden, September 20-24, 2021

The Functional Mock-up Interface (FMI) (Modelica Association 2021b) is a tool independent standard for the exchange of dynamic models and for co-simulation. FMI 2.0, released in 2014, is recognized as the de-facto standard in industry for... more
Figure 1. Comparison of interface types
Figure 2. Schematic view of data flow between user, the solver of the importer and the FMU for Model Exchange.
Figure 3. Schematic view of data flow between user, the co- simulation algorithm of the importer and the FMU for Co- Simulation. Compared to Figure 2, the solver is part of the FMU, and not part of the importer.
Figure 4. Schematic view of data flow between user, the sched- uler of the importer and the FMU for Scheduled Execution
Figure 5. Example supervisory control system and how the new features of FMI CS can improve its simulation. Finally, the Supervisor FMU may reconfigure the Con- troller FMU when a certain condition is met. When this happens, the Supervisor FMU may signal that stepping phase needs to be halted, and event handing is needed.
Figure 6. Example clocked control system.
Figure 7. Example FMU implementing the SE interface.
Figure 8. Example execution trace of Figure 7. Task N corre- sponds to execution of partition N, as detailed in Figure 7.
descriptionView Paperarrow_downwardDownload
The Functional Mockup Interface - seen from an industrial perspective
by Christian Bertsch

2022, Proceedings of the 10th International Modelica Conference, March 10-12, 2014, Lund, Sweden

The demand for model exchange between development partners will grow during the next years. The Functional Mockup Interface (FMI) is a well received tool independent approach for model exchange. The Original Equipment Manufacturers (OEM)... more
descriptionView Paperarrow_downwardDownload
Novel tools for model-based control system design based on FMI/FMU standard with application in energetics
by Jana Königsmarková

2022, 2017 21st International Conference on Process Control (PC)

The paper presents novel tools for model-based control system design based on FMI/FMU standard (Functional Mock-up Interface / Unit). It is focused on application of FMI standard for easy integration of control system development cycle... more
descriptionView Paperarrow_downwardDownload
Monitor BT Pilot Project: Combined Voltage Regulation Approach for LV Grids with PV Penetration
by Mario Nunes

2022

Monitor BT project aims at improving LV grid resilience by combining LV grid sensors and smart meter information to enable grid awareness, providing an innovative method for voltage regulation under PV generation presence. Monitor BT... more
descriptionView Paperarrow_downwardDownload
Improving Interoperability of FMI-supporting Tools with Reference FMUs
by Christian Bertsch

2022, Proceedings of the 12th International Modelica Conference, Prague, Czech Republic, May 15-17, 2017

The Functional Mockup Interface (FMI) is more and more adopted by industrial users, increasing the pressure for higher quality and standard compliance of FMI supporting tools. The FMI cross check infrastructure was created to support tool... more
descriptionView Paperarrow_downwardDownload
The Functional Mock-up Interface 3.0-New Features Enabling New Applications
by Klaus Schuch

2022

The Functional Mock-up Interface (FMI) (Modelica Association 2021b) is a tool independent standard for the exchange of dynamic models and for co-simulation. FMI 2.0, released in 2014, is recognized as the de-facto standard in industry for... more
Figure 1. Comparison of interface types
Figure 2. Schematic view of data flow between user, the solver of the importer and the FMU for Model Exchange.
Figure 3. Schematic view of data flow between user, the co- simulation algorithm of the importer and the FMU for Co- Simulation. Compared to Figure 2, the solver is part of the FMU, and not part of the importer.
Figure 4. Schematic view of data flow between user, the sched- uler of the importer and the FMU for Scheduled Execution
Figure 5. Example supervisory control system and how the new features of FMI CS can improve its simulation. Finally, the Supervisor FMU may reconfigure the Con- troller FMU when a certain condition is met. When this happens, the Supervisor FMU may signal that stepping phase needs to be halted, and event handing is needed.
Figure 6. Example clocked control system.
Figure 7. Example FMU implementing the SE interface.
Figure 8. Example execution trace of Figure 7. Task N corre- sponds to execution of partition N, as detailed in Figure 7.
descriptionView Paperarrow_downwardDownload
Parallel Execution of Functional Mock-up Units in Buildings Modeling
by Ozgur Ozmen

2022

Parallel Execution of Functional Mock-up Units in Buildings Modeling
Figure 1. This depiction shows the physical layout of the standard multi-tank mixing problem being used here as a test system model. where x is the liquid level, u is the input flow from the preceding tank, and a is the time constant that represents the geometry and physics of fluid flow to the succeeding tank. Figure 1 illustrates the whole system where X is the liquid level, i is the tank index, and N is the total number of tanks.
Figure 2. Tank-1 liquid levels are nearly identical across C++ implementation via 1 FMU, via 2 FMUs, and the OpenModelica (Euler) solver.
Figure 3. Tank-2 liquid levels are nearly identical across C++ implementation via 1 FMU, via 2 FMUs, and the OpenModelica (Euler) solver.
Figure 4. Runtimes when going to two cores for different simulation lengths and number of FMUs shows greatest speedup via parallelization of the solver loops. In general, there are three parts in a C++ implementation that could enable performance gains from parallelization for FMUs: (i) initializing all FMU instances, (ii) coupling FMUs (i.e., mapping inputs to outputs), and (iii) all solver loops. These parts are wrapped as OpenMP blocks and tested for performance using two compute cores. The runtime values for different numbers of FMUs (i.e., 1 tank per FMU), as seen in Figure 4, are compared to the baseline runtime for that set of FMUs on one compute core. Values that can change the runtime are: (i) integration time interval (df) used in the solver, (ii) the number of models per FMU, and (iii) total time simulated (—Tend in seconds). For each of the four scenarios, dt is 0.1 seconds and the Figure 4 shows the average runtime value when we replicate each scenario for 50 runs. Nearly linear speedup with the number of cores can be realized as the number of FMUs and the termination time increases.
Figure 5. Simulation runtimes (in seconds) for a 200-tank system as a function of the number of FMUs shows significant increases around 25 FMUs.
In Figure 5, overhead due to coupling begins to increase the runtime significantly above 25 FMUs. Ir Figure 6, the total runtime also increases due to coupling overhead after 25 FMUs, but the runtime savings can clearly be seen with fewer tanks per FMU. The longer runtime for the 200T1F system in Figure 6 is likely due to the cost of FMU creation for a large number of tanks. It is anticipated this would be similar to any single FMU which contains a large, computationally complex system. In the following section, parallel computing is explored to compensate the cost of initialization and coupling of FMU instances that are revealed in this section. Figure 6. Total runtimes (in seconds), including simulation, for a 200-tank system as a function of the number of FMUs shows an optimal runtime around 25 FMUs for this mixed-tank problem.
In this analysis, FMU initialization, coupling of FMUs, and solver loops are parallelized using the OpenMP code blocks. Figure 7 shows the benefit of parallelization as limited due to the cost of (non- parallel) creation of 200 1-tank FMUs. Figure 7. Comparison of a 200-tank model in 200 FMUs across multiple cores shows total runtimes (in seconds) do not
Figure 8. Comparison of a 200-tank model in 200 FMUs across multiple cores shows simulation runtime (in seconds), which is less than the 200TF1 system simulation runtime (red line) without parallelization. For most use cases, FMUs of sub-systems are provided and users are not obligated to regenerate FMUs. Hence, Figure 8 shows only the simulation runtimes that an end-user might experience when eac component is shared as an FMU (1T200F). As observed in Figure 8, three-core parallelization outperforms the simulation runtime of 200T1F system from Figure 5.
Figure 9. Running a 200-tank model as a function of the number of FMUs on four compute cores shows simulation runtimes (in seconds) that originates from load balancing.
Using Dymola’ and the Buildings Library, a test model is introduced that consists of three components: (i) Thermal zone, (ii) Cooling system, and (iii) Controller. The outside temperature (fixed) transfers heat into the thermal zone through the conductivity of the wall. When the zone temperature is higher than the temperature that is set in the controller, the fan turns on and cooled air flows in the zone. When temperature is at the range of +1-degree Kelvin around the set temperature, the fan turns off. Figure 10, Figure 11, and Figure 12 represent aforementioned three components, and Figure 13 represents how the whole system is connected through input and output ports. Figure 10. A thermal zone with outside temperature, conductivity of the walls, sensor, mixed air, and heat capacitance. Inlet and Outlet ports allow connections to other system components.
Figure 12. A controller that controls the mass flow of the water source that flows into the cooling coil in the cooling system. Input uw is the room temperature. Figure 11. A fan with cooling coil, mixed air, and water source and sink. They constitute the cooling system. Input u is the air mass flow rate decided by the controller.
3.2 SIMULATION RUNTIME PERFORMANCE OF THE ROOM MODEL
Figure 14. Simulation runtime (in seconds) of the three component room model across multiple cores shows limited performance benefits up to three compute cores.
Figure 15. Room model incorporating thermal zone, cooling system, and the controller together. Inputs u and uw. represent heat transfer through walls from an adjacent room.
Figure 16. Four-room model coupling. _ Couplings represent wall connections.
Figure 17. Four-room model temperature values for each room generated via the C++ wrapper and the hybrid solver. Figure 17 represents room temperatures generated by the hybrid solver in C++ and Figure 18 represents room temperatures calculated by the Dymola Euler solver. In experimental conditions, Tend i: 10,000 seconds and dt = 0.1. The solutions are nearly identical up to two decimal points.
Figure 18. Four-room model temperature values for each room generated via the Dymola (Euler) solver.
HUMAN Zao ala Ule COUPE WOU Sallie sleniCdalt PUNE PCrlOrmManCce UOPrOvVeMients, Analyzing the three-compute-core case, we observed both in the for multi-tank and three-component models, that whenever the number compute cores is not a proper divisor of the number of FMUs, the performance gain is limited. This is even worse in the three core case than two core case because the hybrid solver waits for all FMUs to be accomplished before advancing the time. Ideally, the computational burden of each compute core should be balanced to optimally benefit from additional computational resources. Figure 19. Simulation runtime (in seconds) comparison of the four-room model on different numbers of compute cores. Comparison against Dymola runtime of the Figure 16 system shows significantly less simulation runtime which is better than Dymola runtime.
descriptionView Paperarrow_downwardDownload
Smart grid research infrastructures in Austria: Examples of available laboratories and their possibilities
by Matthias Stifter

2022, 2015 IEEE 13th International Conference on Industrial Informatics (INDIN)

The large-scale roll out of renewables in several regions in the world has led to changes in the planning and operation of the electric power systems. They are becoming visible nowadays on all voltage levels in distribution and partly... more
descriptionView Paperarrow_downwardDownload
Power SnapShot Analysis: A new method for analyzing low voltage grids using a smart metering system
by Matthias Stifter

2022

The subject of this paper is to describe the method newly developed within the research project ISOLVES (Innovative Solutions to Optimize LV Electricity Systems). The objectives are to study LV grids in detail and to close gaps of... more
For the development and first validation of the solution described above, the Power-Snapshot-method had to be simulated. Therefore a case study with an exemplary LV- grid (Fig.1) was performed.
Figure 2. Loads and Voltages (1-sec-rms) at all nodes during 15 min
Figure 3. Snapshot of the 1-sec interval containing exhibiting the lowest voltage (Loads are shown at all nodes, voltages only for groups of nodes)
Figure 4. Snapshot for the 1-sec interval exhibiting the highest voltage corresponding to the maximal PV generation (3 & 6 kWp/ single phase)
In Fig. 3 and Fig. 4 the bar diagrams for the Voltage levels show voltage drops and rises from no load level (reference=230 V+4%). The load distribution in Fig. 3 causes voltage drops from +4% at the distribution station down to levels of -5%. The rest of the available voltage band is needed a reserve for drops occurring on medium voltage lines. In Fig. 4 the high penetration of PV-Systems with single phase converters typically results in a huge rise of the voltage. Depending on the medium voltage conditions at this time, the overvoltage protection might disconnect the PV-system from the grid. Nevertheless the technical rules published by the Austrian regulation authority require that the voltage rise caused by decentralized generation in LV-grids does not exceeds +3%. Figure 5. Highest and lowest voltage all over the LV-grid for each second of a “sunny” week-period (they occur at different nodes)
Figure 5. Number of different trigger proposition per measurement interval (minimal voltage - without PV, working day)
Figure 6. Flow chart of the Power Snapshot acquisition process Figure 7. From the signal to the campaign
descriptionView Paperarrow_downwardDownload
Novel tools for model-based control system design based on FMI/FMU standard with application in energetics
by Jana Königsmarková

2022, 2017 21st International Conference on Process Control (PC)

The paper presents novel tools for model-based control system design based on FMI/FMU standard (Functional Mock-up Interface / Unit). It is focused on application of FMI standard for easy integration of control system development cycle... more
descriptionView Paperarrow_downwardDownload
Novel tools for model-based control system design based on FMI/FMU standard with application in energetics
by Martin Čech

2021, 2017 21st International Conference on Process Control (PC)

The paper presents novel tools for model-based control system design based on FMI/FMU standard (Functional Mock-up Interface / Unit). It is focused on application of FMI standard for easy integration of control system development cycle... more
descriptionView Paperarrow_downwardDownload
Extending JGrafchart with Support for FMI for Co-Simulation
by Alfred Theorin

2021, Proceedings of the 10th International Modelica Conference, March 10-12, 2014, Lund, Sweden

descriptionView Paperarrow_downwardDownload
Extending JGrafchart with Support for FMI for Co-Simulation
by Alfred Theorin and 
1 more
Charlotta Johnsson

2021, Proceedings of the 10th International Modelica Conference, March 10-12, 2014, Lund, Sweden

descriptionView Paperarrow_downwardDownload
Tool-independent distributed simulations using transmission line elements and the functional mock-up interface
by Petter Krus

2017

This paper describes how models from different simulation tools can be connected and simulated on different processors by using the Functional Mockup Interface (FMI) and the transmission line element method (TLM). Interconnectivity... more
descriptionView Paperarrow_downwardDownload
An IoT Realization in an Interdepartmental Real Time Simulation Lab for Distribution System Control and Management Studies
by Edoardo Patti and 
2 more
Enrico Pons
Abouzar Estebsari

2016

Modern electric distribution systems with emerging operation methods and advanced metering systems bring new challenges to the system analysis, control and management. Interdependency of cyber and physical layers and interoperability of... more
descriptionView Paperarrow_downwardDownload
Generation of an Optimised Master Algorithm for FMI Co-simulation
by Paul Meulenaere and 
1 more
Bert Van Acker

2016

Model-based Systems Engineering plays a pivotal role in the design of Software-Intensive and Cyber-Physical Systems by enabling early virtual integration of the different parts of the system. Often multiple formalisms are combined to... more
descriptionView Paperarrow_downwardDownload
Generation of functional mock-up units for co-simulation from simulink®, using explicit computational semantics: work in progress paper
by Paul Meulenaere

2016

As the complexity of Software-Intensive and Cyber-Physical Systems increases, multiple formalisms are used to model different parts of a system. Rather than building simulators for these combinations of multiple formalisms, co-simulation... more
descriptionView Paperarrow_downwardDownload
Unambiguous power system dynamic modeling and simulation using modelica tools
by Patrick Panciatici

2016, 2013 IEEE Power & Energy Society General Meeting

Dynamic modeling and time-domain simulation for power systems is inconsistent across different simulation platforms, which makes it difficult for engineers to consistently exchange models and assess model quality. Therefore, there is a... more
descriptionView Paperarrow_downwardDownload
Functional Digital Mock-up and the Functional Mock-up Interface – Two Complementary Approaches for a Comprehensive Investigation of Heterogeneous Systems
by Christoph Clauß and 
1 more
Olaf Enge-Rosenblatt

2016, Proceedings from the 8th International Modelica Conference, Technical Univeristy, Dresden, Germany

Functional Digital Mock-up (FDMU) and Functional Mock-up Interface (FMI) are two keywords arising in the last years in simulation technology. In this paper, we would like to show that both principles, aiming at a comprehensive... more
descriptionView Paperarrow_downwardDownload
The Functional Mockup Interface for Tool independent Exchange of Simulation Models
by Christoph Clauß and 
1 more
A. Junghanns

2016, Proceedings from the 8th International Modelica Conference, Technical Univeristy, Dresden, Germany

The Functional Mockup Interface (FMI) is a tool independent standard for the exchange of dynamic models and for co-simulation. The development of FMI was initiated and organized by Daimler AG within the ITEA2 project MODELISAR. The... more
Figure 7: Three tools are controlled by one master 4.1 Master Slave Principle
Figure 2: Top level part of the FMI XML schema Both approaches share a bulk of common parts that
In Figure 2, the top- FMI-cases, with excep mentation”. If present, ion of evel par nition is shown. All parts are t of the schema defi- he same for the twc he element “Imple- he import tool should inter- pret the model description as applying to co- simulation. As a consequence, select the C-functions for model exchange. An impor he import tool mus: for co-simulation, otherwise ant part of the “Im. plementation” is the definition of capability flags tc define the capabilities supports: hat the co-simulation slave
At every event instant #,, variables might be discon- tinuous and therefore have two values at this time instant, the left” and the ’right” limit. x(¢,), m(#) are always defined to be the right limit at 4, whereas x (t;), m™ (t,) are defined to be the “left” limit at 4, e.g.: m (f;) = m(¢,.,). In the following figure, the two variable types are visualized: An event instant ¢; is defined by one of the following conditions that gives the smallest time instant:
Figure 8: Simple stand alone use case. Master and slave are running in the same process. The slave contains model and solver, no additional tool is needed. The next use case is carried out on different pro- cesses. A complete simulation tool acts as slave. In this case, the FMI is implemented by a simulation tool dependent wrapper which communicates by a (proprietary) interface with the simulation tool.
The slave (which can be a simulation tool as in Fig- ure 9 too) and the master run on different computers. The data exchange is handled by a communication layer which is implemented by a special FMI wrap- per. Neither the master nor the slave notice the tech- nology used by the communication layer. Both uti- lize the FMI for Co-Simulation only.
descriptionView Paperarrow_downwardDownload
Tool coupling for the design and operation of building energy and control systems based on the Functional Mock-up Interface standard
by Thierry Nouidui

2015, Proceedings of the 10th International Modelica Conference, March 10-12, 2014, Lund, Sweden

This paper describes software tools developed at the Lawrence Berkeley National Laboratory (LBNL) that can be coupled through the Functional Mock-up Interface standard in support of the design and operation of building energy and control... more
Figure 1: Simulation tools and hardware that can be coupled to the BCVTB.
Figure 2: FMU for co-simulation import interface in the BCVTB. The use of the BCVTB has the drawback that it in- roduces an additional transaction layer between the different simulators. As computing time is for most applications dominated by the simulation code inside he FMUs, the BCVTB middleware generally has no noticeable effect on the computing time. However, users need to have some familiarity with the use of he BCVTB. This increases the learning curve and
Figure 3: Importing an FMU for co-simulation in EnergyPlus through its ExternalInterface [25]. To facilitate the import of FMUs in EnergyPlus, we developed a utility called FMUParser. This utility is distributed with EnergyPlus and can be found in its PreProcess folder. When invoked, it unzips the FMU, extracts relevant information from the model description file of the FMU, and writes this infor- mation to a temporary EnergyPlus input file. A user can then complete this temporary input file to create the EnergyPlus input file. This parser has been de- veloped so that users do not need to read the model Figure 4 shows how the FMU for co-simulation im- port interface was used to couple an HVAC system, implemented in Modelica and exported as an FMU, o a room modeled in EnergyPlus. This example is described in detail in [24]. The HVAC system com- puted sensible and latent heat exchange with the room, using the air inlet and outlet as the thermody- namic boundary. The room model computed the emporal evolution of the room air temperature and humidity, using the sensible and latent heat exchange as inputs to its energy balance. The FMU uses as inputs the room dry-bulb temperature (TRooMea), he outdoor dry-bulb temperature (TDryBul), the room air relative humidity (rooRelHum), and the outdoor air relative humidity (outRelHum) to com- pute the sensible and latent heat exchange QSensible, QLatent) which are sent to EnergyPlus hrough its outputs. EnergyPlus uses these values to compute the new room air temperature and humidity.
Figure 4: Linking an HVAC model developed in Modelica to an EnergyPlus room model using the FMU for co-simulation import interface.
Figure 5: Coupling of an EnergyPlus model exported as an FMU with a PI-controller using Dymola. Table 1 shows a comparison between the different import and export capabilities. The table also lists their strengths and weaknesses. Although not ex- haustive, this table should guide users in the selec- tion of an import or export facility that is adequate for their specific application. Figure 5 shows how EnergyPlus is imported in Dymola as an input/output block which can be con- nected to other Modelica blocks.
Figure 7: FMU for co-simulation import interface in Niagara**. Figure 6: Niagara** framework (Courtesy: Tridium). g g
Tool coupling for the design and operation of building energy and control systems based on the Functi Vlock-up Interface standard
Table 1: Comparisons between different technologies to couple simulators’. Tool coupling for the design and operation of building energy and control systems based on the Functio: Mock-up Interface standard
descriptionView Paperarrow_downwardDownload
Functional mock-up unit for co-simulation import in EnergyPlus
by Thierry Nouidui

2015, Journal of Building Performance Simulation

This article describes the development and implementation of the Functional Mock-up Unit (FMU) for cosimulation import interface in EnergyPlus. This new capability allows EnergyPlus to conduct co-simulation with various simulation... more
Figure 1. Co-simulation of EnergyPlus with programs B and C using a one-to-tone approach. The second approach is a middleware coupling (Figure 2). The middleware acts as co- simulation master that orchestrates the simulation and manages the data exchange between the
Figure 2. Co-simulation of EnergyPlus with programs B and C using a midleware approach. various tools. middleware which enables the co-simulation of EnergyPlus with other software and hardware.
Figure 3. Co-simulation of EnergyPlus with programs B and C using a standard interface approach another program for co-simulation.
Figure 5. Dataflow of model-exchange and co-simulation using the FMI standard. Since this paper is focusing on co-simulation, we use ,,FMU” and ,,FMU import” as abbrevi-
Figure 6. Architecture of the FMU import. EnergyPlus are mapped to EnergyPlus objects. In the external interface, the input/output signals that are exchanged between the FMUs and
Figure 7. System with one FMU linked to EnergyPlus.
Figure 8. System with an HVAC system modeled in an FMU and a room model modeled in EnergyPlus (Q is the heat flow rate, T is the temperature, rnw is the water mass flow rate, and Xw» is the water vapor mass fraction). the mathematical structure of the coupled system. are not part of an algebraic loop and hence can be sent from one tool to another without changing Figure 9 shows the Modelica implementation of the HVAC model with the four inputs that This is an application of the first use case where the differential variables are room dry-bulb
Figure 9. Modelica implementation of the HVAC model which is exported as an FMU heating and humidification capacities. in the amount My = Yw*M%w,9 Where yp, and y, are the output signals of controllers that track
Figure 10. System with a shading controller in an FMU and a room model with a shading device modeled in EnergyPlus Figure 11 shows the Modelica implementation of the shading controller which has been modeled
EnergyPlus. Figure 11. Modelica implementation of the shading controller model which is exported as an FMU. Figure 12 shows how the shading controller sets the night shade to be active during time when
Table 1. Use cases with different system configurations
descriptionView Paperarrow_downwardDownload
A Generic FMU Interface for Modelica
by Peter Fritzson

2015

This paper discusses technical issues and implementation of a generic interface to import a Functional Mock-up Unit (FMU) into Modelica simulators, specifically the Open-Modelica environment. Whereas other approaches for importing the... more
descriptionView Paperarrow_downwardDownload
FMI Add-on for NI VeriStand for HiL Simulation
by Cosimo Palma

2014

Currently, most of the links from Modelica models to real-time hardware platforms suitable for Testing and Validation are based upon non standard model exchange format, or rely on third party preprocessor. This paper describes the... more
Figure 1: Example of HIL scenario in the automotive field Using the FMI Add-on you can make MiL/SiL/HiL with NI VeriStand framework and all Model Based Design environments compliant with the FMI for Co-Simulation standard. Figure 1 shows a typical scenario of the automotive field where some control algorithms have been designed in Simulaink and LabView, and the car model has been modeled in Dymola. With the FMI add-on and NI VenStand it is possible to deploy the plant model along with the control algorithms in several targets and perform HiL Validation for the whole system.
Figure 2: Example of Co-Simulation scenario in the automotive field with Dymola, Simulink and Lab- View Between these communication points the subsystems are solved independently. Figure 2 shows an exam- ple of Co-Simulation where a complete system has been modeled using three different tools, and where each model uses is own numerical solvers and ex- changes data thanks to the Co-Simulation master environment during the simulation.
=a SOL Gat Nara a) ee In order to check the compatibility of the dll in- cluded into the FMU files, LabVIEW RT DLL Checker [10] has been used. Using this tool, dll gen- erated by any commercial or free tool, together with hand coded and compiled ones must be tested in or- der to check if they are compliant for Phar Lap ETS environments.
NI VeriStand environment is a full featured Co- Simulation platform working as master for the Co- Simulation process. When several FMU’s and Co- Simulation slave models exported using other model exchange formats, e.g. S-Functions, are imported into NI VeriStand, it works as master considering every imported model as slave.
Figure 6: Installation of the FMI add-on on NI RT targets First of all a general schema of the HIL scenario, depending on the system that needs to be validated has to be developed, see Figure 1. Once the HIL schema has been decided, the installation of the FMI Add-on must be done in each RT target that will host an FMU model, see Fig. 6.
Figure 7: FMU for Co-Simulation model export from Dymola based environment in which it was developed. With the installation of the FMI add-on VeriStand will support fmu files in addition to dll, lvmodel, mdl and out files (Fig. 8) . It has to be highlighted that FMU models must be compliant with the FMI for Co-Simulation 1.0 standard. Fig. 7 shows a Dymola model exported with the FMI standard.
Figure 9: NI VeriStand workspace with custom scopes
Figure 10: System architecture for the Validation experiment
Thanks to the support of National Instruments devel- opment team it was possible to grant the best user experience in VeriStand to FMU importers. In fact the FMI add-on was developed in a way so that the import process in VeriStand is now the same for every model exchange format, as shown in Fig 11. Figure 11: Import of different external models using the system explorer
Figure 12: Model parameters explorer into V eriStand This issue will be more likely solved with the next release of the FMI specification that will allow pa- rameter tuning during runtime simulations. To finish the setup phase of the system architecture, the I/O of the all models must be coupled together using the System Configuration Mappings editor in VeriStand, see Fig. 13, and with physical I/O of the target, see Fig. 14.
Figure 13: System Configuration Mappings editor in VeriStand, I/O of the models are coupled together
Figure 14: System Configuration Mappings editor in VeriStand, I/O of the models are coupled with physi- cal I/O of the DAQ systems
Figure 15: NI VeriStand workspace developed tc control the manipulator model
Fig. 16, 17, 18 ana 19 show the simulation results in terms of reference angles and simulated angles for each axis of the manipulator. The results are com- pared to the ones obtained simulating the same sys- tem entirely in Dymola. We can note that the simula- tion results in Dymola are matching with the ones obtained in VeriStand using both windows and NI PXI targets. It has also to be noted that there are some little differences from the results obtained in Dymola and the ones obtained in the PXI target gen- erated from the “errors” introduced by different solvers and by logger used to save the output results and the limited resources of the PXI that generated data losses in the communication between the sub- model units and the master sample time. The data logger was added as a custom device in VeriStand, and is capable of saving the output data on the file system using a fifo.
Figure 17: NI VeriStand with Windows target Vs Dymola benchmark
Figure 19: NIVeriStand with PX] target Vs Dymola benchmark
descriptionView Paperarrow_downwardDownload
Download research papers for free!
580 California St., Suite 400
San Francisco, CA, 94104