Home
Electrified aircraft propulsion (EAP) is a prospective advanced propulsion concept to reduce aircraft noise, NOx emissions and aircraft fuel burn. In its most primitive definition, EAP refers to concepts that utilize electrical power in propulsion of the aircraft. This includes hybrid electric, such as the Boeing-General Electric (GE) “Sugar Volt” and turboelectric concepts, such as STARC-ABL, featuring two main engines and an electrically powered aft thruster for boundary layer ingestion. It also includes electric vertical takeoff and landing (eVTOL) vehicles such as NASA's revolutionary vertical lift technologies (RVLT) concepts. The images below show renderings of the Sugar Volt, STARC-ABL, and RVLT EAP concept vehicles.
Hybrid electric and turboelectric concepts utilize an electrical power system to deliver power from an electrical source, e.g. battery or generator, to a motor which drives a propulsor (or aids a turbine) that provides thrust for the vehicle. The electrical power system impacts the overall weight, thermal system requirements, and efficiency of the propulsion system and these tradeoffs need to be considered to meet the design objectives, especially in an optimized fashion. More specifically, this requires the power system to be included in the conceptual design phase of the propulsion system. One of the most widely used tools for conceptual design of propulsion systems is the Numerical Propulsion System Simulation (NPSS).
This repository, the NPSS Power System Library (PSL), is designed to enable NPSS to address these needs for modeling EAP systems. Further, this documentation describes the library, how to use it, and the components, tools, and other files that it contains.
This library contains a set of power system and circuit components, as well as an interpreted electric port component designed to connect power system components. The electric port is included in all power system components and passes voltage, current, and electrical power information back and forth using complex numbers (phasors) implemented via the ComplexNumber class. The components are designed to work in a manner analogous to baseline NPSS components like compressors, turbines, ducts, and others which communicate via their inherent fluid ports. Electric machine components, being the motors and generators, have performance (efficiency) maps that work like traditional NPSS compressors and turbines.
The library also contains simplified thermal management system (TMS) components designed to be connected to the library's power system blocks. These are similar to base NPSS components that can be used to represent TMSs, such as ducts and heat exchangers, but are set up to be convenient to integrate with power blocks.
The electric port serves the purpose of connecting pairs of power system components to form a network. In the present implementation of the Power System Library, components will carry either voltage or current (i) information to be communicated via their electric port(s). A component that carries voltage information is denoted a node or containing an internal node and will have no information on the currents (i) going through its ports when beginning an NPSS solver iteration. Conversely, components that do not contain nodes (nodeless) will not have voltage information but instead populate their electric ports with current (i) information.
For an NPSS Power System Library model to function, nodal components must thus be linked with nodeless components to properly populate the network with voltage and current (i) values. The Power System Library accomplishes this by defining NPSS solver independent variables to represent node voltages in power transforming components. Power transform components may then be linked to other nodal components using nodeless transmission components (e.g. cables, breakers, etc.) to transmit current (i) information between the nodes. The NPSS solver subroutine will then balance the net current (i) at a node to 0 to preserve Kirchoff's Current Law (KCL) by perturbing the node voltages.
Most power transmission components presently do not contain NPSS solver independents for their currents (i). Those that do (e.g. AeroCable & Breaker) are only run on-design to help size the component to the correct ampacity.
For an NPSS Power System Library model to presently work, nodeless (i.e. power transmission) components like cables and breakers must be explicitly defined at the beginning of the solver execution sequence (before any nodal component). This is due to the fact that nodal components do not initially know their port currents (i) when beginning an iteration. The prePass() function is defined for all nodal components to populate their ports with voltage values before model iteration. Nodeless components are then the first components to run so that they may populate current (i) values. This results in all network ports becoming populated with both voltages and currents (i). In short: voltage propagates on a network by the nodal components' prePass() function; current (i) propagates by executing nodeless components first in the solver sequence. For more detail see ElectricPort.
Once model components have been defined, a user may connect them to each other using the linkPortsI() function. This works almost identically to the NPSS linkPorts() for fluid and other standard NPSS connections. All Power System Library electrical components will contain at least one electric port (input or output) to connect to.
Consider a Source object S1 with ElectricPort EP_O and Cable object C1 with ElectricPort EP_I. We may simply connect these components using linkPortsI like so:
linkPortsI(B1.EP_O, C1.EP_I);NOTE: If a component is required to connect to more than one component, the Enode (Bus) component must be used.
The Power System Library is capable of modeling networks with both Direct Current (DC) or Alternating Current (AC) electric power types. The ElectricPort class defines an NPSS Option variable named ElectricPowerType which currently allows four values: UNDEF, DC, AC1, and AC3. The default power type value for nearly all ports is typically UNDEF which when run will throw an error. Therefore, before a model is fully functional, it must have all its respective component's port power types explicitly defined. Some components such as electric sources or power converters will have already defined their port power types and do not require defining (in fact changing these could result in error). After setting the power type option, the NPSS solver will run the correct component calculations corresponding to that power type.
To omit the tedious task of defining the port power types of an entire network or assembly of networks, the findSourcesAndPropagate() was created to automate this process. This function is included the ElectricPort class and may be called after a network is fully connected with linkPortI(). This will proceed to set all port power types to their correct values provided the network is properly connected. All that is required is for the user to define port power types for electric power sources and power converter components which allow for more than one power type (currently only Source types).
A simple example of how to define a power type for a component may be found in the baseline_all_elec.mdl model file:
Source Source {
/* sets all ElectricPowerType options within the component to DC */
setOption("ElectricPowerType", "DC");
/* component attributes */
Vreal = 1000; // real voltage [volts]
Vimag = 0; // imaginary voltage [volts]
effDes = 0.99; // design efficiency [99 %]
}Assemblies are used in NPSS to group a set of connected components. The Power System Library includes an additional ElectricAssembly which extends the generic NPSS Assembly to allow for electric port functionality (no preprocessor directive required). Generic NPSS assemblies typically require a user to promote a constituent component's port to be considered as the entire assembly's port. In the present implementation of the NPSS Power System Library, this is not required and a user may simply use any port in an electric assembly to connect components with linkPortsI() if it makes a functional network.
TODO
--describe common issues people have when building models, running models, and anything else we can think of.
To continue reading, see Library Structure.