Onion Information

Page Clicks: 0

First Seen: 05/06/2024

Last Indexed: 10/25/2024

Domain Index Total: 80

In this post I will make the argument that error control (feedback) is not sufficient for good planning and that feedforward control is indispensable for good planning. To understand my motivation around this it is necessary to take a detour and talk about co-simulation, cyberphysical systems and my work on FmiGo . This post may seem meandering and in a sense it is, because it touches on some interrelated concepts. Co-simulation and cyberphysical systems Co-simulation revolves around coupling simulators written in different toolchains. A company like Scania that manufactures trucks will have different departments working on different parts of a truck. Each of these departments use different simulation toolchains for the parts that they develop. The engine department might use one toolchain to do its simulations and the chassis department might use another. Without some way to couple the simulations, each department must use a simplified model of the other departments' parts. The idea of co-simulation is that each department's actual simulator is used as part of the simulations carried out by every other department. The goal is to run all simulators as a whole, despite each simulator having its own internal solver. Another example where co-simulation is desireable is when splitting up simulations for parallelization. This turns out to be non-trivial for reasons that I will get to. Cyberphysical systems are systems that feature these kinds of simulators but where real physical systems can be plugged into the loop, such as an engine in a test cell coupled to a road model and a driver model. A planned economy is such a cyberphysical system. Another example is a human operator interacting with a simulation, also known as human-in-the-loop (or, humorously, monkey-in-the-loop). FMI The Functional Mock-up Interface (FMI) is a standard for wrapping simulators like those described in the previous section. Each such simulator is called a functional mock-up unit (FMU) in FMI parlance. An FMU is a .zip file with metadata stored as XML and the simultor itself stored as either shared object file (.so, .dylib and/or .dll) or as source code, or both. The simulator uses a standardized API. A master stepper uses this API to exchange information between FMUs and also to step time forward, to save/restore FMU state, to get partial derivatives and many other tasks. Not all FMUs implement all this functionality, which is where part of the challenge of co-simulation starts. Besides co-simulation, FMI also supports model exchange, where each FMU exposes the system of ordinary differential equations (ODEs) that defines their behavior. All inputs, including time, can be changed at will, and the resulting derivatives read off. This allows the master stepper to integrate all FMUs as a whole. While very useful for accurate simulation, such a model is unrealistic for the behavior of real workplaces (though it may be useful for planning). Co-simulation, where an FMU/workplace is allowed to "do its thing" for a period before communicating again, is a more realistic model. FmiGo is a master stepper developed at UMIT Research Lab . The work was led by Claude Lacoursière. I entered the project some time after it began and have been maintaining the code ever since. It is free software, and we'd like to see more people use it, so feel free to check out the FmiGo website if co-simulation is your thing. Co-simulation by example A concrete example of the problem of co-simulation is keeping the output shaft of an engine FMU locked to the input shaft of a driveline FMU. See the image below. The engine FMU models the inner workings of the engine, clutch and gearbox whereas the driveline FMU models the behavior of the driveshaft, differential and wheels. There are multiple modes at play in the system that happen at different timescales. Fast modes of the system include the driveshaft and engine internals while slower modes are the behavior of the wheels and the gas pedal. A system that has a large ratio between its fastest and its slowest modes is called stiff , and the ratio is called the system's stiffness ratio . Stiff systems are notoriously hard to deal with, especially in co-simulation. This is because each system cannot be stepped with a timestep longer than a fraction of the period of the fastest relevant mode. If for example the engine runs at 3000 RPM, the gear ratio is 1:5 and we need 1000 steps per revolution of the driveshaft, then each global timestep cannot be longer than 100 µs. This is a huge amount of overhead. Each simulator can only be run for 100 µs, then data must be exchanged, and only then can each simulator be let loose on another 100 µs. Meanwhile the monkey in the loop only cares about things that happen on timescales around 100 ms or slower. If we didn't need 1000 steps per revolution but instead could get away with say 10 steps, then we only need a much more reasonable 10 ms per global timestep. Force-velocity coupling One way to couple the two simulators is to use something called force-velocity coupling . In the image above the angular speed ω gearbox of the gearbox' output shaft is fed to the driveline FMU, and a torque τ is fed back to the engine FMU. τ is computed by inserting a spring and a damper inside the driveline FMU between the driveshaft and an "immovable wall" or "connector" with infinite inertia rotating with angular speed ω gearbox . In the figure above this is illustrated as a spring and a dashpot respectively, and a small "plate" representing the immovable wall. Those who prefer rotational rather than linear parts may think of these as a clockspring and a hydrodynamic damper respectively. The damper contributes to the torque proportional to the difference in angular speed, and the spring contributes torque proportional to the difference in accumulated angle, which is computed by integrating the difference in angular speed, like so: τ = d ( ω driveshaft - ω gearbox ) + k ∫ ( ω driveshaft - ω gearbox ) d t where d is the damping coefficient and k is the spring coefficient. This is called force-velocity coupling in the literature. τ is fed back to the engine FMU at each global step. One can use (from the driveline FMU) either τ 's instantaneous value at the start of the current timestep, the end of the current timestep, or an integrated average over the entire timestep. On the gearbox side, the received τ is typically held constant. Note the similarity to proportional-integral (PI) control. If the timestep, k and d are chosen appropriately, then the entire ensemble will behave as one would expect. If the truck is driving up a hill, the driveshaft will start slowing down. This will cause a mismatch in angular speed between gearbox and driveshaft which will result in a higher counter-torque being fed back to the engine. The engine will then slow down and both sides of the shaft constraint will eventually converge as the truck finds its new equilibrium speed given the current gas pedal input. The choice of coefficients is non-trivial and depends on the global timestep and the inertia of all parts of the system, both of which may vary considerably. If d and k are set too low then the resulting system behaves as if the driftshaft is a highly flexible torsion spring (or a wet noodle). Step on the gas pedal and nothing happens for several seconds as the violation between the two sides of the shaft coupling builds, until sufficient torque develops and the truck finally starts moving. Once the truck does move, the pent up energy in the coupling will cause the speed on the input side of the driveline to overshoot and oscillate, and the system will overall behave as if there's no causal link between the gas pedal and the wheels. An undesired dynamic has been added to the system which is entirely an artifact of the coupling. Me and Claude use the term "pneumatics" for this undesired compressibility, to distinguish it from the incompressible "hydraulic" behavior of the preferred method used by FmiGo (SPOOK) which I will get to. If on the other hand d and k are set too high then the system will become numerically unstable and quickly explode. This can be thought of as the system overcorrecting for errors in each timestep. A final option is to decrease the global time step, increasing the number of times ω and τ are exchanged per second. This degrades performance but can bring the violation between both sides of the coupling arbitrarily low if d and k and are also increased appropriately. What is described above amounts to error control . There is no way the system as a whole can anticipate and correct for errors before they happen. Even when errors do occur, it takes a long time for the system to converge to a coherent state. Finally, convergence is linear, meaning the error shrinks as O ( e Δ t ) where Δ t is the global time step. SPOOK The SPOOK solver used by FmiGo achieves quadratic convergence, O ( e ( Δ t ) 2 ) [1] . It revolves around computing a set of forces at each time step that, when applied, keeps the whole system together. The way it achieves this is by modelling the behavior of each FMU, and through a bit of time travel. Let's start with the time travel. SPOOK makes use of the ability of some FMUs to save their internal state and to restore it at a later time. It saves the state of all FMUs, holds their inputs constant and steps them one time step into the future. It then reads the velocities of all relevant connectors, and then resets all FMUs to the present time step. This allows the solver to compute the velocity of the future violations of all constraints. In other words, if during the current timestep the truck starts going uphill, this will result in a future discrepancy between the two ends of the shaft constraint in the present example, meaning the shaft constraint itself acquires a velocity in the future. The solver may optionally also make use of the present violations of the constraints, including both the position and the velocity of the connectors. The economic equivalent of this would be to ask each workplace what they will do for the foreseeable future, all else being equal . Any imbalances between supply and demand can then be treated as constraint violations. The modelling part of the process asks each FMU for partial derivatives of each connector's acceleration with respect to each force input ( δ a / δ F ). This results in a set of mobilities , the inverse of mass, through the Newtonian F = m a ⇔ a / F = m - 1 . The rotational equivalent is τ = I α ⇔ α / τ = I - 1 , or δ α / δ τ in derivative form. Because the solver asks for partial derivatives of all connectors with respect to all force inputs, the resulting set of mobilities contain a set of cross-mobilities . A gearbox has a 2x2 mobility matrix, where the off-diagonal elements are its cross-mobilities, which depends on the chosen gear. A differential has a 3x3 mobility ...