One of the big challenges simulation engineers face when modeling physical systems lies in finding a way to formalize and account for all the data flowing between different parts of the system.
This type of obstacle manifests very often during the controls design phase, since models get richer in information and realism, and thus provide the ability to model more and more complex control systems.
As a result, those same engineers need to avoid over-complexifying their models, since they run the risk of introducing counter-productive clutter, adversely impacting the model’s maintainability, and its approachability for colleagues who need to quickly get acquainted with the model’s contents.
This is where signal buses come in. They exist in the physical world, and aside from bus standards and protocols, can be thought of as big, generic containers, which can be used to pipe data from one subsystem to a neighboring one (or from a physical system to a controller). It’s extremely useful to take this vague analog and apply it to system simulation, since it solves the problems I just brought up above. The good news is that signal buses are one of those features that we’ve entirely revamped in Simcenter Amesim since version 17.
In Simcenter Amesim, signal buses rely on a few basic concepts:
Unique identification: any signal, once added to a signal bus, has a unique identifier, which you can use anywhere in your model to refer to that exact signal. This holds true no matter what kind of signal hierarchy you’re working on. In addition, this identifier is 100% under your control - you know your model best, so your identifier can be as representative of the signal it carries as you wish it to be. An added bonus for this feature is that if you make changes to an identifier at the source, these changes are propagated down the line, to wherever you consume the signal.
Your signal identifier is the main way you interact with your bus signals
Structure through hierarchy: physical systems are complex, and are built by combining subsystems, often several layers or stacks of subsystems. Signal buses accommodate this inherent complexity by allowing you to stack signal bus levels, so the data flowing through different parts of your physical model can be as complex as the physical system itself, all the while preserving the “generic pipe” concept, keeping your sketch simple.
Nest buses so that your data layer accurately reflects your physical system
Flexibility through multiple-consumption: control systems pull on sensor data from multiple locations and subsystems. It should come as no surprise that any given sensor output could be used many times over by a variety of controls systems. Signal buses address this by making it possible to consume a bus signal as many times as you wish in your model. This 1-to-N-ness is a fundamental characteristic of real-life data buses, and it’s a feature we thought was worth bringing into our analogous implementation in Simcenter Amesim.
“So far so good,” you may say, “but what’s really in it for me?”
I’m glad you asked! Here are but a few of the concrete advantages of signal buses for our friend the simulation engineer:
Your digital twin more closely resembles its real-world, physical sibling, thanks to a 1-to-1 mapping between data sources and consumers in both versions of the system. Stacking, or nesting signal bus layers means you can precisely mimic the structure of your physical system even in the signal world.
Single-click workflows mean that your modeling environment allows you to improve your systems in just a couple of steps, without the overhead of cumbersome procedures or error-prone modifications. Through improved usability, Simcenter Amesim fades into the background, and allows you to focus on what you really care about – making the best version of your system that you can. It’ll take care of the rest.
As your digital twin becomes more complex, so do its data flows - at no cost to you! A signal bus port can carry arbitrary hierarchies and quantities of information, from a single sensor’s measurements, to a whole controller’s worth of data. This is especially useful if you have multiple representations of a system, with varying modeling complexities. The subsystem’s physical inputs and outputs may remain the same, and so will its data I/O - everything would go through that single signal bus port.
Performance: we value your time as much as you do – this is why we paid particular attention to simulation performance. The signal bus feature brings significant improvements in this space, compared to the implementation it replaces.
Last, but certainly not least: order, readability, aesthetics. You may have a different name for it, but at the end of the day, an easy-to-read model is a useful model, is a positive investment. Wouldn’t you also like to go from this…
Several subsystems represented in the same sketch
The same sketch, segmented into its component subsystems, data flows managed using signal buses
Watch the video below for a complete review of the process: