Unit Conversion — Control Systems/Signal Attributes

Unit Conversion

Control Systems / Signal Attributes

Converts a signal from one physical unit to another, elementwise: y = a·u + b. The factor a and the offset b are not entered – they follow from the pair of units chosen. Each unit is held as its own affine map onto the SI base unit of its quantity (x_SI = scale·x + offset), so the pair collapses to a = scale_in/scale_out and b = (offset_in − offset_out)/scale_out. Converting degC to K therefore gives a = 1, b = 273.15; degC to degF gives a = 1.8, b = 32; rad to deg gives a = 180/π, b = 0.

The two units must measure the same quantity. Metres into seconds has no factor, so the block reports both names and stops the run rather than answering a number.

Ports

• Input – the signal u, in the input unit, of any size [m,n].
• Output – y, the same value in the output unit, and always the same size as the input. The block never reshapes a signal.

Parameters

• Input Unit – the unit the incoming signal is already in. Chosen from the list below; defaults to degC. inherit reads it off the wire instead: the unit the signal carries from the subsystem port upstream that sets one, as Simulink's Unit Conversion does.
• Output Unit – the unit to convert to. The same list; defaults to K. inherit reads it off the wires downstream: the unit set on the subsystem port the output feeds, directly or through other subsystem ports. With either one at inherit and no unit reaching it, the run stops and says which side has none – Simulink stops the model too. A unit read off a wire is spelled as Simulink's unit database spells it (W*h, cal_th, gn, km/(h*s)), which is the spelling a subsystem port's Unit takes. Both lists offer the same units, grouped here by the quantity they measure – a pair drawn from two different groups is refused:
  • Temperature – K, degC, degF, degR. The only group with an offset, which is what makes this block affine rather than a gain.
  • Angle – rad, deg, rev.
  • Angular velocity – rad/s, deg/s, rpm. Kept apart from Frequency deliberately: Hz and rad/s differ by 2π and are not interchangeable.
  • Acceleration – m/s^2, ft/s^2, km/s^2, in/s^2, km/h-s, mph/s, G. G is the standard gravity, 9.80665 m/s² exactly – a defined constant rather than a local measurement, which is what makes it a unit.
  • Angular acceleration – rad/s^2, deg/s^2, rpm/s. Kept apart from Acceleration for the reason Angular velocity is kept apart from Velocity: a radian is not a metre.
  • Length – m, km, cm, mm, in, ft, mi, nmi. nmi is the international nautical mile, 1852 m by definition.
  • Velocity – m/s, km/h, km/s, ft/s, ft/min, in/s, mph, kn.
  • Mass – kg, g, lbm, slug. A slug is the mass one pound-force accelerates at one ft/s² – 14.5939 kg, and 32.174 lbm.
  • Density – kg/m^3, lbm/ft^3, slug/ft^3, lbm/in^3. The first two imperial rows differ by that same 32.174, which is exactly the confusion a from/to pair exists to prevent.
  • Force – N, kN, lbf.
  • Pressure – Pa, kPa, bar, psi, psf, atm. psf is pounds-force per square FOOT, psi/144, which is how aerodynamic pressures are usually quoted.
  • Energy – J, kJ, Wh, kWh, cal, BTU.
  • Power – W, kW, hp (the mechanical horsepower, 550 lbf·ft/s).
  • Torque – N*m, lbf*ft.
  • Time – s, ms, min, h.
  • Frequency – Hz, kHz, MHz.
  • Current – A, mA.
  • Voltage – V, mV, kV.
• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The pair of units is resolved to the two numbers a and b before anything is emitted, and those two are inlined into the arithmetic rather than exposed as tunable parameters – a generated core carries no unit names and no table, only one multiply and one add. Retuning a deployed core to a different unit pair therefore means exporting again.

The three HDL targets are synthesizable, with the fixed-point range caveat that applies to any arithmetic there: the datapath is Q16.16, so a pair whose factor carries the signal outside ±32768 – kWh into J multiplies by 3.6×10⁶ – will not fit, exactly as a Gain of the same size would not. Choose the pair, or rescale, with the datapath in mind.

Simulink bridge

Imports and exports, in both directions, with both units at inherit, as simulink/Signal Attributes/Unit Conversion. Measured against R2026a: that block has exactly one parameter, OutputType, and no unit parameters at all – it reads the unit off the incoming SIGNAL and the outgoing one from what the signal downstream declares, both set on Inport and Outport blocks rather than on the converter. That is what this block does with both units at inherit, so that is the block that crosses: an imported Unit Conversion arrives with both at inherit, and a Simulink model exported from a subsystem port in m through it into one in cm computes 300 for 3 in R2026a, as here. With a unit chosen from the list, the block is reported and not written when a model containing it is exchanged, and its conversion is left on the ICore side: a block emitted anyway would sit in the Simulink model converting between whatever units its neighbours happened to declare, which is a wrong answer rather than a missing one.

That block also defines no SampleTime parameter – set_param against R2026a answers "UnitConversion block does not have a parameter named 'SampleTime'" – so "Sampling Time (s)" stays on the ICore side.

Aerospace Blockset is the other half of this answer, and it is a different reason. Its aerolibconvert2 library ships eleven conversion blocks – one per quantity, each with an IU / OU pair that is exactly what this block's two parameters are, and none of them with a SampleTime either. Any one of them would map cleanly; the trouble is that a catalog entry names one Simulink path for one ICore type, and this block spans eighteen quantities at once. Splitting it into eleven blocks to gain the bridge would trade a table a user reads once for eleven blocks they have to choose between, so those eleven stay unmapped and the coverage stays here. The factors are the same ones: every unit this block shares with that family was checked against convang, convangvel, convangacc, convacc, convvel, convlength, convmass, convdensity, convforce, convpres and convtemp in R2026a, and they agree to the last bit.

Notes

• Algebraic and stateless – the output depends only on the current sample.
• Deliberately carries no state space, even for the pairs where the offset works out to zero and the block really is a gain. The constant term has nowhere to live in A/B/C/D, and making the block's linearity depend on which units are selected would mean model reduction absorbed it under one pair and refused it under another. Refusing it always is the clearer contract.
• The two unit choices are picked from a list rather than typed. That is not only about typos: a free-text parameter is looked up in the variables space first, so a unit named K or m would begin resolving to a user variable of that name the moment one existed, and the block would quietly convert something else.
• A pair drawn from two different quantities is a stopped run with both names in the message, not a silent pass-through.
• Adding a unit is adding one row to the table this block's dialog and arithmetic are both generated from, so a unit can never be offered and be unknown to the conversion. The three quantities and six units added for the Aerospace family (acceleration, angular acceleration, density; nmi, slug, psf, km/s, in/s, ft/min) changed no existing factor and no default.