{"id":8,"date":"2008-03-27T23:00:47","date_gmt":"2008-03-28T04:00:47","guid":{"rendered":"https:\/\/blogs.mathworks.com\/seth\/2008\/03\/27\/what-is-a-composite-signal\/"},"modified":"2017-01-02T20:47:15","modified_gmt":"2017-01-03T01:47:15","slug":"what-is-a-composite-signal","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/simulink\/2008\/03\/27\/what-is-a-composite-signal\/","title":{"rendered":"What is a Composite Signal?"},"content":{"rendered":"The answer is short and sweet. A composite signal is a mux or a bus signal. These can be thought of as a collection of other component signals. The subtleties of using bus signals and mux signals are a common source of modeling questions, and in 2006 The MathWorks published a new section of Simulink documentation to specifically discuss <a href=\"https:\/\/www.mathworks.com\/help\/simulink\/composite-signals.html\">Composite Signals<\/a>. In this post I will start to share my mental model of the mux and bus.\r\n\r\n<b>It started with mux<\/b>\r\n\r\nThe basic concept for the Mux Block is the idea of bundling signals together. This bundle of signals can be routed through the model, and then operated upon as a collective unit. (Mux actually stands for multiplex.) Along with the Mux Block is the Demux Block, which breaks signals apart into their components to be operated on individually. Take a look at this example.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/muxEx1.png\" alt=\"Simple Mux Example\" \/>\r\n\r\nThe Mux is putting the three signals, (x,y,z) into a single line of width 3. The Demux Block is used to break apart the signals into their basic elements. The Mux and Demux do not change the signals, and are considered virtual. When the model is run, it is as if the blocks don\u2019t exist, and only the connections from source to destination remain, like this:\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/muxEx2.png\" alt=\"Simple mux model virtual blocks, just connections\" \/>\r\n\r\nAn important mental model to use for the mux is the idea of creating a vector. This means you can do things to the output signal that you would do with a vector. For example, multiply the vector by 2.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/muxEx3.png\" alt=\"Mux model with gain\" \/>\r\n\r\nThese types of vector operations impose an important requirement that all signals passed into a Mux Block are the same data type. In my mental model of the mux, it only makes sense to lump signals together if they make sense as a vector. Usually the elements have the same units or they are useful as a group. The only specification you need for a Mux Block is the number of inputs.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/muxDialog.png\" alt=\"Mux block dialog\" \/>\r\n\r\nAnother benefit of using the mental model of a vector is that you can index with the selector block to pick off signals or rewire your connections.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/muxEx4selector.png\" alt=\"Mux model with selector\" \/>\r\n\r\n<b>Later on came the bus<\/b>\r\n\r\nWhen I need to bundle together signals of different types or I can\u2019t naturally express my diagram with a vector, I use a bus. Bus signals can really clean up your diagram. Bus Creators and Bus Selectors provide a graphically convenient way to manage signals and organize your model. In my mental model of the bus, I imagine a rainbow of wires bundled together with a tie-wrap. Without that tie-wrap holding it together I would quickly loose my ability to keep the signals organized. To demonstrate this, I want to look at an example model of the DeHaviland Beaver from the <a href=\"https:\/\/www.mathworks.com\/products\/aeroblks\/\">Aerospace Blockset<\/a>:\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busBeaverTop.png\" alt=\"DeHaviland Beaver Model Top Level\" \/>\r\n\r\nAt the top level of the model, everything is nice and orderly because all the information calculated by each subsystem is bundled up into a bus. Each system packages all the relevant signals into a bus using a Bus Creator, and then passes the bus along to the systems that consume those signals.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busBeaver6dofBus.png\" alt=\"Aerospace 6DOF block and bus creator\" \/>\r\n\r\nCan you imagine if the signals were not bused together? This is a relatively modest model, but it would be a mess!\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busBeaverTopMess.png\" alt=\"DeHaviland Beaver Model with no bus signals\" \/>\r\n\r\nMost of the component systems in this model use bus signals to provide simplified interface. I have noticed that some people will place signals in the bus, just in case they might be needed in another system. Here is an example of a system whose interface is defined with bus signals.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busCalcParamsSys.png\" alt=\"Calculate flight params system\" \/>\r\n\r\nWith a quick glance at this diagram you can determine that the flight parameters (FltParams) can be calculated from environmental signals (EnvirBus) and aircraft signals (ACBus). Inside the system you can see Bus Selectors used to pull specific elements from the bundle of signals. The computed flight parameters are combined with a Bus Creator to define the FltParams Bus.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busBeaverCalcParamsSys.png\" alt=\"Calculate parameters system with bus creator\" \/>\r\n\r\n<b>Bus signals can represent hierarchy<\/b>\r\n\r\nLet\u2019s look at the hierarchy found in the Environment Bus. This is a simple example of a bus being fed into another bus. The environmental signals for gravity (g), pressure (rho), and wind bus (Vwind) are passed into the Bus Creator. The wind bus is defined by the body velocities (uvw_wind) and body rates (pqr_wind).\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busEnvironmentSystem_annotation.png\" alt=\"Environment system bus creator with annotations\" \/>\r\n\r\nThis leads to an organized collection of signals in the bus, as shown by the Bus Creator dialog.\r\n\r\n<img decoding=\"async\" src=\"https:\/\/blogs.mathworks.com\/images\/seth\/2008Q1\/busCreator.png\" alt=\"Bus creator dialog\" \/>\r\n\r\nAt its most basic level, you only need specify the number of inputs to your bus creator. The names of elements are derived from the signal names. Like the Mux Blocks, these bus creators have not changed the signals at all, so we can call them virtual.\r\n\r\n<b>It doesn\u2019t end here<\/b>\r\n\r\nWe are just starting to get into this topic. Next week we will talk about more advanced maneuvers with Mux and Demux Blocks, specifying interfaces with Bus Objects, and nonvirtual buses.\r\n\r\n<b>Now it\u2019s your turn<\/b>\r\n\r\nHow do you use bus and mux signals? What kinds of modeling questions about composite signals do you have? <em>Care to share?<\/em> Post a comment below. If you want to show off the complicated bus hierarchy from your model, <a href=\"mailto:Seth.Popinchalk@mathworks.com?subject=Your%20post%20on%20bus%20signals\">e-mail me<\/a> a picture of your bus and I\u2019ll post it for you (image tags are stripped from comments).","protected":false},"excerpt":{"rendered":"<p>The answer is short and sweet. A composite signal is a mux or a bus signal. These can be thought of as a collection of other component signals. The subtleties of using bus signals and mux signals are... <a class=\"read-more\" href=\"https:\/\/blogs.mathworks.com\/simulink\/2008\/03\/27\/what-is-a-composite-signal\/\">read more >><\/a><\/p>","protected":false},"author":40,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[11],"tags":[12,14,13,444,441],"_links":{"self":[{"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/posts\/8"}],"collection":[{"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/users\/40"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":3,"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"predecessor-version":[{"id":6214,"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/posts\/8\/revisions\/6214"}],"wp:attachment":[{"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/simulink\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}