His encouragement is always important to me and his revision also helped a lot in improving my thesis. Finally, I would like to thank my friends who helped or offered good ideas for my project.
Cyber-Physical System
Embedded System
An embedded system is a computer system designed for a specific purpose of mechanical and electrical devices and embedded in the device[5]. It means that when an embedded system receives a sensor signal, it must perform processing quickly and ensure that the response is sent within specific time limits. Embedded systems are typically designed specifically for specific applications, so they can be optimized so that the embedded system can be much less resource-intensive than general-purpose systems.
Because embedded system is very sensitive to time, it is always an important part to do timing analysis during the development related to embedded system.
Model Based Design
For example, by considering specific cases, the code size and running time of the embedded software are smaller, less energy will be consumed, a lighter system can meet all requirements, and the development cost will also be lower as a result. It is much easier and cheaper to correct errors in the model than on a real device, reducing development costs and increasing reliability. MDB can deliver identical, clearly described models, allowing multiple engineers to perform the development and analysis simultaneously, greatly reducing the development cycle.
Since a crash in simulation will not have serious consequences, MDB approach can also be used for some dangerous tests, which can help to develop products with high safety requirements[9][8].
Real-time Simulation
Sotware-in-the-loop Simulation
In SIL simulation, both the controller and the installation are deployed in the same environment with the same time steps. The simulation can be completely isolated from the physical world, so the simulation time does not have to be the same as the real world time. Faster simulation makes it possible to run more tests in a short time and reduce development time.
Slower simulation allows more computation to be performed in one execution, so more complicated systems can be simulated.
Hardware-in-the-loop Simulation
Software-in-the-loop (SIL) simulation is a technique for running the entire system, including plant model and controller, in the software environment. But HIL simulation runs the controller in a real embedded system in the physical world, so the system is tested in a more realistic environment. HIL simulation can also be used to perform tests that would be dangerous or expensive in the real world, so that a more reliable end product can be developed at a relatively low cost.
Furthermore, a timing analysis can be performed to measure the latency and its effect in the simulation.
Packet-Switched Network
By using HIL simulations, engineers are able to perform optimization and debugging at the hardware level. Thus, the simulation computer and embedded system should support real-time operation and high data transfer rate. In general, processing delay, transmission delay, and propagation delay are on the order of microseconds to milliseconds.
Queuing delay can be as small as on the order of milliseconds, but can be very long if there are many packets waiting in a queue.
Quadcopter
Thesis Objectives
Implementation and Analysis of HIL Simulation
Real-time Simulators
HIL Simulation Analysis
Networked Control
Quadcopter Model and Control
Model Description
The rotation matrix from body frame to inertial frame is: cosψcosφ cosψsinθsinφ−sinψcosφ cosψsinθcosφ+sinψsinφ sinψcosφ sinψsinθsinφ+cosψcosφ sinψsinθcosφ−cosψsinφ. sinθ cosθsinφ cosθcosφ. The dynamics of a quadcopter are described by the following equations: cosψsinθcosφ+sinψsinφ sinψsinθcosφ−cosψsinφ.
Controller Design
In this thesis, the quadcopter controller contains a Kalman filter and uses simple PID controllers to control the quadcopter model.
Quadcopter System Description
Four rotors in the quadcopter model will then affect the quadcopter body's conditions, sensor signals will also change. A round counter is used in the model, which is incremented by 1 at each round and sent out with sensor signals. In this way, when a set of control commands is received, it can match the sensor signals being sent out.
Assumption of Simulation Delay
In this simulation, we are interested in the elapsed time between sending a packet from the simulated real-time plant and the corresponding packet returning to the plant. If all packets have arrived before this one has been received, in the next round of controller execution, this packet will be received and the data processed by the controller. Finally, this packet is received and the command is received by the actuators in the model.
In the following part, we will see all possibilities for the round trip time can be under the above assumptions. In Fig.3.2, Ex Seq PC and Ex Seq BBB represent the performance of plant and controller respectively. If all buffers are empty at the beginning, we can see from Fig.3.2 that the round trip time can be 1 or 2 times of the sample time depending on the relative execution time and delivery time of two processes in controller and simulator.
However, for situation in Fig.3.2a and Fig.3.2c, where BI1>tPD1, this packet will be omitted. Then the package will be processed in the third round, then the return time is two sample time. If this packet is omitted, then consider the next packet's round trip time in the situation where (n−1) packets are in buffer.
From Equation 3.3, we can see that typically the round-trip time is (n+1)Ts, when a process tries to access data in an empty buffer, the total round-trip time increases by 1. To verify the above assumptions, a model will be built based on the above assumptions to simulate delays .
HIL Simulation Test
Now we can consider a general case, suppose at timetPI1, simulation in PC starts execution. n1packets are in the PC's input buffer whose size is L1. With known round trip time, execution time and delivery time, queue delay can be calculated. In section 3.4, we build a model according to Fig. 3.2 and compare the simulated latency with the actually measured latency.
Model of Latency
Latency Measurement
Execution Time of Controller
To measure execution time, we need some instructions that can cause measurable effects at the beginning and end of execution. To be more specific, GPIO pins in the BBB are used to generate these measurable effects. With the observations, the execution time is the interval between two pulses, which can be calculated with the formula Te=tp2−tp1.
Latency Caused by Network
Then, after a certain time2, the packet sent by the controller arrives in a buffer in the computer and waits there until the next execution of the simulation. Using Figure 3.2a as an example, if we capture a packet on a PC, we can calculate time∆tP= tBD1−tPO1. So far, the actual round-trip time, execution time, delivery time and queue delay have been measured.
Control Effect
Software In the Loop Simulation
Step response for height has long rise time, relatively large overshoot, long settling time and no steady-state error. For pitch and roll the answers are very similar, the rise time is quite short, they have some overshoots, the settling time is very long. In this thesis, to measure the effect of latency, pitch or roll will be used to evaluate control performance because these two values are most sensitive to latencies.
Collect the wave response step data in the SIL simulation, record the rise time and overshoot corresponding to the different delay. Rise time is defined as the time required for the response to rise from 10% to 90%. When the delay is large, the actuators will receive delayed feedback that is calculated with delayed error signals.
Since the error signals keep falling initially, the feedback will be larger if it is delayed and the controlled signals will rise faster.
Latency Measurement for Communication Model
- Execution Time
- Delivery Time
- Clock Drift
- Roundtrip Time
- Queuing Delay
And because of the clock drift, the offset changes over time at a fixed rate, as we can see in Fig.4.4a and Fig.4.4b, ∆tBand∆tP is affected by clock drift. According to Fig.3.2 and Equation 3.4, the roundtrip time is affected by the buffer states and the offset of the simulation and the controller execution time. When the BBB clock runs faster than the PC, the performance of the controller will appear earlier in each round as the simulation progresses.
When the BBB clock runs at the same speed as the PC clock, the buffer states and the offset between the execution time of two parts will not change much. When the BBB clock runs slower than the PC, the controller's executions are postponed so that ∆tP continues to grow. This phenomenon will be explained in section 4.2.5. a) BBB clock is faster than PC (b) BBB clock is same as PC (c) BBB clock is slower than PC.
Based on the assumptions in section 3.2, when the BBB clock is running faster than the PC clock, the BBB output packet will be faster than the PC can consume. Queuing delays in BBB look like the shape of ∆tP in Figure 4.6 and they behave the same as ∆tP when the clock skews are different. When the BBB clock is at the same speed as the PC, the queuing delay in the PC buffer will not change much.
In Fig.4.9 we can see two situations where the trade-off between running PC and BBB is the same. In Fig.4.9a, the delivery time is long, BBB executes before the packet delivery, so it will read the buffer from an empty buffer, the queue delay will increase by 5ms.
Timing Analysis
Effect on Control
The results show that the delay in the HIL network simulation is mainly caused by the network delay, especially the queuing delay. Queue delay depends largely on the buffer size, if the buffer size is n, the sampling time is Ts, the maximum queue delay is not Ts. Once the HIL simulation delay is found, the control performance can be predicted based on the SIL simulation results.
As we can see in the experiment result of Fig.4.7, if the receiving speed is faster than the sending speed, there will be mostly no packet waiting in buffer, so the queuing delay can be smaller. This thesis mainly focuses on the latency of network-based HIL simulation and its effect. For example, experiments in this thesis are done when execution time is too small to consider, more experiments can be done to observe the results when execution is large.
More experiments can be done to find the relationship between packet loss and clock asynchronization to support the conclusion. The control effect of HIL simulation is studied by comparing HIL and SIL simulation results. Improve robustness and accuracy of in-circuit power hardware simulation by choosing appropriate interface algorithms.
Limitations of hardware-in-the-loop simulations of space robotics dynamics using industrial robots. Analysis and compensation of time delay effects in hardware-in-the-loop simulation for automotive PMSM drive system.
Cyber-physical system
Real-time simulation and other simulations
Example of Hardware-in-the-loop simulation
Quadcopter Model
Quadcopter system model
Possible Execution Sequence In PC and BBB
System Used for Measuring Latency
Model for simulating latency
Communication between Simulink model and BBB controller
Output of quadcopter model
Latencys’ effect on rise time and overshoot for controller of roll
Measurement of Execution Time
Measurement of Delivery Time
Three situations of clock drift
Clock drifts’ influence on ∆t P
Round trip time in three different situations of clock drifting
Queuing delay in two buffers
Two similar executions with only first delivery time different
Simulation of Latency
Step response
Step response in SIL simulation