{{>toc}}

Oftentimes a device we want to model has attributes we are interested in that are affected by other nearby devices in the system we’re modelling. There are many examples of this. Here is one:

Example 1. You might want to model the current through a resistor in an electrical RC circuit. The current is related to its resistance and the voltage across it by V = IR, but what is the voltage? The voltage at the resistor’s terminals is going to be affected by other objects in the circuit, such as other resistors, capacitors, losses in the voltage source under load, etc. Here is what the example circuit looks like:

Solving the circuit as a system of equations, such as with nodal analysis, is the classic solution to the above problem. The voltage solution takes into account the effects of all the elements in the circuit, so when you compute your final I = V/R you’re doing so for the correct voltage. You can do this with an electrical-aspect GUNNS network of the circuit.

Example 2. Now take the above example one step further: now say you want to model the effect of temperature on Resistor_1 and the difference it creates in the current. Resistor_1’s resistance creates waste heat, which warms the resistor material, which changes the material’s resistivity property, which results in a different resistance and current. You now need to track the Resistor_1’s temperature so you can calculate the resistance from it. The temperature needs to increase from the waste heat from the resistive losses, but it also needs some way to cool off – otherwise it would heat up and never cool down. So, you need a thermal model of the resistor and the surroundings it exchanges heat with. The resistor interacts thermally with a different set of objects than it does electrically. Thermally, it exchanges heat with the circuit board it’s soldered to, and there is radiated heat between itself and the surrounding structure. We can model this with a thermal-aspect GUNNS network like shown below:

In this diagram, the capacitor-like symbols represent the thermal capacitance of each object, i.e. its mass times its specific heat. The nodes represent the temperature of each corresponding object, so node 8 has the temperature of Resistor_1. The radiation symbols represent the thermal radiative path between the objects. We assume that the electrical Battery, Resistor_2 and Capacitor don’t create significant heat so we don’t need to model their temperatures. See how this network looks very different from the electrical network — it has different objects and they’re connected in different ways. The thermal interaction of these objects requires a different solution than the electrical network – thus we have a separate GUNNS network for the thermal aspect.

Resistor_1 is now represented by objects in both the electrical and thermal networks, shown in color in the above pictures – the thermal network models its temperature, and the electrical network models its resistance and current.

There’s just one problem left: Resistor_1 in the above example exists as 2 separate links that don’t know about each other! They need to pass some data back and forth to “close the loop” – the electrical resistor model needs to know the temperature so it can calculate its resistance, and the thermal aspect needs to know how much waste heat is coming from the electrical resistance and current. We use the Trick Sim Bus or equivalent utility to move the data. The diagram below shows where the data is moved. We call this an aspect diagram of the overall model:

The thermal capacitor “Resistor_1” in the thermal network takes the waste heat from the electrical resistor and dumps it into its node. After the thermal network solves for a new node temperature, the new temperature is output by the “Resistor_1” thermal capacitor link back to the electrical aspect. Passing this data cyclically in between the respective network updates causes these objects to act in concert as one model of the actual resistor.

Aspect Architecture allows multiple code objects to act in concert to model a physical device.

The purpose of an aspect diagram is to document how a real-world device is represented in the sim as the sum of its various aspects. It shows what the separate code objects are for each aspect and the interfaces between them. Unlike the GunnsDraw drawings, these aspect drawings do not auto-generate any code (yet), and they are not produced with any standard design or tool.

The aspects don’t have to all be related to GUNNS — there may be other aspects of the model that are outside of GUNNS. A lot of our existing links in GUNNS are designed to interface with what we call a “signal” aspect for modelling things like pump motor & valve controllers, sensors, commands & telemetry, etc. This aspect is not solved in GUNNS, but our aspect diagrams will typically include it to show the whole model design. The pump model shown below is a good example of this.

Instead of dividing up the resistor’s functionality into separate code objects, we could have designed GUNNS to implement all of the possible functionality in one class. This unified resistor model could have had separate interfaces to each network solver, allowing it to be present in both networks at the same time. Then you’d only have to instantiate one object in the simulation instead of two separate objects. However, this would have made the basic solver-link interface much more complicated – the solver calls many methods in the link interface and we would have had to provide a way to map different methods implementing the same interface to multiple networks, through some fancy design pattern, etc. By keeping the link objects separate, we keep a simpler 1-to-many interface between the solver and links instead of a many-to-many interface.

Another reason to implement the functionality in separate objects is illustrated in the above examples. The same electrical resistor class can be used in the electrical network whether the thermal response is desired or not. When the thermal response is desired, as with Resistor_1, we implement its thermal aspect as described above. When it isn’t desired, as with Resistor_2, we leave the thermal aspect out of the sim, and initialize the electrical resistor’s temperature to a default constant value, resulting in a constant resistance during run-time. This gives us options to vary the implementation of each instance of similar physical devices based on what fidelity we need.

Aspect Architecture provides flexibility to include only those code objects needed to model the desired aspects of a physical device.

As in any closed-loop system, excess lag around the loop can create stability problems. The Trick Sim Bus introduces a 1-frame lag in each interface. But we’d rather have this lag between the aspects than in between each aspect and its own network solution. This is because:

A physical device’s aspects are often more tightly coupled with the same aspect of nearby devices than between the other aspects of itself.

“Tightly coupled” means two objects are very sensitive to each other, i.e. “changing A has a big effect on B”. The opposite is “loosely coupled”, which means two objects have little or no effect on each other.

For example, the electrical states of the resistors in the above circuit respond to changes in the circuit at almost the exact same time, because electrical charges propagate at near the speed of light through conductors. Compared to the speed at which the electrical state (voltage) can change, the rate of change of the thermal state (temperature) is many orders of magnitude slower. The only way we can get instantaneous response of the electrical states is to solve them simultaneously in one network. Because the interaction between electrical & thermal states is much slower, a frame of Sim Bus lag makes almost no difference.

The following table lists what types of parameters are usually modeled or “owned” by each aspect. There are a few exceptions, but it should give you a good idea of where to start looking for the parameters you’re interested in:

Fluid	Thermal	Electrical	Signal (non-GUNNS)
Fluid pressure	Structural, thermal mass or “metal mass” temperature	Voltage	Sensor models (3)
Fluid temperature	Non-fluid temperature	Electric current	Effector/Controller models
Other fluid properties (density, enthalpy, viscosity, etc)	Fluid wall temperature (pipes, valves, tanks, etc)	Electric power	Commands & Telemetry
Fluid mass/molar/volumetric flow rate	Non-fluid conductive heat flux	Electrical waste heat (resistive losses, heaters, etc) (2)	Effector mechanical position (valves, switches) (3)
Fluid convective & conductive heat flux to/from wall (1)	Radiative heat flux	Open-circuit (blockage) malfunctions	Effector mechanical rates (pump/fans)
Hydraulic power gain/loss	Non-fluid thermal mass, specific heat, capacity	Short-circuit (leak) malfunctions	Effector/Controller waste heat
Fluid pressure rise/loss	Radiative properties (area, emissivity, albedo, etc)		Effector/controller malfunctions
Fluid shaft work, power, torque	Radiative shading, conductive separation (blockage) malfunctions
Fluid valve/duct area & obstructions (conductance)
Fluid volume, capacitance, compressibility
Fluid blockage malfunctions
Fluid leak malfunctions
Fluid heat exchange degradation malfunctions

Notes:
1. Convection between fluid & wall is always owned by the fluid aspect. Conduction between fluid & wall is owned by either the fluid or thermal aspect depending on the implementation.
2. For heaters, the produced heat is owned by either the electrical or thermal aspect depending on the implementation.
3. Some fluid valves are hydraulically self-activated (pressure regulators, etc), control their own position and require no effector/controller model. Likewise, some electrical switches have built-in sensors and trip logic that can override their own position from that commanded by the controller model.

Below is an aspect diagram that shows a lot of the typical interactions between aspects — this is a typical pump/fan implementation with a dynamic motor & controller. The solid black line dividing the aspect quadrants is the thread-safe Sim Bus. The grey lines that cross the Sim Bus are the data that we move via the Sim Bus. There’s a lot going on in this drawing and in the sim, but the result is a high-fidelity integrated model:

Another nice thing about the Aspect Architecture is that the various aspect networks can be executed in different threads and at different rates, and it’s easy to change the threading and rates.

Regardless of actual threading, all networks & aspects can be considered to run in parallel and always have 1 frame of lag built-in to all simbus interfaces between them. This is illustrated in the picture below.

There are advantages and disadvantages of this architecture:

• The disadvantage is the addition of 1 frame of lag in all interfaces. All interfaces have to be designed to handle this 1 frame of lag, which is important for stability in closed feedback loops. If the two networks were placed in the same thread, with A running right before B during each frame, you could have an architecture that sends the outputs of A right into B during the same frame, and then the outputs of B into A at the beginning of the next frame. This would be a no-lag interface. Aspect architecture never does this — it always takes the output of A and gives it to the input of B on the next frame, regardless of whether A runs before or after B in the same frame.

• The advantage is that the interaction between A & B is immune to threading — you can execute A & B in the same thread in either order, or in different threads, and the data flow between them is exactly the same. The sequence of data values passing through their code is exactly the same and thus the model outputs and response is exactly the same. This is a big deal in large multi-threaded real-time sims where the system architects often have to change the threads that models run in to spread out the CPU loads and avoid sim overruns. With Aspect Architecture, they can do this without having to worry that the model responses will change, and the associated re-testing cost and risk of breaking the simulation this incurs. As far as the models are concerned, they see no change in their interaction.

So with a little bit of upfront design cost in designing aspect interfaces to handle the 1-frame lag disadvantage, we gain the huge advantage of threading flexibility.

The picture below shows the relative timing of SimBus transfer between networks running at different rates. In this example, Network B executes 3 times as often as Network A. From A’s perspective, when the output of B is not queued, there is no difference between this case and the example above: it always receives the last output of B from the previous common frame. When the output of B is queued, A receives a queue containing all 3 of B’s outputs from the previous common frame. However in GUNNS we usually don’t bother with queues so the non-queue example below is the typical case. From B’s perspective, each of its executions sees the output of A from the previous common frame. This means that B executes 3 times in a row with the same inputs from A.

This different in rates is used quite often: since the thermal state of objects usually changes much slower relative to the other aspects, we usually execute thermal networks at a slower rate than electrical and fluid networks to save on CPU cost. Network A thus represents the thermal aspect and Network B represents the fluid or electrical aspect in the diagram below. Fluid & Electrical typically send a heat flux to thermal (the red lines from B to A below), and thermal sends the temperature back (the green lines from A to B). The thermal capacitor link in the thermal network doesn’t queue its inputs from the other aspect, so as in the non-queued diagram below, it only receives the last output of A from the previous common frame, and it integrates that heat flux assuming it is constant over its large time step. Although the heat flux isn’t constant, since B is updating it each of its passes, the error this simplification causes is usually negligible because of how slow thermal transients tend to be in the real world.