Unit Consistency and Reuse in a UAV Endurance Parametric Model
A UAV team is modeling endurance for a fixed-wing surveillance drone. The current parametric diagram has a constraint block 'EnduranceEquation' with parameters fuelMass, specificFuelConsumption, liftToDrag, and velocity. The aircraft block's value properties use inconsistent units: fuelMass in kg, specificFuelConsumption in lb/(lbf·h), velocity in knots. The tool reports a unit compatibility warning, but the team ignores it because the numbers 'look right.' A second variant uses a different engine, and the constraint block is copied and edited, causing two versions. The chief engineer wants a single reusable constraint library and a clear binding to the aircraft's mass and performance properties. The next design review needs a credible endurance prediction with a tolerance of ±5%. The model must also show that the analysis depends on the engine variant and the fuel system.
1. What is wrong with the parametric model, and how should units and value types be fixed?
Read the worked answer
The model mixes unit systems and hides the mismatch behind 'looks right' numbers. In SysML, value properties should be typed by value types that carry a quantity kind and a unit, and constraint parameters should use compatible types. fuelMass in kg is mass; specificFuelConsumption in lb/(lbf·h) is a different unit system; velocity in knots is speed. The parametric binding is only valid if the units are compatible or converted. Define value types such as Mass[kg], Speed[m/s], and SpecificFuelConsumption[kg/(N·s)] (or the equivalent), then either convert the supplied data to one system or insert explicit conversion constraints. Do not ignore the tool warning: validate the binding and show the unit on the diagram. If the equation expects SI, convert lb/(lbf·h) and knots before binding; otherwise the predicted endurance is numerically plausible but dimensionally wrong.
2. How should the constraint block be made reusable across variants and bound to the aircraft block?
Read the worked answer
Move EnduranceEquation into a constraint library and keep it as one reusable constraint block. Give it parameters typed by the value types, not by raw numbers. In an analysis context block, declare a «constraint» property typed by EnduranceEquation and bind its parameters to the aircraft's value properties with binding connectors. For variant support, do not copy the constraint; put variant-specific values on Engine and FuelSystem blocks (or on variant blocks) and bind those values into the same constraint. If the equation itself changes for a different engine cycle, specialize the constraint block or use a variant-specific constraint property, but keep the shared equation as the parent. Allocation is not the right relationship here: binding connectors connect parameters to values; «allocate» would only say the analysis is performed by a block, which is a different statement.
3. What does the ±5% tolerance require in the model, and what should not be modeled as a constraint?
Read the worked answer
The ±5% tolerance is an accuracy requirement on the prediction, not a physical law. Model it as a requirement with text and verification method, and also as a tolerance value property or parameter range on the analysis result so the predicted endurance can be compared with the requirement. Record assumptions (e.g., Breguet range, constant specific fuel consumption, no wind) and their validity range, because the tolerance is meaningless without them. Do not model the tolerance as a constraint equation unless you are actually computing uncertainty; a simple range is enough at this stage. Also do not model the tool's unit warning as a constraint. The review should see: one shared constraint, unit-consistent bindings, variant values, assumption rationale, and a verification case that checks the ±5% against test or higher-fidelity analysis.